애자일 최전선에서 일군 프로젝트 성공 무용담

By | 2009년 5월 1일


헨릭 크니버그(Henrik Kniberg)가 쓴 <<Scrum and XP from the Trenches>>가 『스크럼과 XP: 애자일 최전선에서 일군 성공 무용담』이라는 제목으로 발간을 준비하고 있습니다.

이 책은 제목 그대로 프로젝트 최전선에서 애자일이라는 전략전술 아래 스크럼과 XP라는 전술적 무기를 어떻게 운용하여 프로젝트 전투에 승리하였는지 그 성공 무용담을 아주 세세하고 적나라하게 보여줍니다. 스크럼을 도입하려는 팀이나 잘 되지 않아 중도 포기한 팀, 스크럼으로 재미를 톡톡히 봤던 팀 모두에게 스크럼을 한층 더 깊이 이해하고 구체적인 현장에 적절히 적용하는 데 도움이 많이 될 것입니다. 

[간략한 내용]
스크럼과 익스트림 프로그래밍은 팀에게 매 반복의 종료 시점마다 출시할 만한 명확한 작업 결과물을 완성할 것을 요구한다. 짧은 시간 내에 동작하는 코드를 전달하는 데 집중해야 하므로 스크럼 팀과 XP 팀은 이론만 논하고 있을 시간이 없다. CASE 도구를 사용하여 완벽한 UML 모델을 그리는 데 매달릴 시간도 없다. 그리고 완벽한 요구사항 문서를 작성하지도, 미래에 있을지 없을지도 모를 변경사항을 수용하려는 코드를 작성하지도 않는다. 이렇게 스크럼 팀과 XP 팀은 어떻게든 실제로 일이 되도록 하는 것에 집중한다.

또한 스크럼 팀은 일하는 도중에 발생할 수 있는 실수를 받아들인다. 하지만 그들은 그러한 실수를 발견하는 최선의 방법이 분석과 설계라는 ‘이론적 차원에서 소프트웨어 바라보기’가 아니라, 그 안으로 뛰어들어 직접 손을 더럽혀가며 제품을 개발하는 데 있다.

이 책은 이론보다는 실행에 초점을 맞추고 있다는 점에서 다른 책들과는 차별화된다. 스크럼이 무엇인지 장황하게 설명하지 않는다. 그저 간단한 웹 사이트를 몇 개 알려주고는 곧바로 본론으로 들어가 그의 팀이 제품 백로그를 어떻게 관리하고 활용했는지를 설명한다. 계속해서 잘 돌아가는 애자일 프로젝트의 다른 요소와 기법들을 하나하나 다루어 간다. 이 책에서는 고리타분한 이론도 참고문헌도 각주도 없다. 스크럼이 왜 통하는지, 스크럼이나 다른 기법을 왜 시도하려는지 철학적인 설명도 하지 않는다. 잘 굴러가는 애자일 팀이 어떻게 일하는지만이 설명될 뿐이다.

* 스크럼과 XP 실천법에 대한 실무적인 팁과 요령
* 전형적인 함정과 그 함정들에 대한 대처 방법
* 진행했던 일들을 묘사하는 다이어그램과 사진들
* 테스팅과 테스트 주도 개발
* 여러 팀으로의 확장과 팀 간 조율
* 팀 내외부의 저항 다루기
* 계획 수립과 시간 추정 기법

[추천 글]

김수옥 LG전자 생산성연구원 상무

오늘날 IT, Game, SI 분야뿐만 아니라 전자, 자동차, 금융 등 거의 모든 산업 분야에서 S/W의 비중은 급격히 커지고있으며, 그 속도도 점점 빨라지고 있습니다. 많은 제품에서 사용자 기능의 거의 대부분이 S/W로 구현되고 있고, 이에 따라S/W 개발 능력이 많은 회사의 흥망을 좌우하는 시대가 되었다고 해도 과언이 아닙니다.
S/W 개발의 생산성과 품질을 향상시키기 위한 노력으로 70년대부터 S/W Engineering이 발전되었고, 이후 SPICE,CMM, TSP 등 많은 개발 방법론이 등장하여, S/W도 건축이나 토목공사처럼 프로젝트 계획 시 필요한 자원과 비용을 미리산정하고 설계를 작성하고 이를 구현하는 공학의 체계를 갖추게 되었습니다.

