Agile estimation

Pluralsight 를 통해 공부한 Agile Estimation이란 강의내용을 간략하게 정리해보았습니다.

강의는 대략 아래와 같은 목차로 구성되 있습니다.

Overview

  1. The estimation problem today
  2. An introduction to agile estimation
  3. The mechanics of agile estimation
  4. Stop Estimation and use metrics

먼저 Estimation 이란 무엇인가에 대한 정의로부터 출발합니다.

“Estimation is the calculated approximation of a result which is usable even if input data may be incomplete or uncertain.” – Wikipedia

말 그대로 estimation 이란 결과의 추정치에 불과하고, estimation 할 당시의 input data 에 의존성이 큽니다. estimation 은 프로젝트 초기에 이루어지는 것이므로, input data 가 정확할 리도 없고, 충분할 수도 없습니다. 이 점을 올바르게 인식하는 것이 Agile Estimation의 출발점입니다.

Estimate for our project

실제로 우리가 프로젝트 추정하는 시나리오를 생각해봅시다. 보통 프로젝트 일정을 잡을 때, 한달은 아키텍쳐 디자인, 넉달동안 개발, 마지막 한달은 테스트.  그래서 총 6개월의 프로젝트. 보통 이런식으로 프로젝트 일정을 잡고는 합니다.

하지만, 만약 아키텍쳐 디자인에 1달이 아니라, 1주일 정도가 딜레이되서 총 5주가 걸렸다면,  어떻게 될까요? 관리자들은 개발속도를 더 빨리해서, 딜레이된만큼 시간을 벌충하라고 재촉할겁니다.

실제로 우리가 맨처음에 추정했던 estimation 은 신성 불가침의 프로젝트 데드라인이 되는 경우가 허다하고, 이를 어기는 것은 게으르거나 능력이 없는 개발자로 평가되는 경우가 대부분입니다.

그러나 Agile Estimation에서는 다음과 같이 접근합니다.
추정했던 첫번째 estimation 이 틀렸던 이유는 그 당시 제품 요구사항에 대한 detail 이 충분하지 않았기 때문이다. 또한, 첫 예상(4주)보다 25% 의 estimation margin 이 생긴것이므로, 이러한 offset을  development 와 testing 에도 그대로 적용해야 한다.

따라서, 아키텍쳐 디자인이 끝난후에, 첫번째 estimation을 다음과 같이 조정(readjust)합니다.

4달의 개발기간은 5달로 변경

1달(4주)의 테스팅 기간은 5주로 변경.

The cone of uncertainty

프로젝트 개발초기에는  estimation이 잘못될 수 있는 margin 폭이 엄청나게 크지만, 프로젝트가 점점 진행될수록 이 마진 폭이 점점 좁아지고, 따라서 estimation이 점점 정교해짐을 알 수 있습니다.

이를 Cone of uncertainty 라고 부릅니다.

이 개념은 원래 1950년대 화학 공학에서 유래된 개념이고, 1981년 Waterfall 개발 방식의 핵심 특징으로 소개된 개념입니다.

이 개념이 1997년, Steve McConnell 이 쓴 Software Project Survival Guide 라는 책을 통해 소개되었고, software 산업 전반에 알려지게 됩니다. 위 그림이 waterfall 개발 방식에서의 cone of uncertainty 를 나타낸 그림입니다.

위 그림을 보면 waterfall 개발 stage 마다, 좀더 예측이 정확해 지고 있는 것을 알 수 있습니다.

Agile Estimation 에서는 이 개념이 비록 waterfall 개발 방식에서 유래된 것이라 하더라도, 소프트웨어 개발 현실을 인정하고, 이를 적극적으로 수용합니다.

Agile Estimation Theory

“Estimation is the calculated approximation of a result which is usable even if input data may be incomplete or uncertain.”  – Wikipedia
다시 말하지만, estimation 은 어디까지나 결과에 대한 approximation 입니다.

