예측

Mitch Lacey 작성. Agile 및 Scrum 채택과 개선을 전문으로 하는 컨설팅 기업인 Mitch Lacey & Associates, Inc가 소유자입니다.

2012년 1월

Mitch Lacey는 소프트웨어 프로젝트 추정과 관련된 문제에 설명하고 프로젝트를 추정할 때 두 개의 agile 소프트웨어 추정 기술을 사용하는 팁과 요령을 제공합니다.

적용 대상

응용 프로그램 수명 주기 관리; Team Foundation Server

내용

• 소개

• 예상이 힘든 이유

• 애니메이션 기술

• 측정 단위로서의 스토리 포인트

• 포커 계획

• 벽 예상

• 추정

• 우선 순위 지정

• 결론

창조적이고 예측할 수 없는 작업을 예측하는 것은 매우 어렵습니다. 수행하는 방법을 선택하는 것 역시 부담스러운 일입니다. 프레드 브룩스는 "어떠한 정량적 방법없이 적은 데이터와 주로 관리자의 직관에 의해서 검증하는 방법에 의해서는 생생하고 그럴듯한 작업 위험 방어 추정치를 만드는 것은 매우 어렵습니다." 라고 말했습니다.

경영진에게 이러한 추정치가 개괄적이고 모두 너무 자주 초기 추정치가 실현된다고 경영진에게 상기시킴에도 불구하고 먼저 소프트웨어 프로젝트에 대한 추정치를 제공해 달라고 요청이 옵니다.

이 문서에서는 프로젝트를 미리 추정하는 것이 어려운 이유, Agile 소프트웨어 추정 기술이 도움을 제공하는 방법 및 계획 포커와 스토리 포인트를 사용하여 프로젝트 백로그를 추정하는 방법을 살펴보겠습니다.

예상이 힘든 이유

대부분의 프로젝트에서 미리 예상해야 합니다. 이러한 문제가 발행하는 이유를 이해하려면 1981년에 Barry Boehm이 소개하고 Steve McConnell이 1997년에 그의 저서 소프트웨어 프로젝트 생존 가이드에서 다시 소개한 불확실성의 원뿔을 검토해야 합니다.

원뿔은 프로젝트의 시작 부분(4x~0.25x 분산 범위)에 불확실성이 가장 많다는 것을 나타냅니다. 이러한 가변성은 일년 프로젝트로 추정한 것이 실제로는 3개월에서 48 개월 사이에서 끝날 수도 있음을 의미합니다. 모든 프로젝트는 프로젝트에 대해 가장 확신하지 못할 때 시작하지만 매우 정확한 추정치를 제공해 달라는 요청을 받을 때도 시작합니다.

Agile에서 가능한 사이클을 짧게 하기 위해 불확실성에서 확실성으로 이동하려고 시도합니다. 시스템에 대한 초기 학습 효과와 설계 방식을 극대화함으로써 달성됩니다. 이렇게 하기 위해 시스템, 전체 및 작업 스토리를 통해 단일 경로를 만듭니다. 이를 사용하여 훨씬 더 빠르게 그리고 자신감을 가지고 확실성으로 이동할 수 있도록 디자인 및 요구 사항 가정을 및 디자인 가정을 없앱니다.

애니메이션 기술

카운트, 전문가(개별 및 그룹), 분해, 비유, 프록시 추정, 계획 포커 및 벽 추정을 포함하여 다양하고 유효한 추정 기술이 있습니다. Cocomo II 같은 도구도 사용할 수 있습니다. 이러한 기술에서 모두 시간, 일, 주, 달, 이상적인 날짜, 티셔츠 크기, 포인트 등의 예측 단위 중 하나 또는 전부를 선택해야 합니다. 장치를 이해하지 못할 경우 예측은 아무런 의미도 없습니다. 이 모두를 고려하면 예상에 어려움을 겪는 이유는 놀라운 것이 아닙니다.

