지난 글 에서 저는 Smoke Testing 을 통해 엔라이즈의 개발 팀이 신속하고 핵심적인 테스트를 통하여 빠르고 안정적인 앱 배포 사례를 소개 하였습니다. 이번 글에서는 우리가 정확한 일정 추정을 위해 어떤 노력을 기울이는지 이야기 해 볼까 합니다.

정확한 일정 추정을 위하여

일반적으로 한 번의 배포를 위해 수행하는 개발 과정은 다음과 같습니다.

가설 수립 - 기획 - 디자인 - 개발 - 테스트 - 배포 - 분석

엔라이즈 제품 팀은 이 일련의 과정에서 일정의 불확실성이 가장 높은 단계를 개발 과 테스트 로 판단하고 있습니다. 이 중 테스트 과정은 지난 글에서 소개한 Smoke Testing 이라는 테스트 방법을 통해 불확실성을 어느 정도 통제 가능한 수준으로 만들었다고 보고 있습니다. 또한 개발 과정의 경우 아래 소개할 다양한 방법을 통해 정확도를 최대한 정교하게 끌어올리고 있습니다.

엔라이즈 제품 팀에서 제품 개발 일정은 전적으로 개발 팀이 추정하여 그 일정대로 수행되며, 지난 1년 간 제품 팀의 제품 책임자(Product Manager) 가 판단하는 일정 준수의 체감 정확도는 90% 에 달합니다. 실제 대부분의 일정 추정은 10% 이내의 오차로 배포가 이루어집니다.

정확한 일정 추정의 중요성에 대해

일정 추정은 결국 하나의 약속입니다. 만일 이 약속이 잘 지켜지지 않을 경우 기획 팀과 개발 팀의 의사 소통을 방해하는 큰 저항으로 다가오게 됩니다. 다음과 같은 상황을 한 번 가정해 보도록 하겠습니다.

• 기획 파트에서 제안된 기획안을 개발 팀에서 리뷰 한 후 2주일이 걸릴 거라 예상합니다.
• 그러나 개발 팀이 실제로 개발을 하는데 3주일이 소요 되었습니다.

만일 위와 같은 상황이 반복적으로 일어날 경우 기획 팀에서는 개발 팀이 추정하는 일정을 신뢰하지 못하는 상황으로 이어질 위험이 있습니다. 극단적으로는 “개발 팀이 제시하는 일정에 무조건 1.5를 곱해. 그게 실제 개발 팀의 일정이 될 거야” 식의 확증 편향 으로 이어질 수 있습니다. 이는 개발 팀과 기획 팀의 불화를 일으킬 수 있는 불씨가 될 수 있습니다.

기획 팀과 개발 팀의 원할하지 못한, 신뢰도가 떨어지는 소통을 한다면 좋은 제품이 나올 수 있는 근간이 흔들리게 됩니다. 우리는 정확한 일정 추정이 팀의 생산성을 극대화 하기 위한, 가장 기본적인 필요 조건이라고 생각합니다.

다만 정확한 일정 추정은 말 그대로 추정 일 뿐입니다. 추정이 정확하게 이루어지지 않았다는 것은, 말 그대로 일정 추정의 실패일 뿐입니다. 일정 추정이 잘 되지 않더라도 팀은 다양한 상황에 유연하게 적응, 대처할 수 있어야 합니다. 엔라이즈 제품 팀은 급작스러운 스케쥴 변경에도 유연하게 대응하는 팀이며, 이에 대해서는 다른 글에서 다루어 보도록 하겠습니다.

정확한 일정 추정의 방법

정확한 일정 추정이 유지되기 위해서는 지속적으로 끊임없이 노력해야 합니다. 이는 익스트림 프로그래밍에서 언급하는 “운전하는 법 배우기¹” 와 같다고 생각합니다. 한 번의 급진적이고 전면적인 변화가 아닌, 작지만 지속적인, 그리고 끊임없는 변화가 필요한 부분이라고 생각합니다. 엔라이즈 제품 팀이 정확한 일정을 추정하기 위해 이용하는 방법들 중 중요하다고 판단하는 것은 플래닝 포커와 회고 입니다.

1. 플래닝 포커

플래닝 포커의 가장 큰 장점이라면 의사 결정에서의 앵커링을 효과적으로 차단 할 수 있습니다. 또한 스스로 생각하지 못하는 요인들에 대해 깨닫고, 더 정확한 판단을 끌어낼 수 있습니다.

우리는 2009년에 인사이트 출판사에서 제작한 플래닝 포커 카드를 가지고 있습니다. 그리고 모든 개발 일정은 플래닝 포커를 통해 추정합니다. 플래닝 포커는 경험적으로 굉장히 정확한 일정을 추정하게 해 주는 훌륭한 방법이나, 몇 가지 주의해야 할 점이 있습니다.

앵커링은 여전히 발생할 수 있습니다.

정말 다양한 이유로 인해 앵커링은 여전히 발생할 수 있습니다. 몇 가지 사례를 언급해 보자면 다음과 같습니다.