다만, agile estimation 에서는 각 개발 주기가 끝날때마다  이를 다시 정교하게 수정합니다. (re-estimate) . 예측이 틀려서 발생하는 project deviation 은 deviation 이 아닙니다. 좀더 정확한 estimation일 뿐입니다.

Cone of uncertainty 모델을 waterfall 모델이 아닌 agile 모델에 맞게 변경하면 아래와 같이 됩니다.

달라진 것은 x 축의 내용이 기존 워터폴에서 agile 방식인 sprint 로 변경된 것을 알 수 있습니다.

Mechanics of Agile Estimation

Agile estimation 을 가능하도록 만들기 위해서는 먼저 제품의 기능을 user story 로 나누어야 합니다. uml 에서의 use case, xp 에서의 story card  와 유사하며, 포맷은 이렇습니다.

“As a <role>, I want <goal/desire> so that <benefit>”

부가적으로, user story 에 acceptance criteria 를 포함시켜도 됩니다.

예를 들면, user story는 아래와 같이 만들 수 있습니다.

  • As a user, I want to search for my customers by their first and last names.
  • As a non-administrative user, I want to modify my own schedules but not the schedules of other users.
  • As a user closing the application, I want to be prompted to save anything that has changed since the last save so that I can preserve useful work and discard erroneous work.

주의해야 할 것은 user story 에 너무 많은 기술적인 디테일이 담기면 안됩니다. user 즉 사용자 관점에서 기술하는 것이므로, 사용자 레벨에서 적절히 추상화되어야 합니다.

Look at story points

각 user story 는 story point 를 가집니다. 예를 들면 1포인트, 2포인트 식으로 점수를 갖는 것입니다. 이 숫자가 의미하는 것은 해당 user story 에 소요되는 노력을 의미합니다. 다만 주의할 것은 이 숫자를 개발에 소요되는 시간 (날짜)으로 단순 맵핑하면 안됩니다. 물론, 최종적으로 이 포인트는 개발 시간에 비례하겠지만, 일단은 해당 user story의 크기나 복잡도에 해당하는, 추상적인 단위로 생각해야 합니다.

이를 위해 기준이 되는 user story 를 하나 정합니다. 예를 들면 로그인 화면을 구현하는 user story 가 있다고 해봅시다. 이 user story 는 거의 모든 웹 어플리케이션에서 반드시 구현해야 하는 표준 feature 이므로, 기준으로 삼을만 합니다. 이 user story 에 1 story point 를 할당하고, 다른 user story 에는 복잡도와 모듈 크기에 따라 2 포인트나 4포인트 등으로 할당합니다.

이 단계에서 1 포인트를 “XYZ의 스킬을 가지고 있는 팀원 A가 하루동안 구현할 수 있는 크기” 따위로 변환할 필요는 없습니다. 그것이 가능하지도 않습니다. 왜냐면, 프로젝트 초기에 전체 팀원이 어느정도의 퍼포먼스를 낼 수 있을지는 알 수 없기 때문입니다.

Using planning poker

그렇다면, 각 user story 별로 어떻게 story point 를 할당해야 할까요? 프로젝트 매니저 혼자 작성하는 것이 결코 아니고, 팀 내 시니어 개발자 두세명이 모여서 진행하는 것도 아닙니다. 팀원 전체가 모여서 진행해야 합니다.

우리가 프로젝트를 시작하기 위해 회의실에 모였을때 보는 흔한 광경중 하나는, 두 세 명의 야심찬 중간 개발자들이 회의를 주도하고, 아무 생각 없는 매니져나 고참 개발자들은 팔짱 끼고 구경, 신입사원들은 뭘 어떻게 해야 할지 몰라서 또 벙어리 신세입니다.