Agile팀은 특정한 종류의 예측 단위와 기술 제품 백로그(스토리 점수와 계획 포커)를 예측하는 기술로 몰리지만 사용자의 팀은 필요에 가장 적합한 방법을 마음대로 사용할 수 있습니다. 필자의 경험상 계획 포커 또는 벽 예상 중 하나를 사용 여 스토리 포인트를 추정하면 최선의 결과를 얻을 수 있습니다. 다음 단락에서는 측정 단위로 스토리 포인트와 선호하는 두 가지 추정 기법 즉 포커 계획과 벽 추정을 학습합니다.

측정 단위로서의 스토리 포인트

Mike Cohn은 “스토리 점수는 사용자 스토리의 전체 크기, 작업의 기능 또는 기타 요소를 나타내기 위한 측정 단위입니다.”라고 스토리 점수를 가장 잘 요약합니다. " 스토리 점수를 통해 다른 것들과 비교하여 크기와 복잡성 측면에서 스토리의 크기를 알 수 있습니다. Mike는 팀이 상대 크기의 개념을 이해하도록 도울 때 종종 “dog points”를 언급합니다. 2점(소) 개는 치와와입니다. 13점(대) 개는 그레이트 데인입니다. 이 두 가이드를 염두에 두고 치와와 또는 그레이트 데인에 대해 다른 개 품종의 크기를 매우 쉽게 조정합니다. 치와와보다 약 두 배 큰 비글은 5일 수 있습니다. 비글보다는 크고 그레이트 데인보다는 작은 래브라도는 8입니다.

먼저 스토리 포인트를 사용을 학습하려면 팀은 자체 고정 비교 지점을 설정해야 합니다. 이렇게 하려면 모두가 작고 동의하는 제품 백로그(크기나 복잡도 측면에서)의 스토리를 선택하거나 중 크기 또는 복잡성의 관점에서)의 스토리와 모두가 크다고 동의하는 스토리를 선택합니다. 저는 2 포인트가 될 수 있는 저만의 작은 스토리를 가지는 것을 좋아합니다. 왜냐하면, 만약 제가 작은 스토리(장난감 치와와를 발견했을 때)로 돌아가고 싶으면 돌아갈 수 있기 때문입니다. 만약 제가 알려진 가장 작은 스토리를 1 포인트 스토리로 한정한다면, 더 작은 스토리가 필요할 때 어려움을 겪게 될 것입니다. 이를 기준으로 다른 스토리 크기를 조정할 수 있습니다.

이러한 크기를 나타내는 번호를 선택할 때 최선의 작업을 위해 피보나치 수열을 찾습니다. Fibonacci는 이전 두 숫자의 합계입니다. 따라서 1과 2이고, 다음은 3입니다. 3과 2, 다음은 5입니다. 5와 3, 다음은 8 등입니다. 사람들은 10진수에 익숙하므로, 저는 티셔츠 크기나 지수적으로 증가하는 (4/8/16/32/64/128/256, 등) 수보다 피보나치 수를 선호합니다. 예를 들어 xs, s, m, l, xl과 함께 안에 있더라도 해당 범위에서 벗어나면 혼동됩니다. 피보나치는 수는 간단하고 쉽게 이해될 수 있으며, 목표에 도달할 수 있는 충분한 정확도를 상대적인 추정치와 함께 제공합니다. 다른 숫자 집합을 선택할 수 있지만 중요한 것은 일관성을 유지해야 한다는 점을 잊지 마십시오.

스토리 포인트는 고정되지 않은 상대적인 값입니다. 시간과 포인트 간에는 직접적인 상관 관계가 없습니다. 예를 들어, 2 포인트 범위의 스토리를 완료하는데 실제로 필요한 시간은 매우 광범위하므로 2 포인트 스토리가 12.2 시간과 같다고 말할 수 없습니다. 마찬가지로, 팀의 스토리 점수를 특정 수준의 다른 팀 스토리 점수와 비교할 수 없습니다. 스토리 포인트는 스토리 포인트를 예측하는 팀에 의해 만들어져 사용되고 팀에서만 이해하지만 절대적이지 않은 복잡도 포함될 가능성이 있습니다.

포커 계획

