1.
Scrum은 XP(eXtreme Programming)와 거반 다를 게 없더라. 어찌보면 XP의 단순화 버전으로 느껴지기도.
MS의 공식 가이드 문서를 보면 Scrum과 XP의 비교에 XP는 공학적 실천지침(Engineering Practices)에 중점을 둔 반면 Scrum은 포괄적 프레임워크(overarching framework)가 강하다라고 설명했는데, 둘 간에 뭔 차이를 나타내는지 잘 몰겠다. 뒤에 프로세스를 포괄적 프레임워크를 예로 드는데, XP에도 제시되는 프로세스가 엄연히 존재하는걸(http://bit.ly/bpQyT3)..
위 공식 문서 링크는 한글판인데, 번역의 문제가 여기서도 여지없이. 위의 Engineering Practices나 overarching framework 등은 키워드인데 이를 각각 '엔지니어링 방법', '핵심 프레임워크'라고 번역해놨다. '방법'이라 해놓으면 그 유명한 XP의 12개 practice를 가리키는 것이라 누가 알겠는가. 아흐...
2.
Planning Poker란 델파이와 매우 유사한 기법을 통해 각 사용자 스토리(일종의 작업 항목)의 필요 노력을 공통으로 예측하는데, 이 단순한 절차 뒤에 담긴 이유가 매우 의미있다. 핵심은 각기 다른 예측치의 근거를 발표하여 숨겨진 위험 및 핵심 요소를 드러내고 팀원간 컨센서스를 이루는 데 있다고.
3.
TFS(Team Foundation Server) 뿐 아니라 MS Office와도 유기적으로 통합된 Visual Studio 기반으로 도구 지원이 환상적이다. 복잡한 MS Project가 아니라 친근한 Excel을 통해 WBS(Scrum에서는 User Story, Task 등으로 구분하여 표현)을 관리하는 것 자체도 맘에 들지만, 무엇보다도 팀 구성, 일정 예측/계획, 상태 관리 뿐 아니라 그래프 기반으로 상태 리포팅까지 Excel 만으로 가능하다는 게 아주 굿..
따라서 이러한 정형적 프로세스 도입 시에 가장 문제가 되고 필연적으로 부가되는 '개발 흐름의 단절'을 최소화하는 데 딱이다.
4.
본 Scrum이 제시하는 예측-계획-측정-검토의 프로세스 세밀화 수준, 본 수준이 #3와 같은 고수준 자동화 도구와 밀접히 연계되다 보니 개발 프로세스 실행의 투명성 수준이 무시무시하게 올라가게 됨은 뻔히 보인다.
사실 진짜 하고 싶었던 이야기는 바로 이거
#4에서 이야기한, 개발 프로세스 실행에 대한 투명성의 증대. 이게 사실 양날의 검인데, 본 도구를 잘못 도입/사용하다가는 애먼 팀원이 엄청 고생하게 됨과 동시에 나아가 거시적으로 보면 해당 프로젝트 전체를 망치는, 즉 필요 작업 시간만 길어질 가능성이 높다는 이야기이다. 관리자가 본 도구를 팀원의 '감시'도구로 악용하는 상황을 말하는 바다. 투명성이 극대화되므로 팀원이 빠져나갈 구멍이 없어지는 것이다. 또한, 이와 같이 '감시' 상황의 압력을 받는 팀에서는 Planning Poker 등의 작업 예측 단계에서도 자신의 실제 예상치와는 다른 값을 내놓게 될 터인데, 이와 같이 프로젝트 성패를 좌우하는 기반 가정의 정확도가 낮아져 결과적으로 프로젝트의 위험 수준이 증대한다는 사실.
그러나, Agile 구루들이 바보들인가, 위와 같은 상황을 미리 예상 못했게?
Agile 내 scrum과 동일 분파인, XP의 핵심 가치(value)를 되새겨보자. 소통, 단순성, 피드백, 용기, 존경. 이중 마지막 존경(respect)에 주목할 필요가 있다. 이는 관리자를 포함한 팀원 간의 상호 믿음, 존경을 뜻한다. 이를 위 상황에 비춰 풀어보면 관리자가 팀원을 '감시'하기 위해 도구를 사용하는 것이 아니라는 뜻이다. 오히려 서로 간의 상태를 팀원 간에 최대한 알려, 도움과 피드백 등 긍정적 부가 활동을 위한 도구로 사용하라는 뜻이다. 또한 팀원의 입장에서의 본 '존경'은 팀원이 자신이 수행하는 프로젝트에 자발적인 마음으로 임해야 한다는 뜻이 되기도 한다. 한마디로 표현하자면, 위 도구/템플릿을 통해 성공적으로 프로젝트를 이끄려면 팀원 간에 '믿음, 존경'이 필요하다는 말이다.
Scrum이나 Agile Manifesto에는 respect라는 어휘가 직접적으로 언급되지는 않는다. 하지만 Manifesto 안에 본 개념이 충분히 녹아 있음을 부인할 수 없다. 이를 명시하는 이유는 위 논의에서 Scrum 성패의 조건으로 respect를 들었는데, 그 근거를 모태 격인 Agile이 아닌 동일 수준의 분파인 XP에서 찾았기 때문이다.
사실, Scrum이니 XP니 해서 본 영역에 특화된 무엇이라고 볼 것도 없는 것이, 어느 조직, 어느 프로젝트에서는 안그런가. 사람이 모여서 하는 모든 활동이 성공하기 위한 필수 조건은 '믿음, 존경'이 아니었던가. 알고 보면, 뻔한 이야기였다는 말. 짭.
p.s. Scrum에서는 매일 회의를 여는데, 재밌는게 왠간하면 죄다 서서 진행하라고 한다. 왜? 회의 짧게 하라고. 서서 말하고 듣다보면 피곤하기에 짧게 갈 수 밖에 없다나? 또한 짧게 하기 위해 발표 내용에 대해 토달지 말라고 한다. 토달고 싶음 나중에 하라나? ㅋㅋ