휴... 글 감사합니다. 이 이야기를 하시려고 앞의 글을 적으셨던 거군요? ^^
예전에 시스코에있을때 매니져가 각종 매트릭을 측정하자고해서 별별걸 다 만들어서 아침 스크럼미팅때마다 이야기나누곤 했었는데.. 뭣때문에 저러는지 참 답답했던 기억이 납니다. 아마도 윗선에서 쪼아서 그랬겠지만.. 애자일도 잘 자리잡고 있는 팀이었고.. 프로젝트 관리가 안된다던지 딜레이가된다던지 한적이 없었는데도 그러니까 다들 피곤해 했었습니다. 저는 심지어 매일매일 technical debt 의 갯수와 트렌드를 문서로 업데이트 하기를 요구받았었지요. 알면서도 그런걸 시키는 매니저 입장도 이해는 갑니다만.. ㅎㅎ
한국에서 매니저들은 그것이 자기의 업무라고 생각하는 것 같습니다.
스크럼이 잘 되고 있다면,
메트릭 측정을 하는 팀을 따로 만들면 될 일인데...
개발팀 스크럼 미팅에 이야기를 꺼내면 안된다고 생각합니다.
진짜 스크럼이 잘 되고 있었던 것이었을까요?
항상 잘 되고 있다고 믿는 것에 구멍이 생기기 마련입니다.
어느 누구도 나는 문제 있다고 심각하게 믿지 않기 때문이지요.
Technical debt 갯수는 어떻게 측정하는지 궁금해지네요.
어떤 회사는 COPQ 를 측정하기도 합니다.
저는 개인적으로 스크럼에 회의적인 사람이라.. 어떻게해도 잘되기 어렵다는 생각입니다. 기대치 자체가 낮습니다. 프로젝트 매니져와 회사를 위한것이 개발자를 위한 방식이 아니라서요. 개인적으론 칸반이 훨씬 낫다고 생각합니다. 이번에 드디어 7년만에 스크럼을 탈출하게 되어서 어찌나 신나는지.. ㅎㅎ
technical debt 매트릭은 COPQ랑 거의 같은 개념이었습니다. 개발자귀에 듣기좋은 용어일 뿐이지요.. ^^ 제가 매트릭 만들땐 일단 technical debt 목록을 만들기위해 팀원 한명한명 만나서 미팅을 했습니다. 항목하고, 우선순위, 개선하려면 드는 시간 등을 수집해서 현재 우리팀이 가지고있는 technical debt를 하나하나 user story로 만들었습니다. 초기 매트릭은, 갯수, 해결을위한 예상시간 이고.. 일단 초기 매트릭을 만든 후에는 각자가 시간상의 이유든 커스토머의 이상한 요구사항때문이든 technical debt를 지고있다고 느낄때 스스로 추가하도록 했습니다. A방식으로 할것을 B방식으로 했고 후에 A방식으로 고치려면 x일이 소요되고, 시간이지나면 더 고치기어려워지는지에 대하여 상중하로 매기게 하였습니다. 솔직히 안해도될일을 한것인데.. 나름 호평도 있었습니다. 방송사들의 요구사항이 급작스럽고 복잡하기에 항상 "해야하는방식"을 포기해야하는경우가 많았던 팀이었기 때문에.. 그것들을 목록으로 적어두고 유저스토리로 만들어놓으니, 스크럼미팅 때에 그부분이 언급됨으로써 개발자들에게 힘이 더 많이 실리기도 했고...
스크럼을 하는 이유가 꼭 잘 되기 위해서는 아니고, 문제가 무엇인지 드러내기 위함이지요.
스크럼마스터 교육을 받았을 때, 이건 오히려 심리학에 가깝다는 생각이 들더라고요.
이쪽 분야 사람들 말을 참 이쁘게 잘 만드는 것 같습니다.
"기술적 채무" 뭔가 돈과 연관되어 보이지 않나요?
COPQ 하면 별 관심 없던 경영자들도 채무 하면 관심을 갖기도 합니다.
암묵지의 지식을 드러내 보이는 것은 중요한 일이기는 한데,
인사이트 없이 하는 것은 차라리 머신러닝에 맡기는 게 나을 것 같네요.
ㅎㅎ 공감합니다.
저도 하루짜리 스크럼마스터 교육을 받았는데 개발자는 저랑 다른한사람 둘밖에 없고 전부다 매니져더군요. 무슨 게임하고 소꿉장난 같은거하다가 왔습니다. 풍선불고 카드집만들고.. 매니저들은 우리의 복잡하고 섬세한 일을 저렇게 간단하게 보는구나 하고 황당했던 기억이 납니다. ㅎㅎ
개발자를 최대한 쉽게 대체가능한 존재로 만들기위해 참 많이들 노력하는구나 이런 생각이 많이 들더군요. 반쯤은 성공한것 같기는 합니다.