스크럼에서의 추정은 크게 두가지 입니다. - 사용자 스토리에 대한 포인트, 태스크에 대한 시간
이중 태스크 시간은 개발자에 따라 변동이 커서 신뢰도가 떨어집니다. 물론 팀으로 추정한다거나 표준 시간을 정해준다거나 하면 좀 나아지기도 합니다.
기왕 그렇다면 차라리 태스크 시간을 같은 시간으로 고정시키는건 어떨까요? 보통 8시간 근무니까 4시간짜리 2개 태스크로 정해주는것도 나쁘지 않을거 같습니다.
그러다가 태스크를 상세히 정할 단계가 되면 더 세분화 할 수 있게 해주는거죠.
시간별로 포스트잇을 다양화 해서 시간이 많이 걸리는 태스크가 무엇인지 바로 알아차릴 수 있게 하는것도 좋을듯 합니다.
Ken Schwaber, co-creator of Scrum, says publicly that perhaps only 25% of
Scrum teams get the full benefit of Scrum. Jeff Sutherland, the other
co-creator, says publicly that all the high-performance Scrum teams he has
seen used XP-style practices.In those two sentences, we see a problem, and
part of a solution. Ken Schwaber has the Scrum Alliance working on a
possible Certified Scrum Developer program.
스크럼의 공동 저자인 켄 슈와버는 스크럼의 모든 이점을 얻게되는 스크럼 팀은 아마도 25% 정도밖에 되지 않는다고 공공연하게 말합니다. 제프 서덜렌드, 다른 저자도 높은 성과를 내는 스크럼팀은 모두 XP 스타일의 기법들을 사용한다고 공공연히 말합니다. 이 두가지 시나리오를 살펴보면 문제가 뭐고 이 문제의 해결책 이 무엇인지가 자명해 집니다. 켄 슈와버는 공인 스크럼 개발자 프로그램을 만들기 위해 스크럼 연합에서 작업을 진행중에 있습니다.
며칠전 프로젝트에서 스크럼을 적용하느라 고군분투중인 후배와 이와 비슷한 이야기를 나눴습니다.
스크럼이 처음 도입되면 사람들은 이를 환영하면서 새로운 방식에 열광합니다. 백로그를 작성하고 매 스프린트마다 이슈가 해결되는것을 보면서 기뻐하죠. 회고는 사람들을 새롭게 만듭니다.
하지만...프로젝트가 중반으로 달려가며 점점 많은 이슈가 등장합니다. 그러면서 사람들은 새로운 방식==스크럼의 한계를 느끼게 됩니다. 또 무언가 처음처럼 새로운 것을 기대하게 됩니다.
이때 스크럼의 틀 만으로는 부족합니다. 이때 부터는 XP의 기법들이 하나 둘씩 뒷받침 되어야 합니다. 습관이란것은 무섭습니다. 힘들고 어려운일을 당하면 바로 예전 방식에 대한 향수를 느끼고 회귀하게 됩니다.
켄트벡의 세미나가 시작되기 전에 애자일컨설팅의 김창준님이 '내가 보는 켄트벡'이라는 제목으로 켄트벡을 소개했습니다.
이후 바로 켄트벡의 세미나가 진행됐습니다. (자신의 노트북을 쓰겠다고 가져왔는데 전원잭이 안 맞아서 테이프로 아댑터를 칭칭감아서 겨우 시작했다는 후문이..^^) 레일즈콘에서의 조용한 발표에 대한 기억은 오늘 실제로 발표하는 것을 보고 약간 달라졌습니다. 농담도 섞어가며 재밌게 발표하시더군요.
오전 발표는 주로 개념적인 부분이었습니다.
점심시간전 12시20분부터 저자/역자 사인회가 이어졌습니다. 인사이트에서 가져온 TDD와 Extreme Programming에 대한 25% 할인 행사가 밖에서 진행되었는데 바로 매진됐습니다. 쿨럭
금일 온 사람이 191명이라고 하던데 줄이 끝이 없네요. ^^;;
저요? 당근 받았죠. 하하하. 끝나고 같이 사진까지 찍고 왔습니다.
사인은 이렇게 이름이 나온 부분 밑에다가 날짜와 같이 하는게 추세인듯 합니다.
세미나가 끝나고 김창준님과 같이 인증샷 한장 찍었습니다. (이런거 안좋아하지만 켄트벡이 누굽니까. 기회 있을때 찍어야죠.^^;;)
회사일이 바빠 겨우 짬을 내서 갔는데, 얼떨결에 사회를 보는 바람에 정신이 좀 없었습니다만 켄트벡을 지척에 두고 보낸 하루가 참 인상깊었습니다. 세미나 내용도 따로 정리를 해봐야 겠네요.
컨퍼런스 첫날입니다. 호텔에서 후딱 아침을 먹고 8시30분쯤 컨퍼런스 등록을 위해 Hyatt Regency Chicago 호텔 지하 2층으로 향했습니다. 왼쪽에 있는 부스에 이름을 대니 명찰과 식권, 프로그램 및 티셔츠를 교환할 수 있는 교환권을 나눠주네요.
그걸 들고 오른쪽으로 가니 큼지막한 가방에 뭘 잔뜩 넣어서 줍니다.
(사실 비회원 참가비용이 $1800, 217만원니까 매우 비싼 컨퍼런스 입니다.)
잡다한 홍보물품을 빼고 나니 남은건 컨퍼런스 프로그램, 논문집, 그리고 책이 두권입니다.(일단 책은 하나 건졌습니다.^^) 홍보성 책인줄 알았더니 Becoming Agile은 5월에 출간된 아마드 시드키 Ahmed Sidky의 신간이네요.
9시부터 세션이 시작되는 줄 알았는데 가보니 아무도 없습니다. 프로그램에는 한개 세션이 예정되어 있었는데 취소된거 같습니다. 결국 11시부터 제대로 된 세션이 열리기 시작했고 첫날 제가 들은 세션은 다음 3개 입니다.
11:00~12:30 Prioritrizing Your Product Backlog, Mike Cohn
14:00~15:30 XUnit Test Patterns and Smells, Gerard Meszaros
16:00~17:30 Zen and the Art of Software Quality, Jim Highsmith
Agile emphasizes on the opposite - getting stories which capture
onlythe "what" without the "how". It's a big shift in how we perceive
theprocess of software development to be. I guess it's as hard
forcustomers to get used to as it is for programmers.
역) 애자일은 반대로 스토리를 작성하는데 있어 '어떻게'가 아닌 '무엇을'을 정의하도록 강조한다. 소프트웨어를 개발하는데 있어
우리가 인식하고 있던것에 비한다면 이는 큰 전화점 이다. 고객에게 프로그래머처럼 생각하라고 강요하는건 무리가 있다.
스크럼을 처음 알게된건 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) 개발 단계에 보면 "연구, 개발, 테스트 단계를 꼭 중첩시켜서 돌려야 한다."고 강조하는
부분이 있습니다. 이 사실 역시 알고는 있지만 실제로 적용하기는 매우 어렵습니다. 특히 연구와 테스트 단계는 더욱 그렇습니다.
저는 이 책을 스크럼의 교과서와 같은 책으로 부르고 싶습니다. 스크럼에 대한 많은 정의와 규칙들, 그런 내용들을 실제로 적용하면서 품게되는 많은 질문에 대한 대답들을 저자는 자기가 십수년간 경험을 통해서 제공하고 있습니다.
"언제인가 쓰지 않을까 ?" 하는 생각에 당잘 필요하지도 않은 변수, 메소드, 클래스, 아키텍처를 정의하는 일은 프로젝트에서 흔히 볼 수 있습니다. 확장성, 이식성과 같은 품질 특성이 언급되기 시작하면 더 심해집니다.
하지만 애자일을 사용하면서 부터 이런 버릇을 많이 없앨 수 있었습니다. 자세(Attitude) 자체가 달라졌다고 할까요. 오히려 반대로 생각하게 됩니다. 사용하지 않는 멤버변수를 정의해 놓은것을 볼때마다 "이거 왜 정의했냐?"는 질문을 계속 하다보면 결국에는 필요없는것으로 판별되서 없애는 경우가 8~9할 입니다.
TDD를 한번에 적용하는 것은 쉽지 않습니다. 하지만 이런식의 접근을 계속 하다보면 자연스레 TDD로 갈 수 있을거 같습니다. 하지만 아마 그 반대도 가능할 거 같습니다.
HeadFirst Software Development 번역작업이 마무리 중입니다. 라는 글을 올린게 지난 달이었던거 같습니다. 번역이 끝난지는 좀 됐습니다만 지루한 리뷰를 진행하길 몇 차례, 출판사로 넘기고, 출판사에서 다시 보내준것에 대한 리뷰를 또 몇차례 하고 났더니 11월 중순이네요.
드디어 끝났습니다. 이제 제 손을 완전히 떠났습니다. 후련 섭섭합니다. ^^
어떤 분이 리뷰어를 자청해 주셨었는데 원고파일에 대한 보안과 일정문제 때문에 연락을 못 드렸습니다. 나중에 제가 개인적으로 연락드릴께요. ^^
조판되서 나온 페이지를 보고 너무 편집된 결과가 맘에 들어서 페이지 스샷을 올려봅니다.
아래는 프로젝트 현황판을 어떻게 구성하는지 설명하는 페이지 입니다.
다음은 제가 가장 좋아하는 프랙티스인 CI를 설명하는 페이지 입니다.
책 내용이 너무 좋아서 제가 이 책의 저자가 아닌것이 샘날 지경입니다. 언젠가는 저도 이런 좋은 책을 한번 써보고 싶습니다. 11월 말에는 책으로 손에 쥘수 있을거 같네요.
첫번째 세션을 들어가서 강사를 보고 놀랬습니다. 그나마 여기서 안면을 터서 인사도 하고 세션듣고난 소감은 어떠냐고 물어보고 했던분이 있는데 그분이 들어오더군요. 같은 세션을 듣네 하고 생각했더니 강사자리로 가서 강의준비를 하네요. ^^
강의는 크게 두부분으로 이루어졌습니다. 먼저 강사가 애자일을 적용하는데 있어서 부딪칠수 있는 저항에 대해서 여러가지를 이야기 합니다. 그리고 나서 "Agile" Way라는 토의 템플릿을 알려주고 나서 그룹토의를 시킵니다. 토의가 끝나고 나서 그걸 화이트보드에 적으면서 이 내용에 대해 다른 그룹들도 의견을 이야기 합니다. 강의를 날로먹는 기분도 있는데 참여도는 좋습니다.
오늘은 저도 적극적으로 토의에 참여해봤습니다. 내가 애자일 처음 적용해보는데 어렵더라 그러니 우리 그룹은 내가 겪는 이슈에 대해서 해보자. (겁도 없습니다.^^) 그래도 다행인건 제가 대충 이야기 해도 다들 잘 알아듣습니다. 역시 사람은 궁하면 다 하게 되어있는거 같습니다. 토의중에는 포스트잇을 사용했습니다.
이 사람들 참 영어 못 씁니다. (모국어 맞나 ?) 포스트 잇을 다 가져오기는 했는데 도대체 뭘 적어놓은건지..그래도 저걸 보고 정리해서 말은 잘 합니다. 첫번째가 제가 참여한 그룹이 토의한 내용입니다. 뿌듯..
두번째 세션 이야기 입니다. 강의를 듣기전에는 사실 테스트 코드에 대한 패턴내지는 TDD 적용사례 같은걸 이야기 하지 않을까 생각했었습니다. 근데 들어보니 특정 테스트 프레임워크를 기반으로 테스트 코드를 작성하는거더군요. 아차 싶었습니다. PPT가 거의 이런식입니다. 웹2.0 발표에서 많이 봤는데..
강의는 참 열심히 합니다. 국내라면 TDD가 붙으면 일단 사람들이 쳐다봐 주는데 여기는 아니더군요. 강의장이 썰렁합니다. 그렇다고 이 사림이 실력이 없냐, 그것도 아닙니다. 매닝사에서 나온 JUnit Recipe의 저자입니다. 블로깅도 열심히 하는거 같습니다.아이디어도 괜찮습니다. 애플리케이션의 기능에 맞춰서 테스트 코드를 만들기 보다는 특정 기술에 맞춰서 테스트 코드를 만들면 재활용도도 높아지고 테스트에 들어가는 노력도 많이 줄일수 있다. 대충 이런 내용입니다. 하지만 제가 원했던건 아니어서 휴식시간을 이용해서 다른 세션으로 들어갔습니다. 제가 중간에 갈아탄 세션은 유저스토리에 관한 세션이었습니다.
중간에 들어가서 약간 뻘쭘했는데 다행이 아는 얼굴이 몇명 있습니다. 아니나 다를까 여기도 그룹 토의입니다. 이번에는 강사가 제공한 시나리오를 가지고 유저스토리 맵을 작성하는거네요. 얼른 시나리오를 읽고 토의에 참여했습니다.
시나리오는 별거 아닙니다. CD와 책을 파는 상점의 온라인 시스템을 구성하는건데 이전에 사람들이 만들어놓은 스토리를 보니 피식 웃음이 나왔습니다. 스토리가 엉성합니다. 제 생각에 이론은 잘 알아도 이런걸 직접 하는데는 익숙치 않은거 같습니다. 스토리를 타임라인에 맟추어서 스토리 맵을 구성하는게 최종 결과물입니다.
이렇게 해서 튜토리얼이 끝났습니다. 첫날에 비해 더 많이 참여했다는 생각에 기분이 좋네요. 오늘은 저녁을 주기 때문에 남아서 먹고 왔습니다. 저녁을 먹으면서 독일에서 온 자동차 부품업체의 QAO를 하시는 분과 이야기를 나눴습니다. 영락없는 독일인인데 갑자기 "창원"이야기를 합니다. 들어보니 거기있는 업체가 자기네 회사 솔루션을 써서 한국에 2주 갔다왔다고 하네요. 괜히 반가워서 한창 이런저런 이야기를 했습니다.
지금이 여기시간으로 새벽 4시입니다. 이제 자야겠네요. 컨퍼런스 내용은 내일 정리해야 겠습니다.
오전 세션은 쉽게 골랐는데 오후 세션은 Ahmed Sidky와 Mary Poppendieck & Tom Poppendieck을 놓고 고민하다가 결국 Lean을 선택했습니다. 왜 유명인들을 한 타임에 몰아놓은건지..
오전 세션 같은 경우에는 제가 지금 고민하고 있는 직접적인 문제-우리 회사에 애자일을 어떻게 적용하는것이 맞는것인가와 직결되는 주제여서 좋았습니다. 전혀 모르는 내용은 아니지만 한꺼번에 정리가 되는거 같아서 좋더군요.
강의내용도 좋았지만 중간중간 사람들이 서로 질문하고 서로 답변한 내용에 공감이 많이 가더군요. 그런 모습을 보면서 "이야 이런게 애자일 컨퍼런스 구나 !" 하고 내심 놀랬는데 나중에 알고보니 이 세션이 유별나더군요. 다른 세션 들어가보니 질문하고 답변했던 사람들이 다 강사였습니다.
오후 세션은 내용도 내용이지만 메리 포펜딕의 열정어린 강의에 놀랐습니다. Lean에서 말하는 가치를 자신의 프로세스에 적용하기 위해서는 어떻게 하는가라는 질문을 강의시작부터 끝까지 던지는데 "애자일 적용하려면 저렇게 해야 하나" 하는 생각도 했습니다.
여담이지만 전 톰 포펜딕이 사진사인줄 알았습니다. 오전세션에 갑자기 누가 카메라를 들고 들어와 사진을 찍길래 "컨퍼런스 전속 사진사구나."하고 생각했는데 오후세션 들어갔더니 떡하니 앉아서 자료를 나눠주더군요. 근데 중간에 열심히 사진찍으러 다니는건 여전히 계속..이분 사진이 취미인가 보네요.
강의 중간에 자신들의 프로세스를 개선해보는 토의가 4그룹으로 나뉘어서 이루어졌습니다. 제가 참여한 그룹은 시스코의 리서치에 대한 부분이었는데 사람들이 참 열심히도 참여하더군요. 제 옆그룹인데 무지 열심히 한거 같더니 박스 2개 그리고 말더군요. ^^
첫날이라 분위기 파악하고 사람들이 말하는것만 정신없이 듣다보니 하루가 간거 같습니다. 내일은 못하는 영어로라도 하면서 적극적으로 참여해 보려고 합니다. 더블린 구경 하겠다고 일찍와서 5일을 혼자 지냈더니 입에 거미줄 치는거 같네요. ^^
그나저나 아일랜드에는 한국음식점 찾기가 하늘의 별따기입니다. 구석구석 뒤지다 보면 하나쯤은 있던데 더블린 시내를 그렇게 돌아다녔어도 하나도 못 찾았습니다. 이 촌구석에는 SPAR(아일랜드식 편의점) 하나 없으니 돌아갈때까지 한국음식 먹기는 글렀네요.
더블린으로 가는 비행기를 혼자서 대합실에서 기다리다 시차적응을 못해서 깜박 잠이들었는데 눈뜨니 주변에 아무도 없더군요. 비행기 시간이 8:20분인데 8:30분에 일어나서 부리나케 뛰어가서 탄게 아래 비행깁니다. 까닥했으면 공항에서 노숙할뻔..^^
더블린에 머문걸 제외하면 2틀간 꼬박 걸려서 여기까지 온거 같습니다. 옆에 사진을 자세히 보시면 호텔 밖에서 소랑 말이 풀을 뜯고 있는걸 보실수 있습니다.
호텔에서 컨퍼런스가 열리는 리메릭 대학까지는 가깝습니다. 수목원같은 길을 따라서 15분정도를 걸어가면 리메릭 대학이 나오는데, 미리 컨퍼런스 건물을 확인하러 갔다가 사람이 아무도 없어서 좀 놀랐습니다. 나중에 대학을 둘러보다가 그 이유를 알았는데 이 대학 캠퍼스가 엄청 큰데다가 학생수가 적어서 그렇다고 합니다.
절에 공부하러 온 기분으로 열심히 배우고 가야겠습니다. 그나저나 다시 돌아갈걸 생각하니 갑갑하네요.
XP Conference
주로 유럽사람들이 참여하는 컨퍼런스 입니다. XP2008은 아일랜드 Limerick이라는 곳에서 열리는군요. 잘하면 갈수도 있을거 같은데, 혹시 가게되면 참관기를 열심히 한번 써보려고 합니다.
XP2007에 다녀온 분이 쓴 소감도 한번 읽어보세요.
애자일 그룹에서 진행한 애자일 경험을 공유하는 자리에 갔다 왔습니다. 애자일 하는 분들의 모임이어서 그런가요. 모임의 시작부터 끝까지 자유스로운 분위기에서 많은 이야기가 오갔구요. 오랜만에 아는분도 만나서 근황도 듣고..아주 유쾌한 모임이었습니다.
위 사진은 TDD를 할때 타이머를 사용했던 경험을 이야기 하면서 TDD를 지원해 줄수 있는 장치를 설명하고 있는 사진입니다. 노트북 옆에 있는 장치가 그건데 장치에 달린 스위치를 누르면 화면에 "테스트 코드를 작성하세요", "코딩을 하세요"와 같은 메시지를 뿌려줍니다. 재밌는 아이디어 같은데 약간 불안했다는..^^
OST와는 사뭇 다른 경험이었습니다. 자세한 내용은 Xper.org에 올라온 내용을 참고하시기 바랍니다.
베스트 프랙티스 공유 200804
저도 들으면서 간단하게 나마 마인드맵으로 정리했는데 이제 와서 보니 내용이 좀 빈약하네요. 그래도 필요하신분은 받아서 보시기 바랍니다.
『애자일 프랙티스』를 한나절만에 읽어버렸습니다. 그냥 무슨 내용이 있나 훝어보려다가 3시간만에 독파를.. 읽다가 잠깐 책을 덮고 생각도 하고 그랬어야 했는데 뭐랄까..읽기 좋은 소설책처럼 좀더..좀더..하다보니 참고문헌이 나와버렸네요. 내용도 좋지만 번역도 너무 잘 하신거 같습니다. ^^;
책은 "애자일 소프트웨어 개발 선언문"으로 시작하고 있습니다. 저도 이 글을 개인적으로 좋아하는데 그래서 시작부터 "오 이책 괜찮은데" 하는 생각이..^^
'프로세스와 도구' 보다는 '개인과 상호작용'을
'포괄적인 문서화'보다는 '동작하는 소프트웨어'를
'계약 협상'보다는 '고객과의 협력'을
'계획 주수'보다는 '변화에 대응'을
업무가 프로세스에 대한 일이다 보니 프로세스 준수 체크에 대한게 이슈가 되기도 합니다. 2장 38페이지를 보면 프로세스 준수가 결과는 아니다.는 부분이 나옵니다. 일을 하다보면 프로세스를 위한 프로세스가 되기도 하고 결과보다는 중간 산출물만 체크하는걸 프로세스 준수라 생각하고 끝을 내는데 이런 관행을 다시 생각하게 해주었습니다.
4장 89페이지에 전략적 설계 대 전술적 설계 에 대한 부분이 나옵니다. 설계를 얼마나 상세하게 해야 하느냐 ? 는 제가 오랫동안 가지고 있는 숙제중 하나입니다. 개발에 집중해보기도 하고, 설계에 정말 많이 노력해 보기도 했고, 라운드 로빈으로 둘다를 유지해 보기도 하면서 설계의 효용성에 나름 많은 생각을 했던적이 있습니다. 요즘도 MDA에 대해 고민하고 있는데 이 부분도 좋은 해답중 하나라는 생각이 듭니다.
전략적 설계는 요구사항이 아직 정제되지 않았을때 일반적으로 이루어지는 설계이다. 전술적 설계는 메서드,매개변수,필드 등의 세부내용이나 객체간 상호작용의 정확한 순서를 명시하는 것. 이 전술적 설계는 프로젝트가 진화할 때에만 드러난다. 좋은 전략적 설계는 올바른 방향을 가리키는 지도와 같은 역할을 한다.
4장 97페이지에 보면 형상관리에서 사용할 수 있는 기본전략에 대한 내용이 나옵니다.
체크인한 코드는 항상 바로 쓸 수 있어야 한다.
로컬 테스트를 실행하라.
최신 소스를 체크아웃하라.
체크인하라.
이제 형상관리는 당연히 사용해야 하는 툴로 인식되는거 같습니다. 하지만 단순히 툴을 사용한다고 해서 형상관리를 제대로 한다고 말할 수는 없습니다. 이 책 곳곳에 형상관리에 대한 내용이 많이 나오는데 이것만 잘 정리해도 좋은 형상관리 정책을 정할 수 있을거 같습니다.
6장 167페이지에서 주석에 대한 좋은설명을 읽었습니다. 이 책에도 나오는 "코드로 대화한다."는 말도 많이 하지만 저에게는 수백줄 코드보다 한글로 눈에 쏙 들어오는 주석이 더 눈에 쉽게 들어오더군요.^^
코드를 읽는 사람에게 올바른 방향을 알려주는 일종의 로드맵을 만들기 위해서 주석을 사용하라. 너무 많은 주석은 어떠한 유용한 정보도 전달하지 않는다. 이런 주석은 조직밖의 사람을 위해서가 아니라 몇달 후의 나를 위해서 추가하는 것이다. 좋은 주석은 다음 사항을 만족시켜야 한다.
목적 : 이 메서드는 왜 존재하는가 ?
필요조건(선행조건) : 이 메서드를 실행하기 위해서는 어떤 입력이 필요한가 ?
계약사항(후행조건) : 이 메서드가 완료되면 어떤 결과가 발생하는가 ?
예외 : 잘못되면 어떤 예외를 던지는가 ?
6장 187페이지에 보면 신문 배달 소년과 지갑이라는 비유로 일종의 Separation of Concern을 이야기 하고 있습니다. 좋은 비유라는 생각이 드네요.
8장 220페이지 등장하는 스크럼의 돼지와 닭의 비유는 볼때마다 정말 멋진 비유라는 생각이 듭니다. 타이머를 이용한 스탠드업 미팅등은 타임방식을 중요시하는 애자일의 좋은 프랙티스라 생각합니다.
8장 230페이지 제목이 아키텍트는 코드를 작성해야 한다.입니다. 저는 이런 제목 볼때마다 안심합니다. "그래 난 잘못된 방향으로 공부하고 있는게 아냐." :-)
책 뒤에 보면 책에서 참고했던 레퍼런스들을 다양하게 소개하고 있습니다. 이거 찾아보는 재미도 쏠쏠 합니다. 지난번 마틴파울러의 Continous Integration을 번역해서 올린이후 뭘 또 건드릴까 찾아보고 있었는데 하나 건졌습니다. (다음번에는 Is design Dead ? 를 번역하려고 합니다. ^^)
그냥 인상깊었던 부분을 몇자 적으려고 했는데 너무 길어졌네요. 좋은 책이라 꼭 읽어보시라고 추천하고 싶습니다.
어제부터 『린 소프트웨어 개발에 적용』을 읽기 시작했다. 애자일 컨설팅과 인사이트를 통해 이 책이 출간된지는 이미 알고 있었지만 이런저런일로 미루다가 겨우 손에 잡을수 있었다.
이 책을 중반까지 읽고 나서야 "내가 이 책에 약간의 오해를 갖고 있었구나"라는 사실을 깨달았다. 나는 이 책이 린 소프트웨어 개발이라는 방법론을 설명하는 책이라고 생각했다. 하지만 린이란 도요타식 생산방식을 가리키는 용어이고 제조업에서 수십배의 생산성을 자랑하는 린 생산방식을 소프트웨어 개발에 도입하는 방법을 책은 설명하고 있었다.
산업공학을 전공한 덕분에 이 책의 용어를 보는게 너무나 반가웠는데 마치 처음 대학에 입학해서 산업공학 개론책을 보는 기분도 들었다. 산공을 전공한 사람이 IT에 많기는 하지만 직접적으로 산공지식을 살리지는 못한다. 하지만 이 책은 그에 대한 좋은 사례를 제공한다.
책 중간에 보면 대기행렬 이론을 소개하면서 Little's Law를 보여준다. 대학원에서 Queueing Theory책의 맨처음에 봤던건데 이걸 여기서 볼줄이야. ^^ 가끔 성능분석 책에 보면 이런 내용이 나오기도 하는데 기능목록을 설명하면서 이걸 언급하는건 처음본거 같다. 이 책에서는 사용자 목록이 너무 많거나 들쭉날쭉 하면 안된다는 근거로 들고 있다. 하지만 Little's Law를 잘 이용하면 사용자 목록이 추가되는 데이터를 조사하여 이를 적당한 지수분포로 맵핑하고(fitting) 이를 입력으로 잘 모델링하면 시스템이 안정상태에 이르게 되는 확률값을 계산해 낼 수 있다.
사실 소프트웨어 개발에 제조업의 특징을 따와서 생산성을 높이려는 시도는 이 방법이 처음은 아니다. 과거에도 많이 있어왔다. 소프트웨어 팩토리(Software Factory) 같은걸 떠올려 보면 알수 있을것이다. 어찌됐든 소프트웨어 개발의 또 다른 접근방법을 명쾌하게 설명하고 있는것만으로도 이 책은 읽어볼 만한 가치가 있다.
지난번에 만났던 회사의 책임님이 『나이키의 상대는 닌텐도다』라는 책을 이야기 하면서 비즈니스간의 경계는 이미 무너졌다는 이야기를 했던게 기억난다. 정확히 기억은 안나지만 건설인가 자동자에서 조선업을 벤치마킹 해서 성공했다는 기사를 본적도 있고, 멀리 가지 않아도 건축의 아키텍처 기법을 소프트웨어 개발에 사용하는것은 이미 일반적이 되었다.
어느 분과 개발자 역량에 관해 이야기를 하던중에 들은말이 기억난다. "일이 주어졌을때 어느정도 일정이면 개발할 수 있다고 말할수 있는 사람이 역량있는 개발자라고 생각해요." 자신의 역량을 알고 일이 주어졌을때 얼만큼의 기간이 걸린다고 모든 개발자가 말해줄 수 있다면 참 좋을거 같다. 그게 정확하면 금상첨화 일테고..^^
하지만 현실은 그렇지 못하다. 그렇기 때문에 우리는 처음에 계획했던 일정대로 일을 진행하지 못하고 매번 프로젝트 일정에 쫓기기 다반사다. 그럼 정말 개발자 역량이 딸려서 그렇게 말을 못하는 걸까 ? 전적으로 개발자 탓은 아니라고 본다. 예측을 잘 하려면 먼저 상세화(Break Down)를 잘 해야 한다. 얼마나 잘 해야 할까 ? 예측이 가능할 정도로 잘 해야 한다. 무슨 궤변으로 들릴 수 도 있게지만 나는 이 말이 맞다고 본다. 예측을 하기 어렵다면 아직 상세화가 덜 된거라고 보면 되지 않을까 ?
그럼 상세화를 잘 하려면 어떻게 해야 할까 ? 인간이 정보를 이해하는 첫번째 단계는 분류(Categorization)라고 말한다. 커다란 덩어리를 이리 나누고 저리 나누었을때 우리는 더 쉽게 이해한다. 방법론의 구성을 살펴보면 그 수행 단위에 따라 Phase, Activity, Task 등으로 나누어서 작업을 할당하게 되는데 이도 비슷한 원리다. 나누는 명확한 기준이 있어야 한다. 작업의 기준이 될수도 있고 프로그램의 기준이 될수도 있다. 아키텍처도 훌룡한 기준의 하나로 볼 수 있다. 명확한 아키텍처가 있다면 고객이 말하는 특정 기능에 대해 어느정도 코드가 나올지 가늠이 가능해진다.
소프웨어 공학의 사실과 오해에 보면 이런 내용이 나옵니다. 예측(책에서는 추정이라는 용어를 사용합니다.)이 실패하는 이유는 적당하지 않은 사람이 적당하지 않은 시기에 하기 때문이다. 시스템을 제대로 모르는 마켓팅 담당이 시스템 범위도 결정되기 전에 먼저 제품 발표일을 결정합니다. 잘못된 예측이 나올수 밖에 없습니다.
Prioritizing Your Product Backlog.pdf
Ahmed Sidky와 Mary Poppendieck & Tom Poppendieck을 놓고 고민하다가 결국 Lean을 선택했습니다. 왜 유명인들을 한 타임에 몰아놓은건지..