측정 단위를 선택하고 배율을 설정한 후 예측할 시간입니다. 대부분의 Agile 팀은 스토리의 상대 크기를 추정하기 위해 계획 포커를 사용합니다. 이는 비유와 전문가 판단을 포함하여 여러 주관적 추정 기법을 포함하는 객관적인 측정이므로 agile 팀에 많이 사용됩니다. 포커를 계획하는 열쇠는 참가입니다. 팀의 모든 사람이 참가해야 합니다. 기능 테스터는 개발 작업을 예측하고 그 반대의 경우도 마찬가지입니다. 기능 프로젝트 관리자는 개발 작업을 예측할 수도 있습니다. 이렇게 하면 목표 수치가 가능한 훨씬 주관적인 예측을 포함하게 됩니다.

포커 카드 계획의 집합으로 시작합니다. 계획 포커 카드는 색인 카드로 쉽게 계획할 수 있으며 카드 놀이를 통해 조작되거나 구매할 수 있습니다. Visual Studio에서도 계획 포커 카드를 만들 수 있습니다. 각 카드는 스토리 점수의 범위에서 선택한 번호 중 하나를 가지고 있습니다(1, 2, 5, 8, 13, 등). 모든 참가자는 사용 가능한 스토리 점수의 전체 범위를 포함하는 “손”을 처리합니다.

카드를 배포한 후 게임이 시작됩니다.

1. 스크럼 마스터는 제품 백로그의 상위 항목을 팀에게 제시합니다.

2. 팀은 스토리가 무엇인지 논의합니다.

3. 제품 소유자는 질문, 가정, 알 수 없음 및 수락 기준을 명확하게 나타냅니다.

4. 각 팀 멤버는 개인적으로 이 스토리가 참조 스토리, 참조 스토리의 시리즈 또는 제품 백로그 상의 모든 스토리와 얼마나 크게 관련될지를 결정합니다.

5. 셋을 세면 모든 사람이 자신이 선택한 카드를 동시에 보여줍니다.

모든 사람이 동일한 카드를 재생하면 팀은 추청치를 기록하고 다음 이야기로 이동합니다.

만약 큰 차이가 존재한다면, 예를 들어 표시된 숫자의 범위가 1부터 8까지라면, 팀은 스토리 토론에 많은 시간을 소모합니다. 토론에 집중하려면 낮은 입찰자와 높은 입찰자 모두 견적에 대한 이유를 설명해야 합니다. 여기에서는 숫자가 아니라 대화가 중요합니다. 여기에서 학습이 발생하고 모든 가정이 적용되기 때문입니다. 간단한 30초에서 1분의 토론 후에 팀은 4단계와 5단계를 반복합니다. 팀이 스토리에 대한 예측에 동의할 때까지 계속됩니다.

비교적 간단하게 보이지만 몇 가지 기본 규칙을 이해하는 것이 중요합니다. 첫째, 만약 팀이 계약의 일부에 완전하게 동의하지 않았다면 다음 단계로 진행하지 말아야 합니다. 예를 들어, 다른 모든 사람들은 5를 선택했지만, 8을 선택한 사람이 있다고 생각해 봅시다. 모임 사회자가 다음과 같이 말하는 경우: “이제 끝내도 되겠습니다. 이 하나에 5가 포함됩니다. 계속 이동하십시오. 그 사람이 무엇을 할까요? 누가 8을 가졌습니까? 제 경험에 비추어 그 사람은 팀이 어떤 결정을 하든 따르겠지만 더 이상 전적으로 참여하지는 않을 것입니다. 계획은 더욱 빠르게 진행될 수 있지만 무엇인가 귀중한 것을 잃었습니다. 이 사람은 작업을 이해하지 못하고 팀은 구성원 한 명의 입력과 관점을 손실합니다. 동의하지 않아도 좋습니다. 귀중한 이해는 한 사람이 다른 사람보다 많은 수를 확인한 이유에 대한 토론에서 나옵니다. 스스로 교착 상태라고 판단되면 사회자가 “피스트 투 파이브(Fist to Five)” 기술을 사용하도록 합니다. 참가자들이 서로 소원해지지 않고 회의가 진행되는 기적을 낳습니다.