야심찬 중간 개발자중에서도 정말 실력이 동급최강인 수퍼 개발자가 특정 기술에 대해 어쩌고 저쩌고 떠들면, 또 다른 수퍼 울트라 개발자는 아니다, 이건 그렇고 저건 저렇고, 이런식으로 논쟁을 벌이고, 그걸 이해하지 못하는 나머지 회의 참가자들은 그냥 그런가 보다 하고 따라가기 일쑤입니다. 그러다가 막판에 프로젝트 일정은 논쟁에서 이긴 수퍼 울트라 개발자의 목소리에 좌지우지되서 결정되곤 합니다.

이를 일컬어 dominating personality 라고 부르는데, 팀원들의 능력은 저마다 모두 다르기 때문에 프로젝트 관리자 입장에서는 이를 반드시 경계해야하고, 전체 팀원의 능력을 고려하여 프로젝트 일정을 수립해야 합니다.

Agile estimation 에서는 이때 적용할 수 있는 툴로 planning poker 라는 것이 있습니다.

http://www.crisp.se/bocker-och-produkter/planning-poker

planning poker 를 사용하는 법은 이렇습니다.

1. 회의 전에 모든 팀원들은 user story 를 숙지하고 있어야 합니다.
2. 모든 팀원들이 회의실에 모입니다.
3. 프로젝트 리더는 user story 1을 이야기합니다.
4. 모든 팀원은 자신이 생각하는 user story 1에 해당하는 story point 를 생각합니다.
5. 모든 팀원은 story point 에 해당하는 planning poker 카드를 집어듭니다.
6. 팀원들이 돌아가며 자신이 왜 이 카드를 뽑았는지를 설명합니다.
7. 만약 팀원간의 point 격차가 너무 큰 경우 (가령 한명은 20이 적힌 카드를 뽑고, 다른 한명은 2가 적힌 카드가 뽑혔다면) 이 차이는 반드시 토의를 통해 해결되어야 합니다. 이 과정에서 반드시 모든 팀원들이 토의에 참가해야 합니다.
8. 모든 user story 를 마칠때까지 4~7의 과정을 반복합니다.

이 과정이 중요한 이유는 project estimation 에 모든 팀원이 참여하도록 하기 위함입니다. 수퍼 울트라 개발자라 할지라도 미처 생각지 못한 것을 신입사원을 통해서 깨우칠 수도 있고, 신입사원은 자기가 알지 못한 것을 이 과정을 통해 알 수 있기 때문입니다.

Re-estimation

story point 가 할당된 user story는 product backlog 에 취합합니다. 이때 제품의 출시 상황에 따라 user story 마다 priority 를 줄 수 있습니다.

예를 들면 아래와 같이 작성할 수 있습니다.
Sample Product backlog

Backlog item estimate (points) priority
Allow a guest to make a reservation

3

High

As a guest, I want to cancel a reservation

5

Medium

Sprint 1

첫번째 개발주기인 sprint 1을 실행하고 나면, 각 story point 가 어느정도의 time을 요구하는지를 가늠할 수 있습니다. 다만 이 단계에서 유의할 것은 개발자들이 너무 완벽을 추구한 나머지 over commit 하지 않도록 독려하는 것입니다. 모든 software 는 버그가 있을 수 있다는 것을 인정하고, working prototype 을 만드는 것에 집중하는 것이 더 효율적입니다.

Team Velocity

sprint 1을 실행하고 나면 해당 제품에 대한 전체 팀의 퍼포먼스 수치인 team velocity를 얻을 수 있습니다. team velocity 는 한 iteration 당 얻을 수 있는 토탈 story point입니다.
얻어진 team velocity 를 이용하면, 다음 iteration 에 얼마 만큼의 story point 를 달성할 수 있는지를 예측하는 것이 가능해집니다.

iteration 이 반복되면서 team velocity 는 당연히 변경될 수 있습니다. 그 요인은 story point를 제대로 예측하지 못해서 발생될 수도 있고, 프로젝트 외부요인 (휴가, 병가)일 수도 있습니다. 하지만, 아무리 velocity 가 널뛰듯 하더라도 대개 3번에서 6번의 iteration 을 반복하면 어느정도 안정된 숫자 범위의 team velocity 값을 얻을 수 있습니다.

