Sprint는 Scrum의 큰 특징 중 하나지만, 내가 방법론 담당자였을 당시 애자일 문외한이었던 프로젝트 팀원들에게 설명하기 매우 어려웠다. 뭐가 어려웠냐면 당시 내가 속한 조직에서는 Sprint는 곧 Incremental 개발이었는데 이게 뭐가 좋은건지 도무지 납득을 시킬 수가 없었다. 나도 납득이 안되는데 좋다고 설득하자니 마음이 불편했다.
Incremental 개발은
Waterfall 방식 개발과 본질적으로 같다
Incremental 개발은 작은 Waterfall이 여러 개 연달아 있는 것 뿐이다. Waterfall 개발과 Incremental 개발은 둘 다 마치 모짜르트가 자기 머리 속에서 완벽하게 음악을 작곡하고 악보에 한번에 옮겨적은 후 조금도 수정하지 않았듯이, 설계하고 개발해버린건 다시는 건들지 않는다. 오직 결함이나 요건변경이 있을 경우만 재개발을 한다. 재개발은 금기이고 악이며 실패 그 자체이다. 조직은 재개발을 예방하기 위하여 어마어마한 리소스를 투입해가며 노력을 아끼지 않는다.
굳이 찾아보자면 Waterfall에 비해 Incremental이 사업관리가 빡쎄게 진척 관리하기 편하다는 장점이 있다. (이럴라구 애자일했나 자괴감 들어)
정확하고 완벽한 설계를 전제로 한다
정확하고 완벽한 설계를 한다는 말은 지금 하려는 일에 대해 니가 모짜르트 급이어야 한다는 소리다.
고객이 피드백을 주기 어렵다
위 장표의 모나리자 그림을 보자. 지금 단계가 1번 단계라면 고객은 모나리자 마빡만 보고 할 수 있는 말이 거의 없다. 좀 더 진도나간 다음에 봅시다 정도 밖에 얘기할 수 없다.
고객의 피드백을 반영하기 어렵다
물론 이번 스프린트에서 나온 피드백 중 다음 스프린트에 반영할만한게 있을 수 있다. 하지만 기본적으로 피드백의 대상은 이번 스프린트에서 개발한 것이고, 그 피드백의 반영은 곧 재개발을 의미한다. (근데 우리한테 재개발은 금기이고 절대악이며 실패 그 자체잖아… 고객이 “이미 개발 끝난 것들은 어쩔 수 없죠. 앞으로 개발할 것들만 잘 해주시면 돼요”라고 말 할 리도 없는데 큰일 난거다)
작은 결론
이 정도 흉내로는 효과를 기대하기 어렵겠다
한편
Iterative 개발은
계속 재개발한다. Iterative 개발에서 재개발은 금기도 아니고 악은 더더욱 아니며 결코 실패가 아니다.
Incremental 개발과 Iterative 개발은 사용자 스토리부터 달라질 것이다
