실용주의이야기(Pragmatic Story)

스크럼을 처음 알게된건 2년전입니다. 미국의 한 컨설팅 업체로부터 "애자일을 엔터프라이즈에 적용하기 위해서는 어떻게 해야하느냐"는 컨설팅에 대한 답이 바로 스크럼+XP 였던것으로 기억합니다. 요즘에는 대부분 이런식으로 애자일을 적용하고 있으며 이를 Generic Agile이라고 부르는거 같습니다.

이후 사내 연구회를 통해 이 책(Agile Software Development with Scrum)을 공부하면서 스크럼이 무엇인지 알수 있었습니다. 책의 내용을 앞에서부터 살펴보겠습니다.

1장

"생산성이 극도로 높은 상태에 이르는 열쇠는 주제 영역에 대해 끊임없이 컴포넌트를 테스트하고, 패키지를 통합했으며, 시스템을 선택적으로 리팩토링하는 활동이었다." - 왜 XP의 실천법이 TDD, CI, Refactoring인지 알수 있는 대목입니다.

"스크럼의 실천법은 겉으로는 잘 드러나지는 않지만 우리 대부분이 잊고 있는 단순하고 보편적인 패턴이다." - 6월 첫주 XP 2008 컨퍼런스에 다녀왔습니다. 제가 들었던 키노트 세션에서 이런 이야기를 했던게 생각나네요. Agile is easy but diffcult. 누구나 금방 알수 있지만 실천하기는 어려운것. 스크럼의 특징 역시 잘 나타내는 말이라 생각됩니다.

2장

"우리 산업이 명시적인 방법론들을 사용할 경우, 통제력 상실과 불완전한 제품 생산을 초래할 것이라는 사실을 이론화하였다." - 지금까지 무거운 방법론을 주로 적용해 온 제 경험에 비추어 본다면 너무나 가슴에 와 닿는 구절입니다. 방법론을 현장에 확산하면서 항상 느끼는 부분이었고 이런 문제를 해결하기 위해 찾은게 애자일이었는데 그게 잘못된 선택이 아니라는 확신이 듭니다.

"스크럼은 경험주의에 바탕을 두고 있기 때문에 이전과 다르게 느껴지고 낯설게 보인다. 계획과 업무 정의에 소모하는 시간이 줄어들수록 관리 보고서를 작성하고 읽는데 소요되는 시간이 줄어든다." - 애자일의 생산성이 왜 좋은지, 문서화에 대한 작업을 왜 지양하는지 잘 설명합니다.

3장

옮긴이 의견에 보면 "약간 다르더라도 하지 않는것이 좋다."는 부분이 있습니다. 책에는 스크럼을 초기에 도입할때는 엄격하게 스크럼의 규칙을 지키라고 말하고 있습니다만 국내 실정을 감안한다면 이는 불가능에 가깝습니다. 특히 SI 프로젝트에서는..저도 옮긴이 의견에 공감합니다. 안하는것보다는 다르더라도 일단 하는것이 좋다고 생각합니다.

스프린트 검토에 보면 "대양을 오가는 배들은 매일 아침저녁으로 자신들의 위치를 '정정(fix)'했다."는 비유가 있습니다. 우리가 왜 스탠드업 미팅과 스프린트 검토회의를 해야 하는지 금방 이해시켜주는 좋은 비유라 생각됩니다.

4장

번 다운 차트는 프로젝트 현황을 나타내는 중요한 도구입니다. 이런 챠트를 사용하는데 있어서 겪는 어려움은 "이 챠트를 어떻게 만들어야 하는가"가 아니라 "어떻게 해석해야 하는가"라고 생각합니다. 여기서는 다양한 스프린트 유형을 보여주면서 그에 대한 이유를 제공하고 있어 유용합니다.

5장

"잡음은 요구사항이 잘 이해되지 않고, 서로 협의도 이루어지지 않을 때 증가한다." 색의 비유를 통해 잡음이 무엇인지를 설명하고 이를 가지고 요구사항과 연결하여 설명하고 있는 부분입니다. 책을 쓴 이가 이 분야에 깊은 이해를 하고 있다는걸 느낄수 있습니다.

"명시적인 제어 방식이 통하려면 개발 방법론들이 프로세스를 충분히 정확하게 정의할 수 있어야 하고, 그 결과 발생하는 잡음도 반복 가능성이나 결과 예측성을 침해 하지 않아야 한다." 기존의 개발 방법론들이 왜 현장에서 크게 환영받지 못하고 있는지 잘 설명하고 있는 표현입니다.

"기존의 시스템 개발 방법론들이 기반하고 있는 개발 활동정의는 불완전하고 취약하다." - 그렇기 때문에 애자일이 개발에 대한 실천법을 더 강조하고 있는거 같습니다.

"나는 방법론이 하라는 대로 다 했어. 분명 개발자가 방법론이 지시한 내용을 제대로 하지 않았을 거야. 진행상황을 정확하게 보고하지 않았을 수도 있고, 방법론의 지시 내용을 따르지 않았을 수도 있지. 방법론 개발 회사는 방법론만 따르면 예측 가능한 결과를 얻을 수 있다고 했는데, 이걸 개발자들이 제대로 완수해 내지 못한거야. 망할 개발자들 !" - 저는 실제로 이와 유사한 불평을 많이 들은적이 있습니다. 제가 한적도 많습니다. 방법론을 만든사람들을 저주하기도 했죠. ^^ 이제는 그 이유를 알거 같습니다.

6장

중첩(overlapping) 개발 단계에 보면 "연구, 개발, 테스트 단계를 꼭 중첩시켜서 돌려야 한다."고 강조하는 부분이 있습니다. 이 사실 역시 알고는 있지만 실제로 적용하기는 매우 어렵습니다. 특히 연구와 테스트 단계는 더욱 그렇습니다.

저는 이 책을 스크럼의 교과서와 같은 책으로 부르고 싶습니다. 스크럼에 대한 많은 정의와 규칙들, 그런 내용들을 실제로 적용하면서 품게되는 많은 질문에 대한 대답들을 저자는 자기가 십수년간 경험을 통해서 제공하고 있습니다.

끝으로 8장과 9장에 나오는 말로 리뷰를 끝내고 싶습니다.

"스크럼은 방해물 제거를 목표로 삼는다."

"할 수 있는 최선을 다하기 위해 배짱과 결단이 필요할 것이다."

스크럼 카테고리 컴퓨터/인터넷 지은이 켄 슈와버 (인사이트, 2008년) 상세보기

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.