[#M_더보기|접기|그러나 이러한 소프트웨어 공학의 도움에도 불구하고 여전히 S/W 개발 프로젝트는 매우 힘들게 진행되는 경우가 많습니다. 상당수의 프로젝트가 중간에 Drop 되고 있고, 절반 이상의 프로젝트가 납기와 예산을 초과하고 있습니다. PL은 항상 바쁘게 뛰어다니고, 개발자는 야근, 특근을 밥 먹듯 하지만, 관리자는 프로젝트가 계획 대비 진행률이 어느 정도인지 파악조차 되지 않아서 불안해합니다. 이러다 보니 IT 분야 종사자들은 3D 업종 종사자라고 푸념하기도 합니다.
2000년대에 와서는 Agile 개발 방법론이라는 새로운 패러다임이 등장합니다. 이것은 다른 무엇보다도 S/W를 낭비 없이 빠르게 만드는 것이 가장 중요하다고 믿는 사람들이 커뮤니티를 만들어 활동하면서 발전되기 시작했으며, S/W 개발자들 간의 상호작용, 작동하는 S/W, 고객과의 협력, 변화에의 대응을 4가지 주요 가치로 삼고 있습니다.
이들에 의해 만들어진 방법론 중 하나가 스크럼(Scrum)입니다. 스크럼은 복잡한 프로젝트를 관리하기 위한 아주 단순한 프레임워크로, 고객이 원하는 Product Backlog와 그것을 만들어 내기 위한 Sprint Backlog를 Daily Scrum 미팅을 통해 고객에게 최고의 가치를 제공하는 Product를 만들어 내게 합니다. 그 결과 여러 기업과 조직에서 큰 성과를 거두었다고 알려져 있습니다.
급변하는 시장 상황에 대응하기 위해 기존의 대량 생산과는 전혀 다른 새로운 개발 방식이 도입되는 과정에서, Lean 생산, 반복 개발과 같은 개념이 나타나면서 스크럼 탄생에 영향을 주었습니다. 재미있는 것은 이런 방법론들이 서로 완전히 독립적으로 시작되었지만, 그 발전 과정에서 많은 공통점을 갖게 되었다는 것입니다.
저자는 S/W 개발 조직 내에서 벌어질 수 있는 다양한 상황을 몸소 체험하고, 이에 대응하기 위한 많은 시도(때론 시행착오를 겪어가면서)를 하면서 얻은 소중한 경험들을 이 책에 쏟아 내었습니다. 스크럼을 시작하거나 또는 시작하지 얼마 되지 않는 조직에서 앞으로 겪게 될 상황들이 이 책에 거의 모두 설명되었다고 할 것입니다.
또한 이 책의 역자들은 LG전자에서 수년간 SW 개발 조직을 컨설팅하면서 많은 실전 경험을 갖고 있는 사람들로서, 저자의 의도를 정확히 파악하고 이를 생동감 있는 문장으로 번역하여 독자에게 읽기 쉽고 재미있는 책으로 재탄생시켰습니다.
스크럼을 추진하면서 어려운 상황에 직면한 조직은 이 책에서 유사한 상황을 찾을 수 있을 것이고, 책에서 제시한 방법을 참고하여 문제를 해결할 수도 있을 것입니다. 많은 S/W 개발자, 프로젝트 리더, 관리자, 경영자들이 이 책을 통해 그들이 당면한 난국을 타개할 수 있는 전략과 지혜를 얻을 수 있기를 기대합니다.
_M#]

 
박일 NC소프트 |블로그 parkpd.egloos.com

스크럼은 배우기는 쉽지만, 적용하기는 어렵습니다. 스크럼 연합(Scrum Alliance)은 스크럼을 프레임워크 (framework)라고 부릅니다. 프레임워크라는 건 문자 그대로 뼈대입니다. 스크럼을 성공적으로 적용하기 위해서는 간단한 뼈대만 그려진 도화지에 물감을 풀어 살을 입히는 것처럼 상황에 맞게 빈칸을 채우는 노력이 필요합니다. 즉, 개발팀 고유의 특성에 따라 스크럼을 상황에 맞게 적용할 수 있어야 합니다.

[#M_더보기|접기|스크럼은 팀마다 상황마다 다른 방식으로 적용됩니다. 저희 팀 같은 경우, 정보방열판 역할을 하는 큰 화이트보드가 있지만, 공식적인 제품 백로그와 스프린트 백로그는 포스트잇 대신 엑셀에 기록한 후 CVS에 저장합니다. 정해진 스크럼 마스터는 없습니다. 하지만, 암묵적으로 그 역할을 사람이 있고(보통은 팀장이 하게 됩니다), 100% 이상 그 역할을 잘 해주고 있습니다. 일일 스크럼 회의는 하지만 스프린트 검토회의는 각 업무별로 실무자들끼리 알아서 진행합니다. 팀 전체 번다운 차트는 없지만, 개인별 번다운 차트가 있어서 누군가의 업무가 밀릴 경우 다른 팀원이 그 팀원의 작업을 도와줄 수 있도록 조정해 줍니다. 개발 기간 중에는 스프린트를 돌리지만, 라이브 업데이트 후에는 서비스가 안정될 때까지 비상체계로 돌아갑니다.
‘이 책에 소개하는 그대로’의 스크럼은 아니지만 저희 상황에 맞는 스크럼을 진행함으로써 생산성이 많이 향상되는 것을 체험할 수 있었고, 큰 거부감이나 부작용 없이 스크럼이라는 문화를 팀에 정착시킬 수 있었습니다.
자전거를 배우는 가장 좋은 방법은 잘 하는 사람이 하는 걸 관찰하면서 실제로 따라해 보고 그 감각을 익히는 것일 겁니다. 이 책에서는 ‘스크럼을 어떻게 도입할 수 있는지’에 대해 저자의 경험담과 함께 세세한 부분까지 하나하나 소개하고 있습니다. 이 책을 읽은 후 프로젝트 성공을 위해서 스크럼을 어떻게 도입하고 사용할 수 있을지를 동료들과 함께 고민하고 동시에 노력한다면 성공으로 가는 길이 좀더 가까이 다가올 것이라 생각합니다.
_M#]

 

.

15 thoughts on “애자일 최전선에서 일군 프로젝트 성공 무용담

  1. 심우곤

    우와~! 드뎌 출간이네요~~ ^o^

    인사이트 사장님과 부장님.. 너무 수고 많으셨어요~
    특히 제안하였던 플래닝 포커.. 반신반의 했었는데 또 흔쾌히 제작해
    주셔서 더욱 감사해요~~

    함 찾아가 뵙겠습니다.

    Reply
  2. duru

    우곤 님이 수고 많으셨죠. 저희야 뭐~…
    네, 언제든 오세요. 책걸이 함 해야죠…^^

    Reply
  3. 레몬에이드

    와 이책 얘기 들은게 작년 11월 쯤이었던 것 같은데
    드디어 나오는군요 ^^
    인사이트 애자일 시리지는 언제나 재밌게 보고 있습니다

    Reply
  4. monac

    상화에 맞게 -> 상황에 맞게
    왜 이런 것만 보이는지…ㅋㅋ

    재미있는 책이네요~

    Reply
  5. 심우곤

    앗.. 근데 책을 보니까..

    다른 애자일 시리즈와는 달리 페이지 번호가 책 안쪽에 출력됐네요?
    페이지 찾기가 쉽지 않아 보이는데..

    일부러 편집이 그렇게 된 것인지요? ^^

    (김창준 님 블로그에서도 추천사와 더불어 이 문제를 언급하셨네요)

    Reply
  6. Pingback: The Galaxy: Woo-Gon's Blog

  7. Pingback: Pell's seer Blog

  8. 헝그리맨

    안녕하세요.
    오늘 강컴에서 이 책을 샀는데, 플래닝 포커 카드가 안 와서 슬퍼하는 중입니다.
    근데 책을 열어보니 페이지가 책 안쪽에 찍혀있던데요.
    이거 혹시 제본이 잘못된것은 아닌지요?
    일부러 이렇게 만들었다고 생각하기는 어렵고…
    반환해야 하는건지…
    알려주시기 바랍니다.

    Reply
  9. 두루

    헉, 플래닝포커를 못 받으셨다니, 강컴에 알아보시고 만약 해결이 안 되시면 저희가 보내드리겠습니다. 저번에 보내드렸던 분당 주소로 보내드리면 되죠?

    그리고 본문 페이지는 제본이 잘못된 게 아니라 디자인을 부러 그렇게 한 것입니다. 본문 여백 처리에 변형을 주면서 몇몇 디자인 요소들에 약간의 변형을 준 것인데, 너무 파격이 아니었나 생각되네요.ㅠ;ㅠ

    책 자체의 쪽수가 많지 않고 그림 및 지면 여백도 많으며 내용 자체도 난해하지 않아 편히 볼 수 있는 책이라 그렇게 장애가 될 줄은 몰랐는데, 반환을 생각하실 정도니, 분명 문제가 있네요.

    Reply
    1. 헝그리맨

      안녕하세요.
      빠른 답변 감사드립니다.^^
      오늘 강컴에서 답변이 왔는데 배송실수인것 같다고 카드를 다시 보내주겠다고 합니다.^^
      그리고, 제본은 원래 그런거라면 굳이 반환할 필요가 없겠네요. 음, 너무 파격적인 디자인 수정이었다고 생각됩니다. ^^

      Reply
  10. hermian

    인사이트 책의 깔끔한 디자인을 좋아했는데…
    이번 책은 참으로 난감하더군요.
    agile한 책의 페이지를 어찌 안쪽으로 넣을 생각을 하셨는지. 도무지 페이지를 어찌 찾으라는 얘기인지요?

    페이지는 당연이 바깥쪽에 있어야지요.
    쉽게 해당 페이지를 찾을려면 당연 한거 아닌가요.
    파격이 아니라 이건 만행 입니다.
    책의 기본이 안된거라고 봅니다.
    나중에 증보판을 내실때 꼭 수정 바랍니다.

    그리고 보통 짝수 페이지에는 장의 정보를 홀수 페이지에는 절의 정보를 적는데…인사이트 책중 아직 그런 원칙을 지키는 책을 보지 못했습니다. 책제목을 찍는다거나 하는건 아마 도움이 되지 않습니다.

    “겸손한 개발자가 만든 거만한 소프트웨어 ” 책도 첫줄 들여쓰기를 희한하게 하셨더군요.
    도무지 책에 일관성이 없어보입니다. 가독성이 현저희 떨어집니다.
    편집자가 어떤 철학이 있어 그렇게 하셨는지…

    http://ajt.ktug.kr/2008/10/31/volume2-number2 페이지의 PDF 를 한번 읽어보시기 바랍니다.

    앞으로도 좋은 책 많이 부탁드립니다.

    Reply
    1. 인사이트

      소중한 지적 감사합니다.
      Scrum과 XP의 페이지는 재판 때 꼭 수정토록 하겠습니다.
      또, “짝수 페이지에는 장의 정보를 홀수 페이지에는 절의 정보를 적는” 문제 역시 고려하겠습니다. 그렇게 하지 않는 이유는 사고가 생길 가능성이 높아지기 때문이었습니다. 마무리 하면서 페이지 변동도 심하고, 원고를 손보며 제목을 조금씩 다듬을 경우, 그곳 하나만 고치면 되는 게 아니라 이곳 저곳 수정사항이 생기기에 조금만 집중하지 않으면 ‘사고’가 터지는 부분이거든요.

      매번 책을 만들며 나름 정성을 기한다곤 하지만, 미처 눈길이 가지 않거나, 생각치 못한 부분이 많습니다. 독자님들의 눈높이에 맞추려면 아직 배울 게 너무 많다는 걸 새삼 느낍니다.
      더 분발하겠습니다.
      애정어린 지적 다시 한번 감사드립니다.

      Reply
  11. Pingback: The Galaxy: WooGon's Blog

댓글 남기기