User Stories Applied : Chapter 9 이터레이션 계획

이터레이션을 계획하기 위해서는 팀 전체가 이터레이션 계획 회의에 참석해야 한다. 모든 개발자 뿐만 아니라 고객도 회의에 참석해야 한다. 회의에서는 스토리들을 좀더 세부적으로 살펴볼 것이므로 여러 가지 의문이 생길 것이다. 이러한 물음에 답할 수 있는 고객이 곡 참석해야 한다.

스토리 토의

• 프로그래머는 스토리 개발 난이도에 대한 의견을 변경할 수 있다.

• 고객도 스토리의 우선순위를 변경할 수 있다.

• 개발자는 스토리를 세부 작업으로 나눌 수 있을 만큼 충분히 이해할 때까지 질문한다.

• 스토리의 모든 세부 사항을 완전히 이해할 필요는 없으며 오히려 각 스토리를 너무 깊이 다르다 보면 회의가 길어질 수 있다.

작업 단위 나누기

스토리가 충분히 작아서 그 자체를 업무 단위로 사용할 수 있더라도, 더 작은 하위 작업으로 나누는 것이 일반적으로 더 효과적이다.

애자일 프로세스에 대한 비판 중 하나는, 폭포수 모형 프로세스에 있는 것과 같은 코딩에 앞선 사전 설계 단계가 없다는 점이다. 그것이 사실이긴 하지만, 대신 애자일 프로세스에서는 설계를 자주, 신속하게 한다. 스토리를 작업들로 나눈 것은 최소한의 설계가 머리 속에 그려질 때 가능하다. 이 과정은 폭포수 모형의 사전 설계를 대체하는 신속한 적시 설계의 예라고 할 수 있다.

스토리는 이미 충분히 작기 때문에 굳이 적절한 작업 크기까지 지침으로 제시할 필요는 없을 것이다. 다만, 스토리를 작업으로 나눌 때 다른 지침을 따른다면 도움이 될 것이다.

• 스토리를 구성하는 작업 중에서 특히 추정하기 어려운 작업이 있다면, 해당 작업을 스토리의 다른 부분들과 따로 분리한다.

• 다른 개발자와 나누어 진행할 수 있는 작업이 있다면 나눈다.

• 스토리의 일부분만 완료되어도 도움이 된다면, 그 부분을 별도의 작업으로 나눈다.

책임 맡기

• 한 스토리를 구성하는 작업들을 모두 찾고 나면, 개발자는 각 작업에 대해 자발적으로 책임을 맡는다.

• 짝 프로그래밍을 하는 경우라도 작업의 책임은 한 사람이 맡도록 한다. 그리고 이 사람이 해당 작업을 완료하는 책임을 가진 것으로 가정한다. 고객에게서 추가 정보가 필요해도 이 사람이 요청하여 얻는다.

추정과 승인

팀의 속도가 이터레이션 당 스토리 점수 40점이면, 앞의 절차들을 우선순위가 높은 스토리부터 스토리 점수 합이 40점이 될 때 까지 진행한다. 그런 다음 각 개발자는 자신이 책임을 맡은 작업들의 작업량을 추정한다. 이 때도 물론 이상적 작업 시간으로 추정하는 것이 가장 좋은 방법이다.

자신이 맡은 작업들의 추정을 마쳤으면, 추정치를 모두 더한 다음 이터레이션 안에 모두 완료할 수 있을지 현실적으로 평가해야 한다. 만일 완료할 수 없는 경우라면 다른 개발자가 자신의 업무 부담을 평가해 본 뒤 나의 작업 중 일부를 맡을 수 있다고 하면 그쪽으로 책임을 넘긴다. 하지만 작업을 넘겨 받을 수 있는 여력이 아무에게도 없는 경우에는 고객이 나서서 일부 작업을 이번 이터레이션에서 제거하는 방식으로 도와주어야 한다.