초기 탐색
개발자는 스토리를 추정하려고 시도하지만 이 추정은 절대적인 것이 아닌 상대적인 것이다. 이런 상대적인 비용을 표현하기 위해 스토리 카드에 그 스토리의 몇몇 포인트를 적는다. 각 스토리 포인트가 어느정도의 시간이 필요할지는 모르지만 대략적으로 스토리 포인트의 양을 통해 어떤 스토리가 더 비용이 클지 알 수 있다.
스파이크, 분할, 속도
너무 크거나, 작은 스토리는 추정하기 어렵다. 그렇기에 너무 큰 스토리는 분할하고, 너무 작은 스토리는 다른 작은 스토리들과 합쳐야 한다. 당연하게도 스토리가 분할되거나 합쳐지면, 다시 그 스토리를 추정해야 한다. 분할해도 포인트가 더 많아지는 경우도 있는데 아주 자연스러운 일이고 더 많아진 포인트가 정확한 추정인 것이다. 그런데 이러한 분할 여부도 상대적인 추정에 기반하기에 결정하기 쉽지 않다. 스토리의 정확한 크기를 알기 위해서는 속도라는 요소가 필요하다. 정확한 속도를 알면 스토리의 추정에 그 속돌르 곱해 실제 소요 시간 추정 결과를 알 수 있다. 프로젝트가 진행됨에 따라, 이전 반복에서 완료한 스토리의 포인트 수를 측정할 수 있기에 속도는 점점 정확하게 측정된다. 일반적으로 며칠만 투자해도 한 두개의 스토리로 프로토타입을 만들어보면서 팀의 속도를 측정할 수 있는데 이러한 프로토타입 단계를 스파이크라고 한다.
릴리즈 계획 세우기
주어진 속도를 기준으로 고객은 각 스토리에 들 비용을 알 수 있다. 이러한 각 스토리의 비용과 사업적 가치와 우선순위를 바탕으로 먼저 완료할 스토리를 선택하는 것이 업무 의사 결정이다. 당연하게도 비용 대비 효과가 가장 큰 스토리를 먼저 선택해야할 것이다.
개발자와 고객은 프로젝트의 첫 번째 릴리즈 날짜를 정하는데 보통 2~4달 정도이다. 이런 릴리즈 계획은 속도가 점점 정확해짐에 따라 조정될 수 있다.
반복 계획 세우기
개발자와 고객은 반복의 크기를 정해야 한다. 일반적으로 2주 정도를 잡는다. 그리고 고객은 해당 반복에 구현되었으면 하는 스토리를 선택한다. 물론 현재 속도를 고려하여 범위 내에서 선택해야 한다. 이러한 반복 안에서 스토리 순서를 결정하는 것은 기술적인 결정이다. 이러한 결정은 당연히 개발자의 몫이다. 반복이 시작되면 고객은 그 반복의 스토리를 바꿀 수 없다. 하지만 그 외의 스토리를 자유롭게 변경하고 순서도 바꿀 수 있다.
모든 스토리의 구현이 완료되지 않은 경우에도 반복은 정해진 날에 끝난다. 그리고 완료된 스토리의 추정 소요 시간을 모두 더해 반복의 속도를 계산한다. 그리고 다음 반복의 계획을 세우는데 이용한다.
태스크 계획 세우기
개발자는 스토리를 분할해 개발 태스크로 만든다. 이때 태스크는 한 개발자가 4~16시간 동안 구현할 수 있는 것이 되게 정한다. 그리고 개발자는 구현하려는 각 태스크에 하나씩 참여하여 작업하고 그 태스크를 임의의 태스크 포인트로 추정한다. 이때 개발자는 어떤 종류의 태스크든 참여할 수 있다. 개발자가 전체 프로젝트에 대해 더 알게 될수록 프로젝트 팀은 더욱 탄탄해지고 더 많은 정보를 공유하게 될 것이다. 즉 전문성과 관계없이 이러한 정보들이 팀 내에 퍼지게 되는 것이다.
각 개발자는 최근 반복에서 자신이 구현한 태스크 포인트 갯수를 인지하고 있을 것이며 그것이 바로 그들의 개인적인 예산이다. 어떤 팀원도 자신의 예산보다 많은 포인트에 참여하지 않는다. 태스크 선택 과정은 모든 태스크가 다 할당되거나 모든 개발자가 예산을 다 사용할 때까지 계속된다. 즉 서로 태스크를 교환할 수 있다. 혹시라도 태스크를 모두 할당할 여유가 없으면 고객에게 양해를 구하고 그 반복에서 태스크나 스토리를 취소해달라고 부탁해야하고 반대로 여유가 있다면 스토리를 더 달라고 부탁할 수 있다.
반환점
반복이 반쯤 진행되면 팀은 미팅을 가지게 되고, 이때 반복에 계획한 스토리의 반 정도가 완료되어 있어야 한다. 만약 완료되지 않았다면, 팀은 태스크를 재분배하고 반복이 끝날 때 모든 스토리가 확실히 완료되도록 해야 한다. 혹시 이런 재분배를 할 수도 없다면 고객에게 부탁해서 그 반복에서 어떤 태스크나 스토리를 제외할 것인지 결정해야 한다. 반환점에서 스토리의 반이 완료됬는지 확인할 때 주의할 점은 태스크의 완료가 기준이 아닌 스토리의 완료가 기준이라는 것이다. 아무리 많은 태스크를 완료했더라도 스토리를 완료하는 것이 중요하다. 즉 반환점에서 그 반복에 처리할 스토리 포인트의 반을 의미하는 완료된 스토리들을 봐야 한다.
반복
2주마다 반복이 끝나고 현재 동작하는 실행 가능한 부분을 고객 앞에서 시연한다. 그리고 고객은 프로젝트를 평가하고 새로운 사용자 스토리를 통해 피드백을 제공한다. 이렇게 고객은 진행 상황을 수시로 알 수 있고, 속도를 측정할 수 있다. 팀이 얼마나 빨리 프로젝트를 진행할 수 있을지 예측 가능하고 우선순위가 높은 스토리를 빠르게 처리하도록 일정을 잡을 수 있게 된다. 그들이 원하는대로 프로젝트를 관리할 수 있게 되는 것이다.
결론
이러한 반복에서 반복으로, 릴리즈에서 릴리즈로의 과정을 통해 프로젝트는 예측 가능해지고 이해당사자는 자주, 그리고 충분히 진행 상황을 파악할 수 있게 된다. 직접 보며 피드백을 제공할 수 있는, 동작하는 소프트웨어를 보여주는 것이 훨씬 바람직하다. 개발자는 스스로 추정한 소요시간에 기반하여 스스로 측정한 속도로 합리적인 계획을 알 수 있고, 편한 마음으로 작업할 태스크를 선택하여 자신의 기량을 최상으로 유지할 수 있다. 관리자는 각 반복마다 데이터를 얻고 그 데이터를 이용해 프로젝트를 제어하고 관리할 수 있다. 주의할 점은 이런것들은 이상적인 이야기가 아니라는 것이다. 이 과정에서 나온 데이터를 보고 언제나 행복할 수는 없다. 애자일 방법을 사용한다고 무조건 이해당사자가 그들이 원하는 것을 얻는 것은 아니다. 그저 최소의 비용으로 최대의 사업상 가치를 얻을 수 있도록 팀을 제어할 수 있게 되는 것일 뿐이다.