포커 익스프레스를 계획하는 것은 점으로 예상되므로 제품 백로그를 예측하는 것이 이상적입니다. 그러나 스프린트 백로그는 시간 단위로 예측해야 합니다. 계획 포커는 스프린트 백로그를 추정할 수 있도록 성공적으로 사용할 수 있고 사용되었습니다. 하지만 카드의 숫자는 점이 아니라 시간이 됩니다. 따라서 규칙은 간단합니다 -

• 제품 백로그 예측은 점으로 되어 있습니다.

• 스프린트 백로그 예측은 시간 단위입니다.

새로운 정보가 드러나고 우선 순위가 변경되며 표면이 명확해지면 프로젝트의 시작 부분과 수명 주기 전체에서 계획 포커를 사용할 수 있습니다.

벽 예상

계획 포커는 사용자 스토리를 추정하는 환상적인 도구이지만 계획 포커를 사용하여 한 번에 하나씩 수 백 개의 스토리를 추정하는 데에는 너무 많은 시간이 소요됩니다. 추정되거나 우선 순위를 매기지 않은 수백 개의 스토리로 구성된 원시 백로그를 가지고 있다면 빠르게 추정할 수 있는 방법이 필요합니다.

벽 추정은 팀이 토론 2 대 3 그리고 토론 5 대 8을 제거하고 연속적으로 순수한 상대적인 방법으로 사물을 그룹화하도록 설계되었습니다. 또한 관계자를 하나의 스토리가 다른 스토리보다 약간 더 중요한지 여부와 관계 없이 큰 스토리 그룹에 일반 우선 순위를 제공할 수 있습니다.

벽 예측을 수행하려면 먼저 카드에 사용자 스토리를 인쇄해야 합니다. 큰 빈 벽(약 14 피트 X 8-11 피트 높이)을 가진 룸에 팀과 이해 관계자를 모읍니다. 다음과 같은 벽에 대한 두 가지 사항을 이해합니다.

• 높이가 우선 순위를 결정합니다. 맨 위에 있는 스토리가 높고 맨 아래에 있는 스토리는 낮습니다. 스토리의 우선 순위는 ROI, 비즈니스 가치, 또는 단순하게 "이유는 모르지만 그냥 중요한 것"을 기준으로 할 수 있습니다.

• 너비는 크기에 예약되어 있습니다. 왼쪽의 스토리는 더 작고 오른쪽의 스토리는 더 큽니다. (예를 들어 일본에 있다고 한다면 반전시키거나 오른쪽에서 왼쪽으로 이동할 수 있으며, 더 논리적인 방법입니다.) 중요한 점은 수평선 및 수직선을 마음 속에 그리는 것입니다. 팀 멤버와 이해 관계자는 다른 스토리를 기준으로 이것이 맞는 것인지 자문해야 합니다.

팀은 모든 스토리의 크기를 조정하기 위해 벽을 사용합니다. 이해 관계자는 스토리의 우선 순위를 지정하기 위해 벽을 사용합니다. 계획 포커와 마찬가지로 상대적 크기 조정을 사용하고 있습니다. 하지만 두 참조 스토리 비교에 사용하는 대신 벽은 상수가 됩니다 작은 스토리? 왼쪽으로 이동합니다. 큰 스토리? 오른쪽으로 이동합니다. 중요한 스토리? 높이 배치합니다. 지금 없이도 살아갈 수 있는 이야기입니까? 낮게 배치합니다.

관련자는 스토리를 예측하는 동안에 자리에 있을 필요가 없지만 팀은 스토리의 우선 순위를 지정하는 동안 방 안에 있어야 합니다. 스크럼 마스터와 제품 소유자는 예측과 우선 순위 지정 활동에 모두 참석해야 합니다.

이제 예상된 백로그 있으면 이 연습의 우선 순위 지정 섹션을 수행할 수 있습니다. 제품 소유자와 이해관계자가 이미 우선 순위를 부여한 백로그를 주었다면 추정 부분만 수행하면 됩니다. (제품 소유자는 예측이 완료된 후 우선 순위 지정을 다시 방문해야 합니다. 결국, 비용이 우선 순위에 큰 영향을 미쳤습니다.) 팀 역할부터 시작하여 작동하는 방식에 대한 세부 정보를 살펴 보겠습니다.