• 팀원의 성격 자체가 개인의 의견을 강하게 주장하는 것을 싫어하여, 만일 다른 일정 추정이 나왔을 경우 본인의 의견을 바로 부정하고 상대방의 의견을 수용해 버리는 상황
• 자신이 생각하는 일정에 대한 추정이 아닌, 상대방의 추정 일정에 자신의 추정 일정을 맞추려 하는 상황

공통적으로 수동적이거나, 플래닝 포커에 익숙치 않은 분들이 저지르는 실수입니다. 플래닝 포커를 주도할 때는 팀원들의 이런 상황들을 섬세하게 확인하여 위의 사례와 같이 수동적으로 일정 추정을 하려 하는 사람이 있을 때 즉각적으로 해결할 수 있어야 합니다.

팀원 간 생각을 긴밀히 조율할 필요가 있습니다.

A 라고 하는 하나의 기능 구현 작업이 있을 때, 어떤 팀원은 일정 추정을 A 기능 구현 전체로 추정을 하려 하고 다른 팀원은 A 기능을 a, b, c 로 나눈 후 각각에 대해 일정 추정을 시도하려 할 수 있습니다. (만일 현재 팀원이 이런 상황이라면 당장 플래닝 포커를 도입해야 한다고 생각합니다.) 즉 플래닝 포커를 이용하는 팀 수준에서 정의되는 ‘일정 추정을 위한 최소 단위의 규모’ 가 합의되어야 합니다.

엔라이즈 개발 팀은 2012년부터 플래닝 포커를 도입하였으며 그 시간만큼 다양한 규모로 일정 추정을 시도해 보았습니다. 경험적으로 보았을 때 ‘일정 추정을 위한 최소 단위의 규모’ 가 지나치게 커지면 일정 추정의 불확실성이 높아졌으며, 지나치게 작아질 경우 추정 일정이 과대 평가되었습니다. 여기엔 정답이 없습니다. 팀원 간 플래닝 포커 경험이 많아질 수록 자연스럽게 ‘일정 추정을 위한 최소 단위의 규모’ 가 잘 정의되고, 그에 맞추어 추정 일정의 정확도가 상승합니다.

2. 회고: 일정의 과소/과대 추정을 막기 위해, 그리고…

저는 일정 추정이란 결국 휴리스틱한 의사 결정 과정이라고 생각합니다. 그리고 일정 추정의 정확도를 올린다는 것은 경험적 직관력을 올리는 것과 같다 생각합니다. 따라서 지속적인 회고는 플래닝 포커와 동전의 양면과도 같은, 따로 생각할 수 없는 중요한 부분이라고 판단하고 있습니다.

또한 플래닝 포커는 당연하지만, 은탄환 이 될 수 없습니다. 정말 너무나도 많은 이유로 추정된 일정은 실패하기 마련이며, 대부분은 일정이 과소/과대 추정되었기 때문입니다. 이 때 지속적인 회고와 회고의 결과로 도출된 결론이 되먹임(Feedback) 되지 않을 경우 일정 추정의 정확도는 절대 오르지 않습니다.

일정을 과소/과대 추정하는 팀원에게는 지속적으로 과소 추정하는 것에 대한 원인 분석을 진행해야 합니다. 그렇다면 일정을 정확하게 추정하는 팀원은 완전한 것일까요? 저는 그렇게 생각하지 않습니다. 추정한 일정을 높은 확률로 정확하게 수행하는 팀원은 “몰입 구간"에 있을 수도 있겠지만, “지루함의 영역"에 있을 수도 있습니다. 여기에 대해서는 당신이 제자리 걸음인 이유 : 지루하거나 불안하거나 를 참고하시기 바랍니다.

우리는 플래닝 포커로 추정된 일정을 실제로 수행해 보고, 배포가 끝난 후 회고를 통해 어떤 부분을 더 개선해야 하는지, 만족스러웠던 점과 불만족스러웠던 점에 대해 지속적으로 토론합니다. 서로 간에 지속적인 자극을 통해 생산성을 높이기 위한 다양한 방법들에 대해 이야기를 나누고, 이는 다시 플래닝 포커를 통한 일정 추정에 반영됩니다.

마치며

2012년에 도입한 플래닝 포커는 정확한 일정 추정에 있어 언제나 중요한 역할을 담당하고 있습니다. 첫 도입 때의 낯설음을 견디면서 지금까지 꾸준히 수행한 결과 일정 추정의 정확도는 언제나 만족스러운 결과를 보여 주었으며, 제품 팀이 생각하는 개발 일정에 대한 신뢰도는 매우 높습니다.

기획 팀은 개발 팀의 일정 수행 능력에 대한 신뢰도를 바탕으로 더욱 재미있고 흥미로운 가설들을 시험할 수 있고 개발 팀은 불확실한 일정 추정으로 인한 불안감 없이 개발 작업을 수행합니다. 정확한 일정 추정을 위해 고민하고 있는 분들이 계신다면 이 글을 통해 조금이나마 도움이 되었으면 좋겠습니다.

우리 팀에 흥미를 가진 개발자를 찾고 있습니다! 관심 있는 분들의 지원을 기다립니다. :)

감사합니다.