Re-estimation

프로젝트 리더는 각 sprint 마다 전체 프로젝트에 대해 다시 estimation을 해야 합니다. 프로젝트를 진행하다보면, 초기에는 미쳐 생각하지 못했던, 이런 저런 기능이 함께 구현되야 한다는 것을 알아차리게 되기도 하고, 이미 구현한 어떤 user story에 발생된 버그를 수정해야 하기도 합니다.  또한 개발팀장이 불쑥 나타나, 저 기능이 다음주까지 완료되어야 한다고 말할 수도 있습니다.
반드시 각 sprint가 끝날때 마다 re-estimation 해야 합니다. 우리는 cone of uncertainty 를 적용하고 있다는 사실을 잊으면 안됩니다.

Stop Estimating and use metrics

이제 위에서 말한 개념들을 적용해, 수치화해봅시다.

Metrics at sprint 1

Sprint 1
Backlog size at start of sprint
이번 sprint시작시 토탈 product backlog의 크기
100 (100개의 작업항목)
Sprint backlog committed
이번 sprint에서 처리해야할 work item의 수
10
Sprint backlog completed
이번 sprint에서 처리된 work item 의 수
7 (팀이 빈둥거린다는 뜻이 아님!!)
Team velocity 7
Items added to backlog
새롭게 추가된 워크 아이템
5
Bugs added to backlog
이번 sprint에서 생긴 버그의 갯수
1
Items removed from backlog
구현할 필요없다는 것이 밝혀진 워크 아이템
0
Sprints Estimate to completion 14.14286 (= 99/7)

14.14286 = 99 / 7 = ((100 +(5 + 1) – 7) / 7)

Sprints Estimate to completion = Remaining product backlog size / team velocity

About 14 sprints need in order to complete the project

What about bugs

개발중 발생된 버그는 어떻게 estimate 할 수 있을까요?

버그는 사실 직접 잡아보기전에는 얼마나 걸릴 지 알 수 없습니다. 공학의 영역이기보다는 과학의 영역에 가깝기 때문에,실제 기능구현에 걸리는 시간을 추측하는 것보다 훨씬   추측이 어렵습니다.

이때 적용할 수 있는 방법으로는매 sprint 마다 전체 time 중 몇 퍼센트를 할당하는 방법이 있습니다. 가령 sprint1에서는 아무런 버그가 없을것이므로,전체 시간중  0%의 시간을 bug수정에 할당합니다. sprint2에서는 10% 또는 1 story point를 버그 수정에 할당합니다.

각 스프린트 당 10 story point를 할당했다면, sprint2에서는 10story point 대신에 9 story point만을 할당합니다. sprint 3에서는 20% 또는 2 story point를 버그 수정에 할당합니다.

이런 식으로 계속하여 버그 수정또는 rework에 드는 %를 계속하여 증가시켜 나갑니다.

Metrics at Sprint 2

Sprint 1 Sprint 2
Backlog size at start of sprint 100 99
Sprint backlog committed 10 8
Sprint backlog completed 7 8
Team velocity 7 7.5
Items added to backlog 5 4
Bugs added to backlog 1 2
Items removed from backlog 0 0
Sprints Estimate to completion 14.2 12.9
Allocation % for new Bugs/ Reworks 1 (=0%) 0.95 (=5%)
Weighted number of Sprints to completion 14.2 13.6

위와 같은 metric을 이용하여, 프로젝트 진행상황을 수치화할 수 있습니다.

Metrics give you answers

Realistic indication of how many sprints to completion of entire backlog

  • Using the weighted average

How many story points per sprints are done (velocity)

Use metrics to “Sell” agile estimation to management

  • or if you are consultant, sell to your client
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s