추정

팀에게 원시 제품 백로그를 제공하고 예측을 시작합니다. 벽의 맨 왼쪽에 가장 작은 가능한 스토리가 있어야 하며 맨 오른쪽에 숫자에 관계 없이 가장 큰 가능한 스토리 있어야 한다고 팀에 지시합니다. 팀은 두 기둥을 기반으로 벽 어딘가에 스토리를 배치합니다. 이런 방식으로 작업을 수행하는 장점은 2 포인트나 3 포인트 스토리에 대해 인식된 개념이 없다는 것입니다. 이는 벽의 크기와 큰 벽이 편리한 이유에 따라 상대적이 될 수 있습니다.

팀이 작업을 수행하는데 문제가 있다면 1부터 8 포인트 범위의 부가적인 참조 스토리를 제공하여 벽을 더욱 구조적으로 만들 수 있습니다. 더 큰 참조 스토리를 만드는 것에 대해 걱정하지 마십시오. 우선 순위에 오르면 더 큰 것은 모두 무너지게 됩니다. 팀이 5개의 스토리를 확인한 후 (왼쪽에서 오른쪽으로 다시 이동하여) 크기와 관련이 있는 위치에 배치합니다. 8점보다 큰 스토리에 대해 벽 오른쪽에 공간을 확보합니다. 더 작은 스토리는 왼쪽으로 그리고 더 큰 스토리는 오른쪽으로 이동한다는 점을 명심하면서 이러한 스토리를 벽에 놓고 팀에게 참조 스토리에 대해 벽에 남아 있는 스토리를 놓도록 지시합니다.

벽에 스토리가 있을 때 팀이 스토리 크기 간에 논리적 구분을 식별하도록 하십시오. 이러한 구분을 보여주기 위해 스토리 그룹 사이에 세로 줄을 테이프로 표시합니다. 곧 이곳에 표시된 벽처럼 보이는 벽이 있을 것입니다. 첫 번째 그룹은 모두 2, 두 번째 그룹은 3, 세 번째 그룹은 5, 그리고 마지막 그룹은 모두 8일 것입니다. 번호는 모든 스토리가 서로에 대해 예상되는 만큼 중요하지 않습니다.

스토리를 추정했으므로 스토리에 우선 순위를 할당할 수 있도록 해당 이해 관계자가 참여해야 합니다.

우선 순위 지정

고객과 관련자는 우선 순위를 결정하는 데 도움이 되는 스토리의 크기를 알고 싶어 하겠지만 자신과 관련된 스토리를 찾고 그 스토리가 완성되는지 여부에 훨씬 중점을 둘 것입니다. 이해 관계자가 우선 순위에 동의하지 않을 것 같으면 제품 소유자는 최후의 우선 순의를 결정에 도움이 되는 정보를 사용할 수 있습니다.

벽을 관계자에게 설명합니다. 벽의 카드가 최종 제품에서 표시할 모든 기능을 반영한다는 점을 알려줍니다. 팀이 이미 각 스토리 예측하고 있으며, 벽에 어떤 열을 기준으로 스토리 예상 지점을 결정할 것인지 설명합니다. 팀 멤버는 우선 순위에서 활성 참가자가 아님을 모두에게 알려주십시오. 이는 동작, 상호 작용 및 일부 스토리가 우선 순위에서 올라가거나 떨어지는 이유에 대해 관찰하고 메모합니다. 이들은 필요할 경우 이해 관계자의 모든 질문에 답변할 수도 있습니다. 특정 이해관계자에 의해 하나 또는 그 이상의 스토리의 크기가 요구되므로 팀이 확신을 가지고 크기를 결정할 수 없다면, 시간이 허락할 때 스토리에 대한 질문을 할 수 있습니다.

테이프에 기록된 열에서 스토리를 위아래로 이동하여 모든 스토리의 상대적 우선 순위를 결정하도록 관련자에게 부탁합니다. 벽에서 스토리가 위로 올라갈수록 비즈니스에 부여되는 우선 순위는 높습니다. 다음 규칙을 설정합니다.

