스크럼 적용 3주째. 폭포수(waterfall) 모델과 같은 선형적인 기존 모델에 기반한 다른 관리 기준과 스크럼의 공정 측정 사이의 점접을 찾는데 시간이 다소 필요했다. 스프린트 계획 회의 없이 PM이 미리 준비한 작업 목록으로 시작한 '스프린트0'에 대해서 회고를 진행해보았다. 얼음을 깨는 일에 대해 다소 우려감이 있어 짧은 시간 동안 맛뵈기로 진행하려고 했는데, 의외로 많은 이야기들이 쏟아져나왔다.  애자일 회고를 읽으면서 리듬감을 중요시하는 인상을 받았는데, 실제로 해보니 한 사람이 너무 오래 이야기하지 않도록 하는 것이 중요한 듯 하다.

4시간의 스프린트 계획 회의를 통해 도출한 작업 목록으로 스프린트 백로그를 구성했다. 제품 백로그에서는 각 스프린트별로 목표를 정한 후에, 목표를 달성하기 위해 팀별로 하위 목표를 작성하게 했다. 팀별 하위 목록은 WBS의 활동(Activity) 수준과 대응시킬 수 있었다. 제품 백로그에는 모든 스프린트에 대해서 활동수준으로만 기록해두었다. WBS 역시 활동 하위의 작업은 미리 계획하지 않았다. 그러나, Critical Path에 걸치는 일들을 알아내야 대략의 마일스톤을 알 수 있기 때문에 작업 목록 초안을 뽑아두기는 했다. 풀에 올려놓고 배정은 하지 않은 것과 같은 모습이다. 스프린트 백로그에서는 활동 하위의 작업(Task)을 도출했다. 더불어 해당 작업(Task)은 이슈 트래커에 할일(todo) 타입의 이슈(Issue)로 등록해서 Eclipse Mylyn (formerly known as Mylar) 연계를 구성했다.

관리 활동에 익숙한 두 사람의 전문가는 너무 촘촘한 관리가 아닌가 하는 의아스런 입장이었다. 글쎄 아직 섣불리 평가하기 힘들지만, 되려 진정한 관리란 이런 것이 아닌가 싶어 아이러니하다. 개인은 가능한 하루 단위로 작업 관리를 하도록 작업을 쪼개었더니, 스스로 진척을 관리하는 것이 향상되는 모습이 눈에 보였다. 처음에는 팀원 모두가 스프린트 계획 회의에 참여하는 것이 지나친 시간 소모가 아닐까 싶었는데 그렇지 않다. 되려 그 시간에 심도있게 논의를 하면서 보낸 것이 마치 오래도록 일을 해온 경험자 같은 입장을 만들어주었다. 이런 판단은 분명 성급한 것일 수 있지만, 스프린트를 거듭할 수록 성숙도가 눈에 띄게 높아질 것 같다. '예상치와 팀의 실제 수행 능력'의 오차를 조기에 확인할 수 있다는 점과 사전에 예상하지 못했던 작업들을 쉽게 찾아낼 수 있다. 

회고에 대한 글이 올라와서 추가(4/3): Retrospectives Delayed