첫 번째 반복을 완료하기 전에 스크럼 팀의 초기 속도를 추정하는 몇 가지 간단한 지침이 있습니다(아래 FAQ 참조). 하지만 그 이후에는 검증된 과거 측정 지표를 사용하여 기능 계획을 수립해야 합니다. 일반적으로 속도는 단기간에 안정화되며, 애자일 프로젝트의 단기 및 장기 계획의 정확성과 신뢰성을 향상시키는 데 매우 중요한 기반을 제공합니다. 민첩한 전달 사이클이 매우 작기 때문에 속도가 빠르게 나타나고 프로젝트 초기에 검증하여 프로젝트 예측성을 개선하는 데 활용할 수 있습니다.
속도가 정말 그렇게 간단한가요?
네, 그렇습니다속도를 너무 복잡하게 생각하지 마세요. 속도는 정말 간단한 개념이며, 그 가치의 상당 부분은 그 본질적인 단순성에 있습니다. 속도에 익숙하지 않은 많은 관리자와 팀은 민첩한 방법 속도라는 개념을 과도하게 분석하고 그 주변에 너무 많은 복잡성을 부여하는 경향이 있습니다. 하지만 몇 달 동안 애자일 프로젝트를 경험하고 나면 대부분의 사람들은 속도에 대한 "아하!" 순간을 경험하게 되고, 속도와 관련된 모든 부담을 내려놓고 속도의 단순함과 본질적인 가치를 깨닫게 됩니다.
속도 차트
릴리스 및 반복 번다운 차트와 함께, 애자일 팀의 속도 측정은 프로젝트 진행 상황과 상태에 대한 엄청난 통찰력과 가시성을 제공하는 것으로 입증되었습니다. 속도 차트는 모든 반복에서 수행된 작업의 추정치 합계를 보여줍니다. 일반적으로 속도는 프로젝트 팀 구성이 크게 달라지거나 반복 기간이 변경되지 않는 한 프로젝트 수명 동안 안정적으로 유지됩니다. 따라서 속도는 향후 계획 수립에 사용될 수 있습니다. 일반적으로 몇 번의 반복까지는 신뢰할 수 있지만, 우선순위, 목표, 팀이 시간이 지남에 따라 변경될 수 있고 따라서 반복의 신뢰 수준이 훨씬 더 먼 미래에 변경될 수 있다는 점을 감안한다면, 속도를 사용하여 훨씬 더 먼 미래의 릴리스를 계획할 수 있습니다.
애자일 소프트웨어 개발을 처음 접하는 팀은 우선 활용 가능한 가이드라인과 정보를 활용하여 초기 속도를 선택해야 합니다. 매우 빠르게(다음 반복 작업만큼 빠르게) 속도를 측정하고 조정할 수 있습니다. 속도는 사용자 스토리, 백로그, 요구사항 등의 세부적인 기능과 포인트, 이상적인 일수, 시간 단위의 상위 수준 및/또는 상대적 추정과 함께 사용되며, 전체 프로젝트 계획, 추정, 상태 추적 및 보고 프로세스를 크게 간소화하고 가속화합니다.
애자일 스크럼 FAQ
속도는 어떻게 되나요? 민첩한 개발 팀이 계산했나요?
속도는 반복 작업당 전달된(즉, 승인된) 기능의 추정치의 합계입니다.
속도를 측정하는 데 사용되는 단위는 무엇입니까?
속도는 기능 추정치와 동일한 단위로 측정됩니다. 즉, 스토리 포인트, 일수, 이상적인 일수 또는 스크럼 팀이 제공하는 시간 등이 있으며, 이러한 모든 단위는 허용되는 것으로 간주됩니다.
첫 번째 반복의 속도는 어떻게 추정됩니까?
애자일 팀의 첫 번째 반복의 경우, 일반적인 지침은 가용 시간의 3분의 1로 초기 속도를 계획하는 것입니다. 이상적인 프로그래머 시간을 추정하는 경우, 여기에는 회의, 이메일, 디자인, 문서화, 재작업, 협업, 연구 등이 포함됩니다. 예를 들어, 프로그래머가 6명이고 2주 반복이 있는 경우 총 60프로그래머-일(프로그래머 6명 x 10일)이 사용 가능합니다. 이 경우, 반복에서 이상적인 20일 분량의 작업을 계획하는 것이 좋은 시작점이 될 수 있습니다. 실제 시간을 사용하는 경우, 표준 프로젝트 1) 오버헤드와 2) 추정의 부정확성을 고려할 수 있도록 충분한 여유 시간을 포함하십시오. 또한, 속도는 첫 번째 반복에서 빠르게 나타난다는 점을 기억하십시오. 속도가 과소평가되면 새로운 기능이 추가됨에 따라 첫 번째 반복에서 속도가 증가하고, 속도가 과대평가되면 기능이 제거됨에 따라 속도가 감소합니다. 두 번째 반복의 경우, 스크럼 팀은 첫 번째 반복을 지침으로 사용해야 합니다.
회의, 전화 통화, 이메일도 속도에 포함됩니까?
이는 이러한 항목이 추정되고 포함되는지 여부에 따라 달라집니다. 반복 계획. 일반적으로 포함되지 않습니다. 속도의 목표는 민첩한 팀의 전달 능력 측면에서 반복 작업 전반에 걸쳐 상대적인 일관성과 예측 가능성을 확보하는 것입니다.
모든 애자일 개발 팀이나 프로젝트에 걸쳐 속도를 축적해야 할까요?
속도는 매우 지역적인 측정 기준입니다. 팀원마다 서로 다른 "성격"을 가지고 있을 뿐만 아니라, 각 프로젝트는 일반적으로 추정 기법, 세부 프로세스, 기술, 고객 참여 등에서 고유한 특성을 가지고 있습니다. 결과적으로 조직 전체의 분석이 매우 부정확해질 수 있습니다. 반면에 모든 팀이 정확히 동일한 추정치를 사용하고, 정확히 동일한 것을 개발하고, 정확히 동일한 것을 테스트하고, 정확히 동일한 것을 추적한다면, 당연히 당신은 예외일 수 있습니다.
속도가 변동한다면?
속도는 일반적으로 합리적인 범위 내에서 변동하는데, 이는 전혀 문제가 되지 않습니다. 속도가 한두 번 이상 큰 폭으로 변동하는 경우, 스크럼 팀은 속도를 재추정하거나 재협상해야 할 수도 있습니다. 출시 계획.
속도가 안정되려면 얼마나 걸리나요?
대부분의 애자일 개발팀의 경우 속도는 일반적으로 3~6회 반복 사이에서 안정화됩니다.
향후 반복 작업을 어떻게 예상합니까?
향후 반복 작업은 팀의 검증된 이력을 활용하여 팀이 얼마나 많은 작업을 수행할 수 있는지 파악합니다. 따라서 향후 반복 작업을 계획할 때 사용할 수 있는 적절한 척도는 속도입니다.
프로젝트 팀의 규모가 변경되면 속도를 어떻게 추정합니까?
속도는 팀의 일관성에 달려 있어 가장 큰 가치를 지닙니다. 애자일 팀이 변경되는 경우, 향후 반복 작업을 계획할 때 상식적으로 판단해야 합니다. 팀의 20%가 몇 번의 반복 작업에 참여할 수 없다면, 계획된 속도를 20% 정도 줄이세요. 여기에 핵심 인력 몇 명, 특히 참여 가능성이 낮은 고객이 포함된다면, 예상 속도를 조금 더 줄이세요. 다음 반복 작업 동안만 팀이 무엇을 제공할 수 있는지, 그리고 그에 따라 새로운 속도를 더 잘 파악할 수 있습니다.
최대 속도가 최대 생산성을 뜻하는가?
절대 그렇지 않습니다. 속도를 극대화하려는 시도에서 팀은 오히려 정반대의 결과를 얻을 수 있습니다. 속도를 극대화하라는 요청을 받으면 팀은 단위 테스트나 인수 테스트를 소홀히 하거나, 고객 협업을 줄이거나, 버그 수정을 건너뛰거나, 리팩토링을 최소화하거나, 다양한 애자일 개발 관행의 여러 핵심 이점을 놓칠 수 있습니다. 단기적인 개선(그렇게 부를 수 있다면)을 제공할 수는 있지만, 장기적으로는 부정적인 영향을 미칠 것입니다. 목표는 속도 극대화가 아니라, 최종 제품의 품질을 포함한 여러 요소를 고려한 시간 경과에 따른 최적의 속도를 달성하는 것입니다.
반복 길이가 변경되면 속도를 어떻게 측정합니까?
적어도 그렇게 쉽게는 아닙니다. Velocity의 가치는 내재된 일관성에서 비롯됩니다. 고정된 반복 기간은 프로젝트의 안정적인 리듬을 유지하는 데 도움이 됩니다. 이러한 리듬이 없으면 끊임없이 수정하고, 재추정하고, 조정해야 하며, 일관되지 않은 결과로 인해 미래를 예측하는 능력이 저하됩니다. 반면에 거의 모든 사람이 연휴로 일주일을 쉬거나 회사 전체 회의로 며칠 동안 휴가를 가야 한다면, 상식에 따라 반복 날짜나 속도를 조정하면 됩니다. 대부분의 애자일 관행과 마찬가지로, 이는 규칙이 아니라 지침입니다.