• 스토리를 상단에 배치하는 경우 배치를 정당화할 수 있어야 합니다.

• 한 스토리가 다른 스토리보다 더 중요한 이유를 서로 질문할 수 있습니다. 자유롭게 서로에게 "누가 이 스토리를 아래로 또는 위로 이동시킬 것입니까?"라고 물어보거나 "제 생각엔 이 스토리를 이동할 필요가 있습니다"라고 크게 말하세요. 누가 거부합니까?” 이것은 중재 없이 관심을 갖고 있는 당사자 간에 대화를 유도합니다.

• 다른 사람이 한 것보다 스토리를 더 낮은 벽으로 이동하려면 우리가 알 수 있도록 색깔있는 점으로 표시하십시오.

그룹으로 우선 순위를 지정하는 가장 큰 이점은 모든 이해 관계자가 더 잘 다양한 스토리의 우선 순위를 이해할 수 있다는 것입니다. 해결 방법 없이 토론이 너무 길어진다면, 제품 소유자는 카드를 수집하고, 합의점을 찾지 못한 두 이해관계자를 식별하여 후에 개인적으로 그들을 만족시키도록 메모를 합니다.

실습은 스토리 수와 이해 관계자 수에 따라 2-6시간 걸릴 수 있습니다. 완료되면 아래 표시된 그림 같은 벽이 만들어집니다.

벽은 거의 4개로 나뉩니다. 왼쪽 위에 있는 스토리는 우선 순위가 높고 소형이므로 제품 백로그의 위쪽에 들어가게 됩니다. 오른쪽 상단의 스토리가 우선 순위가 더 높지만 크기도 큽니다. 이러한 스토리는 향후 스프린트에 도입할 수 있도록 곧 분류해야 합니다.

왼쪽 아래 사분면은 우선 순위에서 낮은 작은 스토리로 구성되어 있습니다. 이들은 백로그 바닥으로 떨어질 것입니다. 오른쪽 아래 사분면은 우선 순위에서도 낮은 큰 스토리로 채워집니다. 이러한 스토리는 서사시 또는 테마입니다. 이들은 결국 더 작고 보다 관리하기 쉬운 스토리로 세분되지만 우선 순위는 올라가지 않습니다.

벽을 전체로 보고 있는 시간을 그룹과 함께 소비합니다. 스토리가 잘못된 사분면에 있는 경우 이동합니다. 우선 순위가 높은 이야기는 반드시 세분화되어야 하며, 방안에 있는 모든 사람이 이를 수행하는 시간이 주어져야 합니다.

벽 추정이 끝나면 릴리스 계획을 시작하게 됩니다. 팀의 기록 속도 알고 있다면 왼쪽 위 사분면의 어떤 스토리를 완료할지 대략적인 범위를 제공할 수 있습니다.

프로젝트의 시작 부분에는 불확실성이 아주 많기 때문에 추정이 어렵습니다. 제품 소유자와 agile 프로젝트 관리자는 제품 소유자와 이해 관계자와의 대화하고 작업 소프트웨어를 생산하며 출시할 소프트웨어에 대한 피드백을 통합함으로써 처음 학습한 가치를 최대화하려고 합니다. 하지만 애자일 프로젝트라 하여도 기능 집합을 릴리스할 준비가 되었을 때 어느 정도의 예측을 제공해야 합니다.

권장하는 두가지 추정 기술은 계획 포커(스토리의 저 작은 집합에 적합한) 또는 벽 추정(큰 원시 제품 백로그를 관리하는 데 적합한)입니다. 두 평가 방법은 평가의 궁극적인 목표인 계획 수립을 시작하는데 필요한 데이터를 제공할 것 입니다.

참고 항목

개념

공동 작업[리디렉션]

공동 작업(더 자세히)[리디렉션]

백로그 만들기

백로그 정리 및 예상

1. Mike Cohn, Agile Estimating and Planning, Page 36

2. Consensus decision-making: hand signals (Wikipedia)