보나님이 페북에 올린글 Stop Using Story Points 를 읽으면서 번역은 아니고 요약을 좀 해봤습니다.
스토리 포인트는 스프린트 처럼 애자일 하면 떠오르는 용어다. 2007년 의도적으로 스토리 포인트와 개발속도를 적용하지 않으면서 애자일적인 특징을 높히기 위한 실험을 했던 적이있다. 이 실험에서 고정 길이 스프린트(fixed-length-sprint)는 흐름 기반의 워크플로(flow-based workflow)로 바꾸고 일일 스크럼은 잦은 팀 미팅(frequent team huddles)으로 바꿔 진행했다. 프로세스에서 낭비되는 부분을 적극적으로 바꾸다보니 우리의 프로세스는 책에서 말하는 애자일과 사뭇 다르게 보이기도 한다. 그럼 왜 스토리 포인트 사용을 그만둔걸까?
스토리 포인트를 처음 접했을때
1999년 스타트업에서 일할때는 나도 팀의 개발속도를 나타내는 스토리 포인트에 매혹되어 있었다. 관리자들에게도 좋고 팀원들에게도 좋고, 중요도가 떨어지는 기능을 선별할때 특히 유용했다. 스프린트내에 주어진 작업이 끝나면 꼭 필요한 기능(must-have)와 있으면 편리한 기능(nice-have)를 고민하면 되었다.
그 후 난 8년간 스토리 포인트를 써왔고 그러면서 많은 오해와 잘못된 사용경험을 알게되었다. 처음에는 이런 문제를 사람들에게 더 나은 교육을 진행해야 한다는 징후로 이해했다. 하지만 몇년이 지난뒤 스토리 포인트와 개발속도에 깊은 결함이 있음을 알게되었다.
비 이성적인 스토리 포인트의 증가
큰 문제가 있음을 처음 알게된것은 2001년 대형 프로젝트에서다. 첫번째 팀은 완전한 애자일로의 전환을 목표로 하는 우리가 만나봤던 최고의 준비된 팀이었다. 이팀은 2년뒤 기한내 높은 성과를 낸 공로로 보너스와 시상을 받았다. 하지만 이 팀은 그 이후에 더 높은 생산성을 요구받게 된다. 이 팀의 평균 개발속도가 52였는데 80으로 높히라는 요구였다. 어떻게 했냐고 물으니 이런 대답을 들었다. "요즘 여기서는 재채기만 해도 스토리 포인트로 잡아요."
개발속도가 빨라진것처럼 보이기 위해서 스토리 포인트를 얼마든지 오용할수 있던것이다. 이 경험은 스토리 포인트에 대한 나의 믿음을 약화시켰다. 하지만 한편으로 이런 생각을 했다. 문제는 교육이 충분치 않았던게 아닐까? 2004년 스토리 포인트 사용을 그만두기까지 나와 내 동료들은 관리자와 스토리 포인트를 잘못 사용하는 사람들에게 두배의 노력으로 교육을 진행했다.
예측가능성을 위해 품질을 희생하다.
추정을 맞추기 위해서 하는 첫번째 작업이 TDD나 리팩토링을 생략하는 것이다. 품질을 희생하면서 납기일을 맞추려는 팀을 자주 봤다. 수년동안 수강생들이 품질높은 코드를 가진 기능을 배포하는게 어떻다는것을 경험하도록 도우면서 이 공통적인 문제를 역설했다.
위대한 팀들이 일관된 개발속도를 유지하면서 동시에 기술적으로 뛰어난 팀이라는 사실을 설명했다. 이 내용은 사실이지만 그런팀은 드물었고 일관성은 팀 크기가 변하거나 외부의 압력때문에 변하곤했다.
더 많은 해가 지난뒤 일관된 개발속도를 유지하는게 예측이나 추정을 하는데도 도움이 되기 때문에 중요하다는 생각이 들었다. 그럼에도 많은 팀들이 품질을 희생하고 기술적인 빚을 지고 예쁜 소멸차트를 유지하려한다.
포인트로 팀 비교하기
몇년뒤 서로 다른회사에서 일하는 몇명의 관리자들이 이렇게 말하는것을 들었다. "왜 팀X는 스프린트마다 24 스토리 포인트를 처리하는데 팀Y는 12 스토리 포인트밖에 못 끝내지? 팀크기는 같은데 말야 왜 차이가 나는걸까?" 이 관리자들은 개발속도를 팀의 역량에 대한 지표로 보기보다는 성과측정의 지표로 간주하는 함정에 빠진 것이다. 교육할때 팀을 개발속도로 비교하지 말라고 하지만 많은 사람들이 그런 비교를 당연하다고 여기는게 실제로 문제가 된다.
2005년도에는 팀마다 스토리포인트를 좋아하는 과일로 부르도록 함으로서 이 문제를 처리해보려 했다. 한 팀은 개발속도를 오렌지로 다른 팀은 사과, 또 다른팀은 키위 이런식으로 부르게 했다.
그러고 나서 관리자가 팀간의 개발속도를 비교하려 할때 나는 이렇게 말했다. "사과와 오렌지는 비교할수 없어요"
과일을 이용한 접근이 팀간 개발속도 비교를 지적하는데 도움은 되었지만 스토리포인트를 잘못 사용하지 않도록 하는것보다는 더 단순하고 에러가 생기지 않는 방법을 쓰는게 더 낫지 않을까 하는 생각이 드는것은 어쩔수 없었다.
스토리 포인트 혼란: Are We NUTs?
많은 사람들이 스토리 포인트를 사용하는게 정당하다고 하는데 그렇게 말하는 이유가 사람들이 실제 시간을 이용해 추정하는데 익숙치 않기 때문이라고 말한다. 그렇게 말하는 이유로서 실제로 작업을 완료하는데 걸리는 시간을 추정하는것보다 작업의 크기를 추정하는게 더 낫기 때문이라고들 말한다.
사실 사람은 무슨 측정단위를 사용하느냐와 무관하게 보통 추정에 익숙치 않다.
나중에 보여주겠지만 자주 재추정을 할때가 더 나은 추정을 하게된다.
스토리포인트는 이슈를 더 혼란에 빠뜨릴 뿐이다.
시간을 이용해 추정할때 생기는 질문들은 스토리 포인트에서도 똑같이 생긴다.
이런 것들을 이용하기 위해서 우리가 배워하는 것은
- 그것들이 무엇이고
- 어떻게 사용하고
- 그것들을 잘못 사용하지 않는 많은 방법이 있는지
스토리 포인트에 대한 대부분의 교육에서는 사람들간의 저항을 잘 다루는 방법을 가르친다.
신참들은 스토리 포인트를 가지고 추정하는것에 불편함을 느끼기 때문에 스토리 포인트를 실제 시간으로 자주 맵핑해준다.
의미를 잘 아는 애자일 전문가들은 초심자들을 교육시키는데 최선을 다한다. 어떻게 스토리 포인트가 티셔츠 크기나 피보나치 수열에 해당하는지를 설명한다.
2005년 우리 고객중 한명은 스토리 포인트가 혼란스럽다고 NUTs(Nebulous Unit of Time)라고 이름을 바꿔버렸다.
스토리포인트에 대한 잘못된 이해와 사용은 시간이 갈수록 커진다. 특히 하나의 프로세스 처럼 팀에서 부서로 다시 회사전체로 확산된다.
이런 잘못된 이해와 오용을 바로잡으려면 시간과 에너지가 들어간다. 스토리 포인트와 개발속도를 계산하는 일은 애자일을 처음 시작하는 팀에게 불필요한 혼란을 야기시키는 부자연스러운 기법이다.
요약으로 시작했느데 하다보니 번역이 되네요. 이놈의 직업병은 어쩔수 없는걸까요. 글이 길어서 나머지는 다음번 포스트에 계속하겠습니다.
rc172-010d-HTTP_0.pdf
