Martin Fowler씨가 자신의 블로그에 Extreme Programming에서의 계획수립에 관한 글을 썼습니다. 어제는 회사체육대회를 했는데 쉬는 시간 짬짬히 번역해 봤습니다.
5 파운드짜리 가방에 똥 10 파운드를 담을 수는 없는 일이다.– 그 일을 시도해 본 누군가가
Kentii와 내가 Planning Extreme Programming을 저술할 때, 독자들이 계획수립의 본질을 이해하는 것을 돕고자 웃긴 인용문을 포함시켰다. 소프트웨어 개발에 있어 가장 큰 어려움 중 하나는 사람들이 제한된 시간 내에 실질적으로 이뤄질 수 있는 일이 무엇인지 정확히 모른다는 점이다. 우리는 가방 하나에 너무 많은 기능iii이 쑤셔넣어지는 것을 목격한다. 그런 기능들이 가방 하나에 들어갈 수 있는지 여부는 고려하지 않은 채 말이다. 사람들이 바라는 바는 큰데 비해 가방은 보통 너무나 작기 마련이다. 내가 Kent의 계획수립법에서 가장 좋아하는 것 중 하나는 문제를 다루기 위한 간단한 메카니즘을 제공한다는 점이다.
원리는 매우 간단하다. 프로젝트에 주어진 기간을 주기iv로 나눈다. 요구되는 기능들을 특성v로 나눈다. (XP에서는 스토리vi라고 부르길 좋아한다.) 각각의 특성을 완성하기 위해 얼마의 일을 해야 하는지 예측한다. 각 주기마다 어느 정도의 일이 진행되었는지 추적하고, 다음 주기에 적정량 이상의 특성을 추가하지 않는다. XP의 출시 주기는 어떤 주기에 어떤 특성을 추가할 것인지를 결정하는 것이라고 할 수 있다.
다른 여러 일들과 마찬가지로, 이것은 인간중심적인 프로세스vii이다. 최근의 컨퍼런스에서 내 동료 Tim Mackinnon는 개발팀과 몇몇 고객사측 사람들viii이 공동의 공간에서 작업했는데, 그것이 실질적으로 이뤄질 수 있는 일이 무엇인지 파악하는데 크게 도움이 되었다고 했다. 고객사측 사람들은 자신의 업무를 했다. 하지만 공동의 공간에서 격의없는 대화를 나눌 수 있었던 것이 결정적으로 도움이 됐다고 한다.
사람들은 흔히 Agile 방법론의 특징으로 반계획적ix이라는 점을 꼽는다. 하지만 내가 XP의 초보단계를 넘어갔을 때, 가장 인상 깊었던 점이 계획수립의 높은 수준이었다. 특히 계획수립의 본질상, 그 결과에 직면하기 전에 원래 계획에 없던 특성들을 프로젝트에 추가하기 어렵다. 이것이 agile 방법론의 적응적인x 계획수립의 정수이다. – 계획은 자주 변경되지만 제어가능한 범위 내에서 변경된다. 만약 어떤 특성을 추가하고 싶다면, 반드시 특성이 들어갈 공간을 마련하기 위해 무엇을 해야 하는지 생각해야 한다. 만약 그러한 고려없이, 그리고 특성이 들어갈 공간도 없는데 프로젝트에 추가되는 특성을 보게 된다면 그 계획이 망해가고 있다고 결론 내릴 수 있다.
역자 주:
- 원문: FivePoundBag
- Kent Beck 을 말한다.
- 원문: functionality
- 원문: Iterations
- 원문: features
- 원문: stories
- 원문: human process
- 원문: traders
- 원문: anti-planning
- 원문: adaptive
