기능 선택(스프린트 계획 – 1부)
많은 팀이 기능 선정을 위한 지침으로 반복 작업의 전반적인 목표를 설정합니다. 회의 시작 시, 일반적으로 릴리스 계획에서 우선순위가 가장 높은 기능을 선택합니다. 반복 작업에 포괄적인 목표가 있는 경우, 목표에 더 부합하는 경우 우선순위가 낮은 기능도 선택할 수 있습니다. 팀이 현실적인 작업량을 계획하는 데 있어 사전 속도는 매우 중요합니다.
예를 들어, 팀이 이전에 40 스토리 포인트에 해당하는 제품 기능을 확보할 계획이었지만 30 스토리 포인트만 성공적으로 제공했다면, 다음 반복 작업의 현재 속도는 30 스토리 포인트로 간주해야 합니다. 과거 속도 추정치를 실제 수치와 비교하는 것은 반복 작업 수준, 기능 수준, 그리고 작업 수준에서 유용합니다. 이 모든 정보는 팀이 다음 반복 작업에서 얼마나 많은 기능을 확보할 수 있는지 결정하는 데 도움이 됩니다. 반복 작업이 초과 예약된 경우, 고객은 어떤 기능을 다음 반복 작업으로 연기해야 할지 선택해야 합니다. 반복 계획 회의에서 고객은 팀과 기능에 대해 논의하고 팀이 갖고 있는 질문에 답하려고 시도합니다.
작업 계획(스프린트 계획 – 2부)
팀은 기능을 작업으로 나눕니다. 그런 다음 개발자는 작업에 등록하고 예상 시간을 계산합니다. 작업의 크기는 일반적으로 4시간에서 이틀까지이며, 대부분의 작업은 하루 안에 완료될 수 있습니다. 이틀보다 큰 작업은 일반적으로 더 작은 작업으로 나누어야 합니다. 작업 계획 과정에서 특정 기능이 원래 계획에서 심각하게 과소평가된 것으로 판단되는 경우가 있습니다. 출시 계획이 경우, 팀은 고객과 협력하여 수정된 견적을 제공하고, 이로 인해 어떤 기능을 지연해야 할지 결정해야 합니다.
반복 조정
반복 작업 중 모든 기능이 완료된 후 남은 시간이 있다면, 팀은 고객에게 반복 작업에 추가할 추가 기능을 요청합니다. 반면, 모든 기능을 제공할 수 없는 것이 확실하다면, 팀은 고객과 협력하여 반복 작업 마감일까지 최대한의 가치를 제공하기 위해 어떤 기능을 지연하거나 분할할 수 있는지 결정합니다.
경고 신호
- 팀이 여러 차례 반복 작업을 거치면서 기능을 미래에도 계속 확장한다면, 팀이 지속적인 초과 예약을 최소화하고 계획의 정확성을 극대화하기 위해 이전 속도에 더욱 주의를 기울여야 한다는 신호입니다.
- 팀이 각 반복 작업에서 동일한 기능을 계속 추진한다면, 팀이 의도적으로 특정 기능을 피하고 있다는 신호일 수 있으며, 근본 원인을 찾아야 합니다.
- 팀이 너무 세부적인 내용에 몰두하고 각 기능을 전체적으로 설계하는 경우, 필요한 작업을 식별하는 데 더 집중할 기회가 생길 수 있습니다.
자주 묻는 질문
작업 간의 종속성을 어떻게 처리하나요?
이 질문은 꽤 자주 등장합니다. 반복 계획의 일환으로 팀은 기능을 분할할 때 작업 종속성을 최소화하기 위해 노력해야 합니다. Mike Cohn의 훌륭한 저서인 "The Greatest Things"에는 구체적인 기법들이 많이 나와 있습니다. 적용된 사용자 스토리다음으로, 팀은 불가피한 종속성의 영향을 최소화하기 위해 협력해야 합니다. 애자일 팀은 일반적으로 종속성을 최소화하는 단순하고 느슨하게 결합되며 적응 가능한 설계를 채택합니다. 이러한 아키텍처를 고안하고 개선하는 데 유용한 자료로는 밥 마틴의 저서 『애자일 아키텍처 설계』(Agile Architecture Design)가 있습니다. 애자일 소프트웨어 개발: 원칙, 패턴 및 관행. 애자일 팀은 또한 상호 의존적인 하위 시스템과 모듈에서 동시에 작업할 수 있도록 하는 기술, 도구 및 관행을 사용합니다. 테스트 주도 개발자동화된 테스트 하네스, 그리고 모의 객체는 팀이 작업 상호 의존성을 최소화하고 대처하는 데 도움을 줍니다. 지속적이고 긴밀한 협업이 핵심이 될 수 있습니다. 같은 장소에 있는 팀은 반복 과정 전반에 걸쳐 종속성 문제를 적시에 함께 해결하기가 더 쉽습니다.
반복은 한정된 시간 안에 이루어져야 하며, 단 하나의 잠재된 종속성으로 인해 프로젝트가 중단될 위험을 줄여줍니다. PERT 차트와 CPM은 전반적인 시스템 이해 측면에서 잠재적으로 유용하지만, 고속 반복 소프트웨어 개발의 부담으로 인해 무너질 가능성이 매우 높습니다. 2주짜리 반복을 위한 종속성 모델을 구축하는 데 드는 추가 시간과 노력은 그만한 가치가 거의 없습니다. 자동화된 테스트와 코드는 적어도 그만큼 빠르게 더 정확하고 실행 가능한 피드백을 제공할 것입니다.
팀원은 얼마만큼 가입해야 합니까?
팀원은 이전 반복에서 완료할 수 있었던 작업의 총 예상량을 초과하는 작업을 거의 수행하지 않아야 합니다. 반복 계획 단계에서 작업이 수행되지 않는 경우, 이전 반복의 기능 및 작업 속도와 비교하여 팀이 너무 많은 작업을 수행하지 않도록 하는 데 더 중점을 둡니다.
팀 규모가 다를 경우 반복을 어떻게 계획하나요?
일관된 팀워크에 의존할 수 없다면, 애자일이든 아니든 어떤 프로젝트 접근 방식도 큰 통찰력을 제공하지 못합니다. 하지만 반복적 소프트웨어 개발에서는 적어도 시간이 지남에 따라 축적된 어느 정도의 이력을 통해 계획의 기반으로 활용할 수 있습니다. 반복적 개발을 통해 10명의 팀으로 여러 번의 반복을 진행했고, 평균 20일 또는 반복당 200시간의 속도로 반복을 진행했는데, 팀 규모가 절반으로 줄었다고 가정해 보겠습니다. 간단한 계산만으로도 다음 반복에 대해 (적어도 초기에는) 10일 이상의 이상적인 계획을 세우지 않아도 됩니다. 핵심 인력이 제거되었거나 계획이 틀렸다는 것을 알게 되더라도 몇 주 안에 알게 되어 향후 반복에 신속하게 적응할 수 있을 것입니다.
간접비용(회의, 이메일 등)은 어떻게 계산하시나요?
일반적으로 팀은 사소한 오버헤드 항목을 추적하는 데 많은 시간을 들이지 않습니다. 몇 번의 반복 과정을 거치면서 이러한 중단은 점점 더 일관된 (예상치 못한) 속도 실제값에 반영됩니다. 일부 팀은 위험을 줄이고 가시성을 높이기 위해 더 큰 중단 및 차질을 반복 계획에 명시적으로 반영합니다.
반복 계획 중에 버그 수정을 어떻게 고려하시나요?
팀이 버그 수정을 처리하는 방법에는 여러 가지가 있습니다. 가장 간단한 방법 중 하나는 버그를 반복 계획에 명시적으로 반영하고, 우선순위를 정하고, 관련 작업을 예측하는 것입니다. 버그와 기능은 계획 측면에서 본질적으로 동등한 작업 단위입니다. 일부 팀은 반복 프로세스 외부에서 버그를 별도로 추적하기도 합니다. 이 방법은 다소 위험합니다. 반복마다 버그 수정에 필요한 노력이 달라지면 팀의 작업 속도도 그에 따라 달라지기 때문에 예측과 계획에 차질이 생길 수 있습니다. 하지만 버그 수정 노력이 일정하게 유지된다면 이 방법은 상당히 효과적일 수 있습니다.
왜 반복은 항상 같은 길이여야 할까요?
동일하거나 매우 짧은 길이의 반복은 팀이 추정 및 계획 수립에 활용하는 리듬을 제공합니다. 고정된 길이의 반복 없이는 꾸준한 속도를 달성하고 측정하기 어려울 수 있습니다. 반복 종료 시 생산을 중단하는 규칙은 모든 사람의 정신을 집중시키고, 디자인을 단순하게 유지하고 과도한 확장이나 범위 확장을 방지하도록 압력을 가합니다. 조직 전체가 입력, 계획, 실행, 결과, 회고라는 꾸준한 흐름에 빠르게 익숙해집니다. 이러한 리듬이 없으면 팀의 효율성이 떨어집니다. 마감일, 주요 중단, 또는 휴일에 맞춰 특정 반복을 늘리거나 줄여야 할 타당한 이유가 있을 수 있습니다. 하지만 이는 예외적인 경우일 뿐, 일반적인 규칙은 아닙니다.
테스트와 문서화 시간을 어떻게 설명해야 하나요?
테스트 및 문서 업데이트는 개발자의 시간이 필요한 다른 주요 활동과 마찬가지로 우선순위를 정하고, 예상하고, 계획해야 합니다. 테스트 및 문서 업데이트는 특정 기능 아래의 작업으로 생성되는 경우가 많지만, 별도의 기능으로 그룹화될 수도 있습니다.
반복 계획 중에 기능 추정치를 수정해야 합니까?
원래 추정치가 크게 어긋나고 새로운 수준의 노력이 팀의 다른 작업 완료 능력에 상당한 영향을 미칠 경우에만 반복 계획 중에 기능 추정치를 수정해야 합니다.
반복 작업 중에 작업 추정치를 수정해야 합니까?
반복 계획이 완료된 후에는 원래 작업 예상 시간을 수정해서는 안 됩니다. 반면, 향후 반복 작업에 대한 예상 시간은 남은 작업에 대한 정확한 평가를 반영하여 지속적으로 수정해야 합니다.
모든 팀이 동일한 반복 일정에 따라 운영되어야 할까요?
모든 팀이 동일한 반복 일정에 따라 작업하는 것에는 장점이 있습니다. 여러 팀에 걸쳐 반복 상태를 롤업하는 것은 모든 팀이 동일한 일정에 따라 작업하는 경우에만 의미가 있습니다. 반복을 막 시작한 팀과 곧 완료될 다른 팀에 대해 숫자로 된 상태를 롤업하는 것은 도움이 되지 않습니다. 모든 팀이 동일한 반복 일정에 따라 작업하는 것의 단점은 반복을 동시에 시작하고 완료한다는 것입니다. 공통 리소스(예: 고객 또는 경영진)가 여러 프로젝트에서 공유되는 경우, 팀별로 시차를 두고 반복 일정을 조정하는 것이 유용할 수 있습니다.
