※ 일본의 한 블로그 글을 번역한 포스트입니다. 오역 및 의역, 직역이 존재할 수 있으며 틀린 내용은 지적해주시면 감사하겠습니다.
스크럼에서는 스프린트에 투입할 프로덕트 백 로그 아이템은 Ready(준비가 되어 있다)일 필요가 있다. Ready로 해두는 것으로 성과를 일정하게 유지하면서, 프로덕트 오너나 이해 관계자의 입장에서는 예측 정확도를 향상 시킬 수 있다.
Ready활동은 단순히 받아들여지는 기준을 준비하거나 프로덕트 백 로그의 내용을 정교화화거나, 나열하는 정도로 그치지 않는다. 스프린트내에서는 프로덕트 백 로그 아이템을 완성 가능성을 높이기 위해 필요한 활동 모든 것을 포함한다. 그리고 그 중에서 하나가 기술적인 조사이다.
스프린트에서는 프로덕트 백 로그 아이템의 개발에 착수한 후에 구현 방법을 조사하거나, 기술적인 제약에 따른 대폭적인 방침을 전환하거나 하면 릴리즈가 늦어지거나 예측성이 낮아지므로, 착수 전 먼저 기술 조사를 해야한다. 이러한 조사를 스파이크라고 부른다.
이번에는 스프린트를 실제로 시작한 후에 스프린트를 진행하면서 어떻게 스파이크를 하면 좋을지에 대해서 살펴 보고자한다 (스피린트0을 만드는 기간중에도 스파이크를 실시하지만 이번에는 스프린트에서의 활동에 포커스를 두도록 하겠다).
1. 스파이크의 정의
먼저 Agile Dictionary이라는 애자일 용어 해설 사이트의 정의에서 스파이크를 어떻게 정의하고 있는지 살펴보자.
스파이크
릴리즈 가능한 프로덕트를 만드는 것이 아닌, 질문에 답하거나 정보를 수집하는 것을 목적으로 하는 작업이다.
개발 팀이 기술적인 질문이나 설계 상의 문제를 해결하기 위해 실제 작업을 하기 전, 어느정도의 개발 스케줄을 갖고 가야할지 잘 모르겠는 프로덕트 백 로그 아이템이 생기는 경우가 있다. 이러한 경우 해결책은 “스파이크”를 진행하는 것이다.
목적은 질문에 대한 해답이나 솔루션을 찾는 것이다.
어원
스파이크라는 용어는 익스트림 프로그래밍(XP)으로 부터 유래됐다. 여기서 “스파이크란 매우 간략한 프로그그램으로, 솔루션 후보를 탐구하는데에 사용된다”라고 적혀있다. 워드 커닝햄은 c2.com이라는 wiki에서 이 용어가 어떻게 생겨났는지를 기재하고 있다. “우리가 올바른 방향으로 나아가고 있다고 확신할 수 있는 더욱 간단한 것은 무엇인가?”라는 질문에 대해 조금 여유가 남을 정도로 작게 진행함으로써 단순하고 설득력있는 해결책을 찾는 방식으로 전개하기 시작했다. 그리고 켄트 벡은 이것을 스파이크라고 명명했다. 이보다 큰 프레임워크 보수를 할 때에서 이러한 스파이크가 도움이 되는 것을 알게 됐다.
2. 스파이크의 목적
즉, 스파이크의 목적은 다음과 같이 정리할 수 있다.
- 질문이나 의문에 대답할 수 있기 위한 정보를 수집한다.
- 보다 좋은 구현 방법을 탐색한다.
- 견적의 정밀도를 높인다.
- 리스크를 사전에 명확히 해둔다.
3. 스파이크의 진행방법
스크럼에서는 스프린트마다 “릴리즈 판단 가능한 인크리먼트”를 만드는 것을 중시하고 있다. 각각의 스프린트에서 스프린트 목적을 달성할 수 있도록 진행해야만 한다.
따라서 스프린트의 시간을 스파이크로 채우면 안된다. 따라서 아래의 방법으로 진행해야한다.
기본 흐름
- 먼저 프로덕트 백 로그 리파이먼트등을 활용하여, 가까운 스프린트내에 착수할 가능성이 있는 프로덕트 백 로그 아이템을 워크 스루하면서 기술적인 과제가 있는지 아닌지를 확인한다.
- 예를 들어 기술적인 시점에서 아래와 같이 분류해본다
- 환경이나 전제 조건등을 정하여 측정해보지 않으면 모르는 것
- 누구도 해보지 않았고, 노하우나 정보의 입수가 어려운 것
- 누구도 해보지 않았으나, 인터넷상에 다양한 정보가 있을 것 같은 것
- 개발 팀 내에 소수이지만 경험이 있는 것
- 개발 팀에 많은 사람이 알고 있는 것
- 분류한후에 특히 분류 1~3에 포함되는 기술적인 과제가 있는 경우 그것들이 어느정도 큰 문제가 될지 개발팀에서 판단한다
- 개발 팀으로서 커다란 과제는 아니라고 확신이 들었다면 별다른 액션을 필요로 하지 않는다.
- 그렇지 않은 경우는 개발 팀으로서 이러한 과제가 어떤 상태라면 해결됐다고 할 것인지 합의한다.
- 여러 개의 스파이크 항목이 있는 경우, 보통 프로덕트 백 로그와 동일하게 나열한다.
- 그 후에 스파이크를 사용하는 시간의 상한을 설정한다(끝날 때 까지하면 시간이 늘어나므로, 타임 박스를 정한다).
- 스파이크를 실시한다. 필요한 것을 판명하거나, 타임 박스의 상한에 도달하면 스파이크 결과를 공유한다
- 그 후에 더욱 더 추가 스파이크가 필요한지 아닌지를 판단한다.
4. 스파이크를진행할 때 주의할 점
스파이크를 진행할 때는 몇 가지 주의점이 있다. 예를 들면 다음과 같은 몇 가지가 있다.
- 목적이나 과제의 인식을 빼먹지 않도록 한다.
- 스프린트1을 시작하기 전의 초기 단계에서 모든 것을 검증하려고 하지 않는다
- 곧 진행할 스프린트를 대상으로하여 중요한 곳에 포커스를 맞춘다
- 프로덕트 백 로그 아이템의 착수 방식과 동일하게 가능한 개발 팀에내서 한개씩 끝낸다. 즉 스파이크 담당자를 고정하지 않도록 한다.
- 지나치게 하지 않도록 한다. 목적은 프로젝트 백 로그 아이템의 정확도를 향상시키기 위한 것이므로, 모든 것을 망라하려고 하지 않아도 된다.
- 스파이크는 어디까지나 스파이크이므로, 스파이크의 성과 코드를 갑자기 프로덕트 코드에 넣지 않도록 한다
- 설정한 타임 박스에서 끝나지 않은 경우 상확을 확인하고 다시 계획을 세운다. 경우에 따라서는 그만두자고 판단하는 경우도 있다.
- 타임 박스의 설정은 스프린트 시간(기간)의 20%정도가 현실적이다. 물론 개발 팀의 능력에 의존한다.
- 스파이크의 결과는 프로덕트 백 로그 아이템안에 반영된다.
5. 스파이크를 프로덕트 백로그에 넣을지 아니면 버퍼에 넣을지 고민이 될 때
스파이크를 프로덕 백 로그에 넣을지 스프린트의 버퍼에 넣을지 고민이 될 것이다. 그럴 때에는 다음과 같이 결정하면 좋을 것 같다고 생각한다.
버퍼에 넣을 경우
- 스파이크의 소요시간이 짧을 것 같은 경우
- 만일 다른 프로덕트 백 로그 아이템의 구현에 시간이 걸리는 바람에 버퍼가 줄어들어 충분한 스파이크를 할 수 없어고 당장 큰 문제가 되지 않는 경우
프로덕트 백 로그 아이템에 넣을 경우
- 이 다음의 스프린트 진척에 영향을 끼칠 정도로 커다란 문제라고 생각되는 경우
- 스파이크가 필요한 프로덕트 백 로그 아이템이 다른 프로덕트 백 로그 아이템과 의존관계를 형성하고 있는 경우
- 검증에 시간이 걸리는 경우(개발 팀의 버퍼를 넘어가는 시간이 필요한 경우)
또한, 프로덕트 백 로그의 순서의 최종 결정 권한은 프로덕트 오너이다. 따라서 스파이크의 프로덕트 백 로그아 아이템의 중요성을 개발 팀으로서 프로덕트 오너에 전달하여, 스프린트로 투입할지 말지 결정을 부탁 필요가 있다.
6. 정리
반복되는 내용이지만, 준비되지 않은(Ready가아닌) 프로덕트 백 로그 아이템, 완성할 자신이 없는 프로덕트 백 로그 아이템을 스프린트에 투입하는 것은 피하는 것이 좋다.
그리고 프로덕트 백 로그 아이템은 착수전에 요구의 시점뿐만 아니라 기술적인 시점등도 포함하여 완성할 수 있는가를 확인해 둘 필요가 있다.
또한, 기술적 시점에서는 스파이크는 유효한 방법이 된다. 어느정도 스파이크가 필요가한가에 대해서는 개발 팀이 다루고 있는 기술이나 경험에 크게 좌우되지만, 중요한 문제에 포커스하여 타임박스를 설정하여 진행하는 것이 중요하다.
참고자료
'IT > 일본 IT 회사 생활' 카테고리의 다른 글
| [IT 회사 생활] 다른 부서에서도 신뢰받는 엔지니어의 특징 다섯가지 (0) | 2024.02.26 |
|---|---|
| [Agile] 스토리 포인트로 견적내는 현실적인 방법 (0) | 2023.04.29 |
| [Agile] 초심자를 위한 Agile기본 (0) | 2023.04.25 |
| [IT 회사 생활] 우리는 심리적 안전성을 오해하고 있을지도 모른다. (0) | 2023.03.26 |
| [IT 회사 생활] 개발 업무는 어떤 순서로 해나가면 좋을까? (0) | 2022.04.19 |