블로그 이미지
소프트웨어 개발 경험을 공유하고 싶은 재밌게 사는 소프트웨어 엔지니어입니다^^

카테고리

Chungha Story (46)
Agile Experience (22)
My Family (4)
Life Style (8)
Programming (8)
Android (3)
Total128,101
Today109
Yesterday102
지난주에 현업과는 관련이 없어 보이는 NHN에서 주관하는 개발자 컨퍼런스에 참석하였습니다.
업무에 직접적인 관련이 없다보니 영감이 늦게 밀려드는가 봅니다. 이제서야 회고를 해봅니다. (발표 내용에 대한 후기는 없답니다.ㅋ)

NHN은 어디로 가고 있나?

Deview가 끝나고 난 느낌은 "NHN은 이렇게 잘 하고 있구나" 정도였습니다. 솔직히 그 이상도 이하도 아니었습니다.
후기 경품이 탐이 났지만 딱히 쓸말이 없었습니다. 싸이트 가면 동영상이 모두 공개 되어있는데 후기를 쓰자니 거시기 했습니다.
그러던중 문득 이런 생각이 들었습니다. 왜 키노트 스피치를 좀 지루할 정도로 구구절절히 길게 하였을까? 
제가 추측한 이유는 NHN이 가고 있는 목표에 대해서 진심으로 구구절절히 공유하고 싶었기 때문입니다.
키노트 스피치가 끝난 후에 지인중 한분이 그러더군요. "그냥 애자일 한다고 하면 되지 않나?"
분명 NHN에서 하고 있는 활동들은 애자일스러웠습니다. 하지만 애자일이 NHN의 목표가 아니기 때문에 궂이 애자일을 한다고 할 필요가 없었던 것이라고 생각합니다.
이러한 관점으로 Deview의 강연들을 생각해보니 NHN이 가고자 하는 곳이 어디인지가 보이더군요.^^ 
그곳이 어디인지 제가 자세히 기술할수는 없지만 분명한건 NHN 내부 개발자만을 위한 천국은 아닐겁니다.

궂이 애자일 조직이라고 표현할 필요가 없다.

가끔 애자일을 짝 프로그래밍이나 테스트 주도개발, 스크럼등의 Best Practice로 여기시는 분들이 많습니다.
혹은 갓 입사한 회사나 팀에서 애자일을 모른다고, 애자일 팀이 아니라고 실망하는 신입 개발자분들도 있습니다.
수단과 목표가 약간 혼동되는 부분이라고 생각합니다. 애자일도 목표는 아니라고 생각합니다.
꼭 개발조직에 애자일이나 RUP, Waterfall, CMMI 등의 정체성이 명시적으로 존재해야 할까요? 그런건 정치판에서도 지겨운데...
우리가 원하는건 애자일 조직이 아니라 행복하게 개발할 수 있는 매우 효율적인 개발 조직일겁니다. (정확히 말하면 제가 원하는 것입니다^^)
물론 조직에 맞는 애자일스런 Practice를 만들어나가면 좀더 빠르게 그런 조직을 만들수 있을것입니다.
제가 말하고 싶은건 뭘 하면 애자일이고 안하면 애자일이 아니다 이런게 중요한게 아니다라는 것입니다.^^;;
개인적으로 '애자일'이란 표현보다 '실용적인'이란 표현이 더 좋습니다.ㅋ
이런 점에서 NHN의 발표에서 '애자일'이란 용어를 쓰지 않은 것은 현명한 선택이었다고 생각합니다.

기대되는 NHN의 행보

얼마전까지만 해도 NHN은 뒤뚱거리는 거대한 한국의 포털 기업으로만 생각했었습니다. 개발에 열정을 가졌던 친구가 NHN의 신입사원으로 입사한 후에 개발의 열정이 식어버린... 그냥 포털 대기업으로만 생각했었습니다.
하지만 Deview를 보면서 생각이 조금 바뀌었습니다. 열악한 한국의 개발 환경을 불평, 불만만 하는 사람들이 변화될 수 있도록 기여하는 기업이 되고 있다고 생각합니다. (우리 회사도 그런 기업이 될겁니다!^^)

스스로 바뀌어야 환경도 바뀝니다.^^

이상 짧은 회고였습니다;... 회고라기 보다는 주저리주저리 떠든;;ㅋ



NHN Deview 2010 동영상 다시 보기 및 자료 : http://deview.naver.com/2010/courses.nhn
저작자 표시 비영리 동일 조건 변경 허락
신고
Posted by 윤청하

댓글을 달아 주세요

  1. 2010.12.13 11:32 신고 ryuhayoung  댓글주소  수정/삭제  댓글쓰기

    청하 안녕~ ㅎㅎㅎ

  2. 2011.02.16 17:01 신고 arload  댓글주소  수정/삭제  댓글쓰기

    모든 일원이 만족하면서, 개선해 나가고 있따. 나아지고 있다는 느낌. 성장하고 있다는 느낌을 주기는 정말 어려운거 같아요.
    이러한 시도는 정말 감탄할만 하죠. 애자일이 만능이 아니라. 조직도 만족하고, 조직 구성원도 만족하는 것.. 그게 정말 이상인거 같습니다. 다른이의 이상과 저희들의 이상은 다르니깐요.. :)

  3. 2011.02.18 20:21 신고 윤청하  댓글주소  수정/삭제  댓글쓰기

    스스로의 자세를 바꾸면 그 다른 이상들이 하나로 모여질수 있다고 생각해요^^

  4. 2011.11.24 21:44 신고 뇨릉  댓글주소  수정/삭제  댓글쓰기

    "행복하게 개발할 수 있는 매우 효율적인 조직".. 저도 그런 조직을 꿈꾸는 1인입니다...^^;
    하지만 노력하는 만큼 잘 안되서 요즘은 지처가고 있는 중이랍니다...
    사람들의 마인드를 바꾸기가 쉽지 않더군요.. 제가 괜히 엄한데와서 하소연하는군요 >.<

    • 2011.11.25 15:51 신고 윤청하  댓글주소  수정/삭제

      반갑습니다! 윤청하입니다.^^
      저도 한때 지쳐있었는데, 요즘은 200%이상 활력소를 찾았습니다.
      제 경우엔 남을 보다가 제 자신에게 포커스를 바꿔보니 즐거워지고 생산성도 매우 높아졌습니다.
      그렇게 지내다 보면 남들이 호기심을 갖게 되더라구요. 어떻게 하면 저렇게 즐겁게 하나...
      이제 시작인거죠!

      고민은 나눌수록 잘 풀리는거 같습니다. 잘부탁드려요~

얼마전에 "창의적인 아이디어는 어디에서 오는가?" 라는 주제로 강연을 들은적이 있습니다.
강연자분의 결론은 다음과 같았습니다.
창의적인 아이디어는 새로운 것이 아니라 기존에 있던 것을 새롭게 보는 것이다.
창의적인 아이디어를 얻기 위해서는 내가 보고 경험한 것들을 새롭게 볼줄 알아야 하며, 
다른 사람의 말과 행동을 새롭게 볼줄 알아야 한다.
강연을 듣고 저는 다음과 같은 생각을 했습니다. 
항상 주위의 모든것에 호기심을 갖고 관찰하여 필요한 경우 내것으로 만들수 있어야 창조적인 인재가 될수 있다
결국 매우 상투적인(cliche) 결론이었습니다. 하지만 다시 생각해보니 개발자들에게 매우 필요한 능력일것 같다는 생각을 했습니다.

창의적인 개발자는 어떤 능력이 필요한가?

저는 다른 개발자들이 만들어 놓은 결과물을 분석하고 이해할줄 알며, 가져다 사용할 수도 있고 필요한 경우 개선될 수 있도록 기여할 수 있는 개발자가 창의적인 개발자라고 생각합니다.  혼자 모든 것을 만들어 내는 것 보다는 다수의 사람이 같이 만들어 내는 것이 더 창의적인 결과물이 될수 있기 때문입니다.
세계적인 오픈소스에 기여하지 않더라도 같은 회사내, 같은 연구소내, 같은 팀내의 다른 개발자들의 결과물들이 같이 공유하며 개선되고 성장 할 수 있다면 그 조직은 창의적인 개발 조직이라고 할수 있을 것입니다.
이러한 것들이 가능하려면 조직 내에 소스코드 오픈 문화, 개발자간의 신뢰 문화등이 밑바닥에 깔려 있어야 할 것입니다.
어렵지만 할 수 있지 않을까요? 전 애자일이 창조적인 조직을 위한 은탄환이라고 생각하지 않습니다. 
하지만 시도해볼만한 것임은 확실하다고 생각합니다.^^

Two Heads Are Better Than One.
저작자 표시 비영리 동일 조건 변경 허락
신고
Posted by 윤청하

댓글을 달아 주세요

  1. 2010.09.13 09:43 신고 noforest  댓글주소  수정/삭제  댓글쓰기

    공감~

  2. 2011.02.25 10:36 신고 이장석  댓글주소  수정/삭제  댓글쓰기

    글 잘 보았습니다.
    좋은 하루 되십시오.

쉬워 보이는 스크럼

작은 개발팀의 생산성과 품질에 대해서 고민해 본적이 있으신 분들이 스크럼에 대한 이야기를 들으면 적지 않은 분들이 상당한 영감을 받습니다. 그리고 바로 팀에 적용 할 수 있을 것 같은 뽐뿌를 받곤 하죠. 그중에 저도 포함되구요.
하지만 데일리 미팅이 그나마 만만할 뿐 프로덕트 백로그, 스프린트 미팅이나 회고, 백로그 추정등은 그렇게 녹록하지 않았습니다.

베스트 프랙티스 도입보다 더 중요한건 애자일 팀 만들기

스크럼의 구성요소들을 하나하나 뜯어보면 애자일 정신이 가득한 프랙티스들이 주류를 이룹니다.
즉, 애자일 개발팀이 아닌 팀에서 스크럼을 도입하려다 보면 데일리 미팅 정도야 하겠지만, 하나하나 적용시키다 보면 난관에 부딪힐때가 많습니다. 더 중요한것은 이러한 난관에 부딪힐때 해당 고민들을 팀원들과 풀려고 하는 것이 아니라 외부 모임(자신만의 세계, 개발자 친구나 개발자 포럼등)에서 풀려고 하는 것이죠. 즉, 적용하려는 리더 조차 애자일스럽지 못한 것입니다.

제 생각에는 갑작스럽게 스크럼을 바로 도입하는 것보다 애자일 개발팀이 되기 위해 하나씩 바꿔나가는 것이 좋다고 생각합니다.
애자일 개발팀으로써 살짝 자리를 잡은 뒤에 스크럼을 도입해보면 더욱 효과적일것 같습니다.
아래의 프로세스들이 팀에 살짝  정착되고 나서 스크럼을 도입한다면 더욱 효과적일것 같습니다.
  • 지속적인 피드백을 주고 받는 설계와 구현
  • 사용자 스토리를 이용한 요구사항 정리 
  • 업무 추정을 담당자에게 위임 
  • 빌드 자동화 / 일일 빌드 
저작자 표시 비영리 동일 조건 변경 허락
신고
Posted by 윤청하

댓글을 달아 주세요

  1. 2010.08.19 11:45 신고 k16wire  댓글주소  수정/삭제  댓글쓰기

    헨릭의 Scrum & XP 책의 앞에보면 회고부터 시작하라고 이야기 합니다. 저도 동의합니다. 회고를 통해 먼저 무엇인 좋고 나쁜지를 찾아보시는것도 좋은 방법일듯..

저는 스크럼, 테스트 주도 개발, 짝프로그래밍, XP의 원칙과 가치 등을 처음 접했을 때 큰 영감을 받았던 기억이 있습니다.
이런 것을 팀에 도입한다면 한단계 발전하는 팀이 될 수 있을 거라는 확신이 들었습니다.
고민했던 생각들을 실천하고 주변사람을 선동하는데 익숙한 저는 바로 실행에 옮겼습니다.
우리는 XXX 문제들이 있기 때문에 YYY를 도입해서 해결해야 합니다.
그리고 우리는 YYY를 도입했습니다.

새로운 것을 도입하는 것이 끝은 아니다.
스크럼은 정말 쉬워보였습니다. 그래서 우리는 스크럼을 가장 먼저 도입하기로 하였습니다.
약 1년간의 스크럼을 해보면서 느낀 것은 새로운 프로세스와 방법을 도입하는 것은 단순한 액션에 불과하다는 것이었습니다.
새로운 것이 정착하기 위해서 우리는 기존의 것을 포기해야 했습니다. 
적게는 수년에서 많게는 십수년의 경력동안 유지했던 자신만의 틀을 깨야 했습니다.

  • 매일매일 자신의 일정과 업무 진행 상황을 모든 팀원에게 솔직하게 공개해야 했습니다.
  • 팀장님은 외부와의 업무 상황 및 요구사항의 출처 및 발생 이유에 대해서 모두 공유해야 했습니다.
  • 특정 개발자만 처리할 수 있는 소스코드가 없어져야 했습니다.
  • 우리 팀의 상황을 타 팀(영업, 마케팅, QA 등)에게 여과 없이 공개해야 했습니다.
이 외에도 여러가지가 있습니다. 하나하나의 틀을 팀원 각자가 깨나가야 했습니다. 정말 어려웠습니다.

틀을 깬다는 것은 안해봤던 일을 시도해보고 새로운 틀을 만드는 것이다.
기존의 틀이 개발 생산성에 문제가 된다면 과감하게 깰수 있어야 합니다. 단, 단순한 현상이 아닌 핵심이 되는 원인을 깨야 합니다.
그리고 새로운 틀을 만들 수 있어야 합니다. 그 틀이 멋진 선배들이 만들어 놓은 것이라면 자신에게 맞게 고칠 줄도 알아야 합니다.
새로운 기술, 새로운 방법, 새로운 환경이 매일 차고 넘치기 때문에 소프트웨어 엔지니어라면 항상 틀을 깰수 있어야 합니다.
이미 아는 기술, 써봐던 방법, 경험했던 환경이 아니라고 해서 할 수 없다고 말씀하시는 분은 진정한 소프트웨어 엔지니어가 되기 힘들것입니다.
저는 그 틀을 깨는 경험들을 공유하고 싶습니다.^^ 같이 깨보실래요?ㅋㅋ
저작자 표시 비영리 동일 조건 변경 허락
신고
Posted by 윤청하

댓글을 달아 주세요

  1. 2010.02.22 10:50 신고 k16wire  댓글주소  수정/삭제  댓글쓰기

    그래서 기업에서 스크럼을 도입하면 많은 관리자들이 회사를 나간다고 합니다. 대략 30%정도. :-)

  2. 2010.02.27 10:19 신고 heestory.me  댓글주소  수정/삭제  댓글쓰기

    고인물은 썩는다.라는 말이 생각나네....
    물이 흘러가는 방향이야 자신의 생각대로 가는거라지만...
    물이 고여 썩어버린다면.....쩝..


이번 편은 내 경험의 일차적인 마무리로써 앞으로 해결해야할 숙제들을 정리해보려고 한다.
이것은 말단 팀원으로써의 관점이다!

교차 기능 개발팀 구성

스크럼은 개발팀 구성을 스크럼 마스터, 고객, 제품 관리자, 개발자, 테스터 등으로 구성하도록 제안한다.
우리회사의 개발 프로세스는 단계적으로 매우 고립되어 있으며, 개발팀 구성 또한 개발자만으로 구성된다.
따라서 개발자가 프로젝트를 진행하면서 테스터(QA), 고객 혹은 제품 관리자와 피드백을 주고 받는 경우는 매우 드물다.
(프로젝트가 완료된 후 상용서비스에서 장애 발생시에는 직접적으로 피드백을 주고 받기도 한다.)
개발자는 개발 팀장이 간단하게 언급하는 기능 요구사항을 그저 개발만 하면되는 프로세스이다. 

최근에 구매해서 보고 있는 책에서 교차 기능팀(cross-functional team, Wikipedia)에 대해 소개하고 있다.
이해 관계자 중심 소프트웨어 개발
고객의 비즈니스 가치를 드높이는 개발 접근법
칼 케슬러, 존 스웨이처
차영호 역
인사이트
이 책에서 저자는 개발팀은 가능한한 교차 기능팀으로 구성되어야 한다고 주장한다.
개발팀으로써의 교차 기능팀의 인적 자원 구성은 스크럼에서 요구하는 구성원 정도면 충분하다.
교차 기능 개발팀이 됨으로써 개발자는 고객의 요구사항에 어떤 비즈니스 가치가 있는지 알고 개발할 수 있고, 고객과 함께 서로 윈윈 할수 있는 프로젝트가 될수 있다.
교차 기능 개발팀에서는 모든 팀원이 프로젝트의 비전에 대한 이해도가 높아지며, 소수의 이해관계자만을 만족시키는 결과물을 생산할 가능성이 줄어든다.

교차 기능 개발팀만으로 조직이 구성된다면 문제가 될 수 있다. 하지만, 필요한 경우 교차 기능 개발팀을 유연하게 구성할수 있는 조직이라면 조직의 휴먼 리소스 효율면에서 탁월한 조직이라 할수 있겠다.
애자일 문화가 퍼져서 그 성과가 보여진다면 조직도 바뀔수 있지 않을까?

XP 적용하기

스크럼을 적용하면서 나와 희찬씨(L씨)는 XP의 실천법중 짝프로그래밍과 테스트주도개발을 팀에 적용하고자 하였다. 짝프로그래밍은 팀장님이 반대하셨으나, 테스트주도개발은 한번 해보면 괜찮을것 같다는 반응이셨다.
익스트림 프로그래밍 2판
변화를 포용하라 
켄트벡, 신시아 안드레스
정지호, 김창준 역
인사이트
우리는 제대로된 짝프로그래밍은 못하였으나 짝을 지어서 개발을 하도록 노력하였다.
단일 기능에 대한 요구사항 분석, 설계, 개발, 테스트등을 짝을 지어서 개발하였다. (원래는 혼자 해야 한다.)
그나마 다행인것은, 팀장님의 배려로 짝으로 구성하여 자리를 옮길 수 있었다.
혼자 고민하던 것을 짝을 지어서 실시간으로 피드백을 주고 받다 보니 선택의 기로에서 정체되는 일이 드물었으며 개발의 완성도 또한 높았다. 하지만 혼자해야 할 작업에 두명이 투입되었기 때문에 시간적으로 2배 빠르게 진행되어야 했다.
또다른 장점은 코드 공유의 범위가 확대 되었으며, 무 집중도가 매우 크게 상승했다는 것이다.
불행히도 위에 열거한 장점들은 나와 희찬씨만 느꼈을 뿐 다른 팀원들은 이전 방법으로 되돌아 갔다.

올해 우리회사 슬로건 중 하나는 "장애율 0%" 이다. 
이 슬로건을 연구소에 내밀었을때 연구소의 개발자들은 매우 흥분하였다. "버그 없는 소프트웨어는 없다!"
이와 같은 슬로건이 나오게 된 것은 당연히! 작년에 회사의 신뢰도에 문제가 있을 정도로 장애가 많았기 때문이다.
VoIP가 대체 통신 수단에서 주 통신 수단으로 서서히 변경되면서 품질에 대한 걱정은 더 커져갔다.
연구소에는 자동화 테스트의 개념은 전혀 없었으며, 제품에 새로운 기능이 추가될 때 회귀 테스트도 없었다. (기본 기능의 성공 케이스만 확인하는 정도)

난 켄트백의 테스트 주도 개발 책을 보면서 이것이 바로 우리 회사에서 적용해야 할 첫번째 실천법이라고 생각했다.
테스트 주도 개발
Test Driven Development by example
켄트 벡
김창준 역
인사이트
그리고 회사 내의 수석 개발자를 찾아갔다. 그분이 이미 알고 있는 듯한 눈치였으며, 이런거는 회사 현실에서는 맞지 않는다는 뉘앙스를 풍기셨다. 팀장님도 그다지 환영하는 분위기는 아니었다.
물론 두분 다~ 자동화 테스트가 정말 필요하다는 것은 동의하셨다. 
테스트 주도 개발은 자동화 테스트를 누구나(?) 쉽게 만들 수 있는 명료한 방법이다.
  • 테스트 먼저 작성하라
  • 중복을 제거하라
희찬씨와 나는 신규 비디오 코덱 개발에 테스트 주도 개발을 적용하였다. 결과는 참담했다.
비율로 보자면 20 : 80 정도로 기존 개발 방식을 거의 고수하였던 것이다.ㅠㅠ

얼마전에 있었던 xper 정기모임에서 나는 테스트 주도 개발 실천법이 적용하기 어렵지만 그 효과는 매우 크다는 것을 다시 한번 깨달았다. 테스트 주도 개발을 팀에 제대로 적용할 수 있다면 지금처럼 팀의 리소스의 30% 이상을 유지보수에 힘쓰고 있지는 않을 것이다.

문화 바꾸기

애자일에서 팀웍은 매우 중요하다. 즉, 혼자 잘해서 될일이 아니다.
팀 혹은 조직의 문화가 바뀐다면 사람도 바뀔 것이고 조직의 가치도 바뀔 것이다. 
그 안에서 애자일 실천법의 적용은 매우 쉬울 수도 있다.
팀장도 아닌 말단 개발자인 내가 팀과 조직의 문화를 바꾸려면 매우 힘들다는 것을 잘 안다.
하지만 나의 지지자(도반)들을 꾸준히 늘려나간다면, 그리고 이와 같은 생각들을 공유한다면 언젠가는 내가 속해있는 조직도 고효율의 조직이 될 수 있을 것이라 확신한다.

마무리

당분간, 난 테스트 주도 개발에 익숙해 지기 위해 매진할 것이다. 일단 고!
같이 하실분 없나요?^---------^

읽어주셔서 감사합니다!~ 
그냥 가지 마시고 리플로 피드백을 해주신다면 정말 정말 백만개 감사할 것 같습니다.^^
저작자 표시 비영리 동일 조건 변경 허락
신고
Posted by 윤청하

댓글을 달아 주세요

  1. 2009.10.28 17:48 신고 YUZI  댓글주소  수정/삭제  댓글쓰기

    연재 잘 읽었습니다. Cross-functional은 한팀에서 하기 어려울텐데 결과가 기대되네요.
    다양하고 많은 수행이 예정되어 있군요. 화이팅입니다.

    • 2009.10.28 18:11 신고 윤청하  댓글주소  수정/삭제

      감사합니다.^^
      제가 말단이라 다 수행할수 있을지는 모르지만 노력해야죠ㅋㅋ

      물론 교차 기능팀을 한팀으로 구성하기는 힘듭니다.
      가상팀으로 구성해도 괜찮을것 같아요.
      예를 들면 데일리 미팅을 같이 하는 방법으로..^^
      현실적으로 접근할 필요성이 있을것 같아요~

  2. 2009.10.29 12:43 신고 ParkPD  댓글주소  수정/삭제  댓글쓰기

    Mock 환경을 잘 갖춰놓은 다음에야
    다른 팀원들도 테스트를 작성하기 시작하더군요.
    시간이 좀 걸리는 일이지만, 일단 굴러가기 시작하면 좋아지는 걸 느끼실 수 있을 겁니다.
    좋은 글 감사합니다.

    • 2009.10.29 13:20 신고 윤청하  댓글주소  수정/삭제

      괜찮은데요? +_+
      저희는 프로세스간에 메시지를 주고받는 일이 많은데..
      큰부분부터 고민해보고 실행에 옮겨봐야 겠습니다.^^
      구체적인 방법을 제시해주셔서 감사합니다~

  3. 2009.10.29 17:54 신고 heestory.me  댓글주소  수정/삭제  댓글쓰기

    테스트 주도 개발..처음에는 쉬울거라 생각했는데..
    막상 해보니 익숙해지려면 시간이 좀 걸릴것 같네요..OTL
    그래도 홧팅-ㅎㅎ

  4. 2009.10.29 18:22 신고 박형근  댓글주소  수정/삭제  댓글쓰기

    재미있고 유익한 연재 잘 봤습니다.
    다음 연재도 기다려 지네요 ^^
    개인적인 의견으로는 ,
    테스트가 없는 기존 코드가 크게 있고, 거기에 기능을 추가/변경 해 나가는 경우라면 좀 큰 단위의 테스트케이스를
    먼저 작성하는것이 효율적이라 생각합니다. (유닛테스트라기 보다는 '기능테스트')
    저희 팀은 UnitTest가 실질적으로 정착되는데 약 3년 정도 걸린것 같구요.
    기존 코드가 테스트하기 어려운 구조여서 간단한 테스트케이스 만드는데도 시간이 오래걸리니 다들 안하려 하더군요.
    조금씩 코드가 정리되고, 테스트를 편하게 할 수 있는 helper기능들이 추가되니 테스트케이스만드는데 부담이
    적어지면서, 그때서야 정착이 되었던것 같습니다.
    지금은 다들 중요성을 인정하고 있구요.
    과정이 좀 힘들지만 꼭 성공하시길 바랍니다.!!

    • 2009.10.29 18:55 신고 윤청하  댓글주소  수정/삭제

      좋게 봐주시고 명쾌한 피드백 주셔서 감사합니다.^^
      오늘부터 짬나는 시간에 해야 할일들이 머릿속에 정리되는 느낌입니다.
      1) 좀더 큰 부분(기능단위)부터 테스트 케이스 작성을 시도하자.
      2) 테스트에 도움이 되는 것들 (mock object, helper등)을 정리하고 만들자.
      갑자기 뽐뿌 받았습니다!~ 블로깅 하는거 너무 재미있네요~ 진작 할껄~ㅋㅋ

  5. 2010.01.16 23:11 신고 귀뫄뉘  댓글주소  수정/삭제  댓글쓰기

    다른 애자일 관련 포스팅에는 원론적인 글 밖에 없어서 식상했는데,
    실제 적용사례와 효과까지 들려주시니 마치 제가 경험하는 것처럼 재미있네요
    좋은 포스팅 감사합니다 ^^

  6. 2010.10.14 23:47 신고 움케  댓글주소  수정/삭제  댓글쓰기

    잘 읽었습니다. 내용이 참 실용적이네요. ㅎ

    사실 새로운 개발 방법론 같은 것을 프로젝트 매니저가 자신의 팀에 도입하려해도 성공하기 힘들다고 생각하는데,
    말단 팀원이 팀을 변화시키기위해 고생 많이 하시네요. 먼저 매니저를 변화시키고, 좋은 결과 거두시길...

    • 2010.10.18 19:43 신고 윤청하  댓글주소  수정/삭제

      읽어주셔서 감사합니다.
      현재 저는 해당 팀을 나왔습니다^^;;
      새로운 곳에서 변화를 꿈꾸고 있습니다. 꼭 애자일이 아니더라도~

2009/10/12 - [Agile Experience] - 우리 팀에 스크럼을 적용했어요 - 1편
2009/10/13 - [Agile Experience] - 우리 팀에 스크럼을 적용했어요 - 2편
2009/10/19 - [Agile Experience] - 우리 팀에 스크럼을 적용했어요 - 3편
2009/10/28 - [Agile Experience] - 우리 팀에 스크럼을 적용했어요 - 마무리

1편에서 빼먹은 내용

이 글은 수개월에 걸쳐 스크럼을 개발팀에 적용한 경험을 바탕으로 작성되었다.
개발팀은 7명의 개발자로 이루어져 있으며, 팀의 주된 업무는 통신용 서버 시스템 및 플래폼 개발이다.
실패든 성공이든 각자의 경험을 공유함으로써 한국의 개발자들도 인간적인 삶을 살수 있다는 믿음으로 이 글을 작성한다.

스프린트 회고

스크럼에서 스프린트 사이에 스프린트 회고 및 스프린트 계획 회의는 반드시 해야 할 일들이다.
초기의 스프린트 회고는 스프린트 동안 스크럼을 적용하면서 각자 느낀점을 나누는 정도였다.
데모를 하자는 의견을 냈으나, 다수의 분들이 데모의 필요성을 느끼지 못하여 적용하지 못했다.
몇번의 스프린트가 진행되고 나서 우리는 스프린트 데모의 필요성을 느꼈다.
우리는 스프린트 계획 회의에서 각 스프린트 백로그를 어떻게 데모 할 것인지 결정하였다.
결과적으로 우리는 스프린트 회고를 하면서 자연스럽게 스프린트 백로그 별로 데모를 진행하게 되었다.
말로만 주고받던 회고에서는 없었던 날카로운 피드백을 눈으로 보이는 데모를 진행하면서 주고받게 되었다.
우리는 점점 오픈되고 있었고 우리의 제품은 점점 발전하고 있었다. 조금씩 조금씩..

스프린트 계획 회의

우리의 스프린트 계획 회의는 한번에 끝나는 일이 없었으며, 지연되기 일쑤였다.
회의를 지연시키는 원인중 하나는 스프린트 백로그의 예상 시간을 결정하는 일(추정)이었다.
나는 다음의 책에서 소개하는 플래닝 포커를 적용해 보기로 하였다.
불확실성과 화해하는 프로젝트 추정과 계획 
(규모추정, 우선순위, 일정배치)
Agile Estimating and Planning
마이크 콘 지음 (이병준 역, 인사이트)

재미있게도 위의 책을 주문 하였더니 인사이트에서 플래닝 포커를 할수 있는 매우 이쁜 카드를 보내주셨다.

불확실성과 화해하는 프로젝트 추정과 계획 책을 주문하고 받은 선물

플래닝 포커는 우리가 스프린트 계획 회의를 재미있고 빠르게 진행 할 수 있도록 실질적인 도움을 주었다.
특정 사람(특히 경력이 많은)의 의견이 99% 적용되던 이전과는 달리 우리는 해당 백로그에 대한 여러가지 관점을 통해 매우 의미있는 예상시간(추정치)를 만들 수 있었다.

회의를 지연시키는 다른 원인은 스크럼 마스터를 중심으로 스프린트 백로그를 하나씩 검토해 나가는 방식이었다
우리는 스프린트 백로그를 순차적으로 하나씩 검토하고 정리하는 방식이 회의에 참가하는 리소스(팀원들)를 크게 낭비하는 것임을 깨달았다. 이는 마치 나와 관계 없는 회의에 참가하는 것과 같았다.
우리는 고민 끝에 스토리 카드와 포스트잇을 사용하기로 하였다. 절차는 다음과 같다.
  1. 스프린트 계획 회의 전에 스크럼 마스터는 스토리 카드를 출력해 온다.
  2. 회의실 벽에 스토리 카드를 분산시켜서 붙여놓는다.
  3. 스크럼 마스터는 계획 회의 시작을 알리고 팀원들은 모두 일어난다.
  4. 팀원들은 각자 관련있는 스토리 카드에 앞에 서서 추정치를 의논하고 예상되는 테스크들을 포스트잇에 적어 붙인다.
  5. 모든 스토리 카드가 추정될 때 까지 계속 한다.

스토리 카드와 포스트잇의 내용은 아래와 같다.
  • 스토리 카드에는 스프린트 백로그 번호와 내용이 간략하게 적혀있다.
  • 스토리 카드에는 스프린트 백로그의 추정치 및 데모방법을 적을 수 있는 공간이 있다.
  • 포스트잇에는 테스크 내용, 추정치 및 테스트 방법들을 적을 수 있다.
  • 스토리 카드의 추정치는 일 단위로 하였으며 테스크의 추정치는 시간 단위로 하였다.

우리의 방법은 대성공이었다. 
2~3시간의 스프린트 계획 회의에서 끝내지 못한 내용들을 단, 30분 만에 끝낼 수 있었다.

아날로그로의 귀환

이제 우리의 스프린트 계획 회의의 결과물은 스토리 카드와 테스크들을 적은 포스트잇이다.
따라서 우리에게 디지털로 저장하는 것은 매우 귀찮은 일이 되었다. 
히스토리를 남기길 원하셨던 팀장님 마져 손을 드셨다. 
사실 히스토리를 남기는 게 좋다ㅠㅠ 단지, 우리는 귀찮아서 안할뿐이다.
그래서 우리는 기존에 사용하던 화이트보드보다 더 큰 사이즈를 주문하여 다음과 같이 사용하고 있다.

스프린트 백로그 화이트보드

자세히~

포스트잇을 사용하게 되니, 각 테스크를 3단계(준비, 진행중, 완료)로 구분하여 관리할 수 있었다.
데일리 미팅 시간이 좀 더 역동적으로 변하였으며, 팀 영역에 들어오는 어느 누구도 현재 팀에서 진행중인 작업 내용을 꽤 자세히 확인할 수 있게 되었다.
포스트잇을 하나씩 완료영역으로 옮겨 붙이면서 쾌감을 느끼기도 했지만, 진행이 잘안될 때에는 큰 스트레스로 작용하기도 하였다. 
日新又日新 : 우리는 스크럼이 우리가 서로 커뮤니케이션 하기 편한 형태로 점점 진화하고 있다는 것을 느낄 수 있었다.

다음 편은 내가 느낀 우리팀과 스크럼의 한계에 대해 작성해보고자 한다. 
피드백 좀 부탁드려요~~~~~^----------------------^
저작자 표시 비영리 동일 조건 변경 허락
신고
Posted by 윤청하

댓글을 달아 주세요

  1. 2009.10.21 00:25 신고 A2  댓글주소  수정/삭제  댓글쓰기

    이번편도 재밌게 읽었습니다.
    많은 도움이 되었습니다. ^^

  2. 2009.10.22 02:20 신고 heestory.me  댓글주소  수정/삭제  댓글쓰기

    카드와 아날로그로의 귀환은 효과 만점인듯.....ㅋㅋ
    히스토리를 남기기는 어렵지만...막상 없애고 보니..그다지 필요해보이지도 않는..;;ㅋㅋ

    • 2009.10.22 09:12 신고 윤청하  댓글주소  수정/삭제

      회고할때, 이후에 비슷한 프로젝트를 다시 진행할 때 도움이 될 수도 있을거에요.ㅋ
      근데 희찬씨 웹폰트에 싸이트 제한 걸려있데요~ 그래서 제가 드린거 써도 안될거에요.ㅋㅋ 직접 TTF 파일을 웹폰트 파일로 변환하고 자기 싸이트 주소 넣어줘야 함...ㅡㅡ^ (난 나눔고딕으로 바꿨어요)

    • 2009.10.22 11:15 신고 heestory.me  댓글주소  수정/삭제

      변환 프로그램 주삼-ㅋㅋ
      저두 맘 편하게 나눔고딕으로 해야될듯..ㅋㅋ

    • 2009.10.22 11:46 신고 윤청하  댓글주소  수정/삭제

      완벽 가이드...ㅋㅋ
      http://pangsan.tistory.com/102

  3. 2009.10.27 09:41 신고 박형근  댓글주소  수정/삭제  댓글쓰기

    재미있네요!
    저도 비슷한 단계를 밟고 있어서 많이 공감이 됩니다.
    이미 아실지 모르겠지만 '포스트잇'중에 '슈퍼 스티키'라고 되어있는 놈들을 사용하면 칠판에서 잘 안떨어져서 좋습니다.^^

    • 2009.10.27 10:54 신고 윤청하  댓글주소  수정/삭제

      동지를 만났네요^^ 서로의 경험을 같이 공유해요~
      저도 '슈퍼 스티키'를 쓰고 싶지만, 이미 회사에서 구매해 놓은게 많아서 사달라고 하기 좀 그래서요~~
      제가 후딱 다 써버리고 사달라고 해야겠어요..ㅋㅋ

  4. 2011.10.07 17:35 신고 후이총총  댓글주소  수정/삭제  댓글쓰기

    오호~~` 포털에서 검색을 하다 들어와서 글을 보게되었어요.
    저희 회사에서 저희는 본부 차원에서 지금 스크럼을 검토하고 있는데..(사실 회사 여기저기서 본부, 팀 차원에서 여러군데 시도는 하고 있는듯 해요) 실제 외국계 회사에서 여러차례 스크럼하는 것을 지켜보다 오신 분의 이야기를 들어보니 '이걸 왜 하려는지 잘 모르겠다'라고 하시더라구요. 굉장히 힘들꺼고...아무리 노력해도 안 될지도 모른다고..도 이야기 하셔서...좌절해 있었는데..
    이렇게 아무렇지도 않게 은근 슬쩍...기법으로 적용을 하셨다니...대단해보이세요~ 아...현재 저희는 함께 스터디나 해보자는 차원이지미나 저희 본부장님은 궁극적으로 함께 경험해보고 각 PM이 프로젝트를 그렇게 진행하기를 바라고 있거든요...이게 될까요...ㅡ.ㅡaaa

    • 2011.10.12 06:54 신고 윤청하  댓글주소  수정/삭제

      반갑습니다! 본부장님에 의한 Top-Down이군요~ 시도해봐서 나쁠것은 없다고 생각해요~
      단, 본부 전체적으로 시작하는 것 보다는, 가장 의욕적인 팀이 파일럿 팀이 되어 진행해보고
      소속된 본부의 업무 진행 방식이나 제품 개발 형태에 맞게 잘 다듬은 다음에 확산시켜서 같이 해보는 것이 좋을것 같아요~

      전 현재 소속팀에서 스크럼을 하지 않고 있습니다.
      여러가지 이유가 있겠지만, 팀원들이 가장 부담스러워 하는 부분은 업무를 구체적으로 쪼개어 정리해야하는 부담감과 스케쥴이 완전히 오픈되는 것을 꺼려하더라구요.
      그리고 스크럼 하면 업무 몰입도(혹은 긴장감)가 너무 높아져서 부장용을 낳기도 합니다.

      도움이 되셨는지 모르겠네요^^;

  5. 2012.02.23 07:31 신고 행복한길용이  댓글주소  수정/삭제  댓글쓰기

    좋은글 잘읽고 갑니다 자주들릴께요

  6. 2012.02.23 07:32 신고 행복한길용이  댓글주소  수정/삭제  댓글쓰기

    좋은글 잘읽고 갑니다 자주들릴께요


어느날 아침에 한 영업실의 실장님과 간단한 대화를 나누었다. 그때 실장님은 귀에 거슬리는 말씀을 하셨다.
맨날 구조 바꾸고 갈아 엎는다고만 하지 말고 생각 좀 해서 개발해봐! 버그만 심지 말고..
이전에(애자일 마인드를 갖기 전) 이 말씀을 들었다면 매우 부정적으로 "니가 개발을 알아?" 라고 마음속으로 콧방귀를 꼈을 것이다. 하지만 오늘 나는 개발자로써 반성문을 써보고 무엇이 문제인지 밝혀보고자 한다.

영업부서와 개발부서와의 미팅에서 개발자들이 시간적으로나 기능적으로 불합리한 요구사항에 대처하는 핑계중에 하나는 아마 다음과 같을 것이다.
현재 우리 구조에는 적용하기 어렵습니다. 적용하더라도 시간이 걸릴것 같으며, 추후에는 전체적으로 뒤집어 엎어야 합니다.
실제로 내가 다니고 있는 회사의 모습만 봐도 구조 및 설계 개선 등의 이유로 전체 시스템 소스코드를 뒤집어 엎는 경우(전역 리팩토링)가 매우 많다. 우리팀도 작년부터 이전 플래폼을 개선한다는 이유로 2.0이라는 이름을 달고 1년이 넘게 팀의 리소스 중 많은 부분을 플래폼 구조 개선 작업에 투입하였다.

문제는 이러한 작업의 결과가 비지니스적인 가치로 창출되는 경우는 매우 드물다는 것이다. 오히려 새로운 소스코드에 대한 검증 및 안정화 작업으로 인한 업무 오버헤드가 더 증가할 수 있다. 물론 추후 생길수 있는 요구사항을 손쉽게 적용할 수 있을 수도 있다. 그러나 이것은 XP를 인용해보자면 쓸데없는 짓이다. "사용자 스토리"라는 책을 보면 스토리(요구사항)는 투자되는 리소스 대비 비지니스적인 가치가 높은 것의 우선순위를 높게 책정하도록 권장하고 있다. 지금 현재 다른 업무가 거의 없지 않은 이상 전체를 뒤집어 엎는 스토리의 우선순위는 높아질 수 없는것이 자명하다.

그렇다면, 무엇이 문제일까? 개발을 잘 못한 개발자들만의 잘못일까? 이와 같은 일이 벌어지는 이유를 내 경험을 통해 정리해 보겠다. (현재 재직중인 회사만의 현상일 수 있으나, 한국의 개발회사는 크게 차이 없을 것으로 생각된다.)
  1. 개발자마다 "개발완료"의 의미가 다르다.
    어떤 개발자는 코딩 및 컴파일 완료를 개발 완료라고 생각한다.
    어떤 개발자는 기능 테스트(화이트 박스 테스트) 완료를 개발 완료라고 생각한다.
    어떤 개발자는 리팩토링까지 완료해야 개발 완료라고 생각한다.
    불행히도 많은 경우에 두번째의 경우를 개발 완료라고 생각한다.
  2. 개발 기간이 너무 촉박하다.
    영업부서에서 전달하는 요구사항 대비 주어지는 개발 기간이 매우 적은 경우가 많다.
    이럴 경우 핵심적인 기능(비지니스적인 가치가 높은)을 선별적으로 개발해야 하나, 대부분의 협의는 모든 기능 구현으로 종결된다.
    즉, 개발자는 기능 구현에만 집착하게 되며, 리팩토링은 신경쓸 수 없게 된다.
  3. 과도한 업무로 보상 심리가 강해진다.
    개발양은 많고 개발 기간이 촉박해지면, 잦은 야근, 밤샘 작업 및 주말 작업은 일상생활이 된다.
    이로 인해, 프로젝트가 일단락 되어 여유 시간이 생기더라도 보상 심리로 인해 리팩토링 작업은 미뤄지게 된다.
  4. 리팩토링에 대한 교육이 없다.
    리팩토링 뿐만이 아니겠지만, 리팩토링을 강조하고 무엇을, 어떻게 해야하지는 알려주지 않는다.
  5. 깨진 자동차 유리 
    "실용주의 프로그래머"라는 책에 소개된 깨진 자동차 유리 실험처럼, 지속적인 리팩토링이 이루어지지 않은 코드의 중복성은 기하 급수적으로 증가하게 된다.

이유를 적다보니 개발자의 책임이 큰것을 알 수 있었다ㅠㅠ. 
물론 영업부서의 유연하지 못한 요구사항도 큰 문제이다.

나의 결론은 간단하다. 목표는 전체적으로 뒤집어 엎어야 하는 경우를 줄이는 것이다. 
다음과 같은 원칙을 가지고 개발한다면 어느정도 도움이 될 것이다.
  • 항상 중복을 제거한다. [리팩토링]
  • 코딩 전에 테스트를 작성한다. [TDD , 어렵다면 어떻게 테스트를 할지 미리 결정해야 한다.]
  • 설계와 구현은 동시에 진행한다. [XP, 점진적인 설계]
  • 코드 공유 및 리뷰를 수행한다. [XP, Pair Programming]

하지만, 시간이 촉박한 프로젝트의 경우에 해답을 찾기란 쉽지 않다.
결국은 영업 부서와 개발 부서가 한팀이 되어 긴밀한 협업을 하는 것이 중요한 관건이다.
협업이 원활이 이루어 진다면 영업 부서는 비지니스 적인 가치를 극대화 할수 있으며, 개발팀은 핵심 기능에 집중하여 더욱 신뢰성 높일 수 있을 것이다. 고객과의 협업까지 이루어 진다면 금상첨화가 아닐수 없다.
영업 부서와의 협업 방법으로 사용자 스토리스크럼을 추천한다.^^

사용자 스토리와 스크럼에 대한 내용은 다음 책을 참고하면 좋다.
사용자 스토리
고객 중심의 요구사항 기법
마이크 콘, 심우곤 역
인사이트
스크럼과 XP
애자일 최전선에서 일군 성공 무용담
헨릭 크닉버그
인사이트
신고
Posted by 윤청하

댓글을 달아 주세요

  1. 2009.11.05 14:09 신고 윤청하  댓글주소  수정/삭제  댓글쓰기

    스스로 피드백~ (아무도 안줘서..ㅋㅋ)
    거의 동일한 기능을 가지는 새로운 제품을 만들때(설계/구조 개선등의 목적) 생기는 또하나의 단점은
    만약 새로운 제품이 기 제품이 납품된 싸이트에 적용(migration) 될 수 없다면 개발팀으로써는 거의 동일한 두가지 제품을 follow-up 및 유지보수 해야 하는 것이다. 이는 혹떼러 갔다가 혹 더붙이는 꼴이 될 수 있다.
    (특히 상용에서 정상적으로 서비스 중인 제품을 검증되지 않은 새 제품으로 migration 하는 작업을 달가워할 고객은 별로 없을 것이다. - 설득의 문제)

  2. 2009.11.05 14:11 신고 윤청하  댓글주소  수정/삭제  댓글쓰기

    최근 옆팀에서 기존 제품에서 설계/구조 개선을 목적으로 새로 제품을 개발하는 작업을 시작하였다.
    이 팀의 경우 신규 팀원들의 능력 및 업무 만족도 향상이 이 작업의 목적중 하나라고 하였다.
    새로 만드는 것만이 교육적으로 의미가 있고 업무 만족도를 향상 시킬수 있다는 것은 생각해 볼 문제이다.^^

  3. 2009.11.12 18:01 신고 neokido  댓글주소  수정/삭제  댓글쓰기

    좋은 내용 참 잘 읽었습니다. ^^

    제가 TDD와 리팩토링 관련 컨퍼런스에 갔었는데. 그때는 초창기라 TDD와 리팩토링에 대한 관심이 대단했던것 같습니다. 그런데 거기 발표자의 발표 내용에서 제가 느낀것은 그 발표자가 말하는 TDD와 리팩토링의 목표가 정확히 무엇인지 알수 없는 말들을 늘어놓았다는 것입니다. (그분은 그냥 TDD를 이용하고, 이렇게 리팩토링을 하면 소스가 이렇게 짧아지고, .. 틈만나면 리팩토링을 해서 좀더 멋지게 잘 돌아가는 코드를 만든다.. 어쩌고.. 저쩌고..)

    과연 TDD와 리팩토링의 목적은 무엇인가? 에 대한 나름대로의 답을 가지고 있을거라 생각합니다.
    하지만 그 나름대로의 생각이, 회사의 이익으로 나타나지 않는다면 그것은 의미가 없을것입니다.

    단지 개발자 자신이 좋아서 하는 리팩토링,
    내가 만든 코드가 상당히 간결하니 내것을 쓰는게 좋을꺼야.. 자 ~ 써.~..
    남들이 TDD랑 리팩토링은 좋은 것이고, 꼭 해야한다고 생각해서
    기타 등등..

    이런 생각의 개발은 프로젝트중에서 또하나의 구멍을 뚫어서 자원을 낭비하는 거나 다름 없는 것이라 생각합니다.
    이제는 개발자가, 사용자와 니즈에 대한 적극적인 자세와 마인드로 개발을 해야할 시대인듯 합니다.
    좀더 Business적인 관점의 개발 마인드를 가지고, 그러한 Business needs 를 구현하기 위해서, TDD나 리팩토링은 좀더 Agile하게 개발을 쉽고, 명확하게 할수 있는 아주 좋은 툴이 될것같네요.

    님의 항상 연구하고, 적용하고자 하는 모습에 저도 다시한번 자극을 받게 되네요 ^^

    자주와서 좋은정보 공유하고 싶습니다. ^^

    • 2009.11.13 10:40 신고 윤청하  댓글주소  수정/삭제

      크나큰 관심과 엄청난 피드백 감사드립니다.^----^
      저는 고객의 비즈니스 가치는 개발자에게 매우 큰 동기 부여라고 생각합니다. 개발자는 자신이 개발하는 기능이 고객의 어떤 환경에서 어떻게 동작하고 어떤 이로움을 주는지 명확하게 알아야 한다고 생각합니다.
      그래서 저는 개발자의 시야가 좀더 넓어질수 있는 '기능개발팀' 혹은 '교차기능팀'을 구성하는 것을 회사에 제안하고 싶지만..
      아쉽게도 아직은 어렵네요.. 기술적 배경으로 성장한 회사라 그런지 기술적 성장에 더 관심이 많은것 같습니다.^^

      TDD는 고객에게 꼭 필요한 기능들을 명확하게 개발하고 품질을 보장할 수 있는 좋은 방법중에 하나라고 생각합니다.~

      다시한번 좋은 말씀 감사드리구요~ 피드백은 언제나 환영입니다.^^

  4. 2010.04.21 11:01 신고 ryoo  댓글주소  수정/삭제  댓글쓰기

    좋은 글 감사합니다..
    영업부와 항상 피해의식만 생겼었는데 이 글을 보니 개발자도 달라져야겠다는 생각이 드네요.
    개발자의 책임이 큰만큼 먼저 반성하고 주도적으로 이끌수 있는 프로젝트를 역량을 갖춰야겠습니다.


스크럼의 빠른 피드백

8주에 걸친 2번의 스프린트가 끝나고 우리 팀은 처음으로 강남 토즈에서 팀 미팅을 진행하였다.
주제는 "스프린트 회고 및 다음 분기 프로젝트 계획" 이었다.
미팅은 하루 종일 진행 되었고, 프로젝트 별 특정 주제까지 언급하였으나 누구 하나 지루해 하지 않았다.
이유는 간단하게 스크럼에서 찾을 수 있었다. 
우리는 이미 4주간 서로간의 업무를 공유하고 있었기 때문에 자신과 관련이 없는 프로젝트라 할지라도 듣고 이해하고 의견을 개진할수 있게 된 것이었다.
이는 개인 회고를 통해서 고백되었다.
"하루 목표가 분명하기 때문에 업무 시간에 더욱 집중 할 수 있었어요."
"데일리 미팅때 모두가 있는 자리에서 이슈를 설명하니 간단히 해결되는 경우가 많았어요."
"팀원들이 어떤 작업을 하고 있는지 알고 있다는게 도움이 되네요."
스크럼이 이렇게 빠른 피드백을 줄수 있는지 우리는 상상하지 못했었다.
또한 스크럼 하기 전에 진행되던 프로젝트가 오랫동안 지연되고 있었는데(결과물 없이) 약 8주동안 큰 진전이 있었으며 나름 의미있는 릴리즈를 시행하였다.


어떻게 정리할까?

우리는 화이트보드에는 데일리미팅에서 제시되는 테스크를 정리하고 엑셀에는 스프린트백로그를 정리하였다.
엑셀 파일은 공유하기 힘들어서 대부분의 내용 작성은 팀장님이 하셨다.
우리는 백로그를 해당 담당자가 직접 작성하고 관리하기를 원했다.
우리는 여러가지 스크럼 툴을 사용해보기로 하였다.
우리의 요구사항은 "간단한 GUI, 쉬운 사용법 이었다."
  1. IceScrum (http://www.icescrum.org/)
    - 아기자기하고 친근한 GUI로 우리의 눈길을 끌었으나, 사용법이 어려웠다.
    - 현재 IceScrum2가 릴리즈되어서 제공중이다. (사용해 보지 못하였으나 많이 개선된 듯한 느낌~)

    IceScrum2의 스토리를 이용한 스프린트 백로그 관리

  2. Trac (http://trac.edgewall.org/)
    - 개인적으로 위키를 매우 좋아해서 추천했으나 팀원들의 위키 사용 반대로 좌절되었다.
    - 현재 사내에서 사용중인 ClearCase(SCM)와도 연동할수 있어서 많이 끌렸었다.

    프로젝트 관리용으로 많이 쓴다는 Trac

  3. Pivotal Tracker (http://www.pivotaltracker.com)
    - 웹에서 서비스하지만 무료라서 일단 환영받았다. (개발 서버 부족으로 따로 웹서버를 돌릴 여유가 없었다.)
    - 직관적이고 깔끔한 GUI가 인상적이었으며, 사용법 또한 간단하였다.
    - 스프린트 시작일을 지정할 수 없다는 단점이 있었다.

    Pivotal Tracker의 스토리 관리

여러가지 툴을 검토해보고 써본 결과 우리에게는 Pivotal Tracker가 가장 알맞을 것이라는 결론을 내렸다.
결론을 내린 다음 스프린트 부터는 Pivotal Tracker를 사용하였다.

툴만 정하면 될것이라 여겼으나 툴 사용 첫날부터 삐걱거리기 시작하였다.
Pivotal Tracker에는 스토리 밑에 테스크라는 개념이 없는데 테스크 별로 모두 웹에 등록하려면 매우 비효율적이라는 것이었다.
XP의 윈윈윈 정신에 입각하여 우리는 어느정도의 크기로 스토리를 작성할 것인지, 테스크 관리는 어떻게 할 것인지 고민하였다. 고민의 결론은 다음과 같다.
  • 스토리는 비지니스적인 가치를 지닌 하나의 기능 정도의 크기를 갖는다.
  • 스토리는 프로젝트 담당자가 팀장님과 협의하여 작성한다.
  • 테스크는 해당 스토리를 완성하기 위해 필요한 작업들을 1~2일 정도 크기를 갖는다.
  • 테스크는 데일리미팅에서 화이트보드에 작성한다.


처음 블로그를 시작하여 올리는 글들인데 쓰다보니 스스로 회고도 되고 굉장히 재미있네요^^
다음편에서는 결국 모두 아날로그로 돌아가게 된 사연을 써보겠습니다. 감사합니다.
신고
Posted by 윤청하

댓글을 달아 주세요

  1. 2009.10.14 06:12 신고 heestory.me  댓글주소  수정/삭제  댓글쓰기

    ㅋ글 잘 쓰시에용-ㅎ

  2. 2009.10.14 11:53 신고 eminency  댓글주소  수정/삭제  댓글쓰기

    재밌게 읽었네, 나도 개발이 그립구만...

  3. 2009.10.17 17:20 신고 A2  댓글주소  수정/삭제  댓글쓰기

    1, 2편 읽었습니다. ^^
    좋은 글이네요.
    제가 일하는 곳도 이번에 처음 스크럼을 도입했습니다.
    경험이 거의 없지만 자리를 잡아가면 크게 도움이 될 것 같은 느낌이 옵니다. ^^

  4. 2011.11.08 13:15 신고 A3  댓글주소  수정/삭제  댓글쓰기

    저희 회사에서는 teamoffice쓰는데 좋은 것 같아요.

  5. 2012.02.10 17:40 신고 아멜리에  댓글주소  수정/삭제  댓글쓰기

    pivotaltracker 관련 글 찾다가... 우연히 오게 되었는데요.. ^^;;


    현재 hitask 쓰다가, 불만족스러워서 다른 것으로 옮기려고 하는데요.

    pivotaltracker 는 정말 ui가 직관적이라 마음에 드는데.. . 한꺼번에 작업을 추가할 수 없는것인가여? ㅠㅠ


    저는 개인쇼핑몰 운영자인데...
    애자일 프로젝트를 많이 애기하네여. ^^;;

    프로그래머는 아니지만 함 적용해보고 싶어지네여. ^^;;

    • 2012.02.10 17:57 신고 윤청하  댓글주소  수정/삭제

      협업도구를 찾으신다면 http://pragmaticstory.com/1868 요것도 한번 참고해보세요^^ 괜찮다고 하시네요~~

      애자일은 소프트웨어 개발에만 적용할수 있는건 아니에요.
      아래 링크 참고하시면 유치원에 애자일을 적용한 사례입니다.
      https://www.ibm.com/developerworks/mydeveloperworks/blogs/9e635b49-09e9-4c23-8999-a4d461aeace2/entry/67?lang=en

2009/10/12 - [Agile Experience] - 우리 팀에 스크럼을 적용했어요 - 1편
2009/10/13 - [Agile Experience] - 우리 팀에 스크럼을 적용했어요 - 2편
2009/10/19 - [Agile Experience] - 우리 팀에 스크럼을 적용했어요 - 3편
2009/10/28 - [Agile Experience] - 우리 팀에 스크럼을 적용했어요 - 마무리
2009/12/12 - [Agile Experience] - 회고 : 스크럼 돌아보기
2010/01/21 - [Agile Experience] - 팀 자리를 이동하고 스크럼을 위한 War Board도 이동했습니다!


은근 슬쩍 시작하기


나와 아주 친한 연구원(L씨)는 니코틴 충전시간을 활용하여 현재 우리 팀의 문제점에 대해 고민하였다.

우리 팀은 전형적인 한국의 개발팀과 대동소이했다.
  • BMT 준비로 인한 잦은 밤샘
  • 빈번히 변경되는 요구사항
  • 유지보수 지원으로 인한 신규 프로젝트 지연

그와중에 알게된 해결책 중의 하나가 스크럼이었다. 방법은 매우 단순 했다. 
우리는 금방이라도 팀에 적용할 수 있을 것 같은 환상에 빠졌다. 
결국, 둘이 협공하여 팀장님을 설득하였다.

적용 첫주에는 티타임을 가장하여 은근 슬쩍 데일리 미팅을 진행하였다. 
물론 스크럼, 제품 백로그, 스프린트 등의 전문 용어는 일체 사용하지 않았다.
출근시간이 자유롭기 때문에 한번에 모이기가 힘들어서 데일리 미팅의 시간은 매우 유동적이었다.

팀원들이 데일리 미팅에 익숙해 질 쯔음(약 일주일정도 지난) 스크럼에 대해 언급하기 시작하였다.
팀 서고에 스크럼 관련 책을 비치 하였으며 독서를 독려하였다. (하지만, 실제 책을 읽은 사람은 매우 적었다.)
  • 스크럼 : 팀의 생산성을 극대화 시키는 애자일 방법론 (Ken Schwaber, Mike Beedle)
  • 스크럼과 XP : 애자일 최전선에서 일군 성공 무용담 (헨릭 크니버그)
개인적으로 "스크럼과 XP" 책이 더 따라하기 쉽다고 생각한다.


첫번째 스프린트 회의

얇은 지식을 바탕으로 첫 스프린트 회의를 개최하였다. 프로덕트 백로그는 엑셀로 정리하였다.
프로덕트 백로그 하나씩 짚어가며 정리하다 보니 시간이 매우 오래걸렸다. 
2시간이 걸렸음에도 반도 끝내지 못하고 다음 날을 기약한채 회의를 종료하였다.
(스프린트 기간을 4주로 결정하는 것 조차 오래걸렸다.)
그 결과, 스크럼 도입에 회의적이었던 팀원들은 여러가지 불만을 토로하였다.

"저의 작업 진행 방식(요구사항 검토하고, 개발 계획 및 스케쥴링을 하는)과 크게 차이를 못느끼겠습니다. 
왜 이걸 해야 하죠?"
이유는 간단 했다. 서로 잘 알지 못하면 서로 도움을 줄 수 없기 때문이다. 
(하지만 그당시 난 상대방을 적절히 설득하지 못하였다ㅠㅠ)

결국, 회의 이후에 팀장님께서 일일이 스프린트 백로그를 정리하셨다. OTL


본격적인 스프린트 진행

매일 시간은 달랐지만 하루도 빠지지 않고 데일리 미팅을 진행하였다.
팀원은 8명이었고, 평균 진행 시간은 20~25분이었다. 
고정된 데일리 미팅 시간 갖기, 평균 진행시간을 20분 이하로 줄이기 위해 노력하였으나 실패하였다.
이유는 불행히도 우리 팀은 "개인의 자유"라는 가치를 매우 크게 생각했기 때문이다. (팀장님 포함)
가치에 기반하지 않은 실천방법은 어떤 방법으로도 설득하기 힘들다는 것을 깨달았다.

데일리 미팅에서 언급되는 내용은 한 팀원이 팀내에 비치된 화이트보드에 작성하였다.
백로그별 예측되는 남은 시간은 팀장님이 엑셀을 통하여 정리하였다.
이때까지만 해도 업무 담당자의 의도와 작성자(화이트보드 혹은 엑셀)의 정리 내용에 차이가 발생할 수 있음을 알지 못하였다.

엑셀로 정리한 스프린트 백로그


데일리 미팅에서 가장 어려웠던 점은 "예측되는 남은 시간"만을 적는 것이었다. 
우리는 왜 남는 시간만을 남겨야 하는지 이해하지 못했다.
그리하여 우리는 남은 시간을 예측하지 않고, 최초 예측 시간에서 실제 작업시간을 뺀 값을 정리하는 쪽으로 의견을 모았다.
실제 작업 시간을 남김으로써 프로젝트를 제대로 관하고 있다는 느낌과 그 히스토리를 통해서 무언가 피드백을 받을 수 있다는 상상은 쓸모없는 것임을 매우 나중에 깨달았다.

마지막으로, 나는 팀내 스크럼 도입을 주도하면서 내 지식 혹은 직감을 남에게 전달하는 것이 얼마나 어려운 일인가를 다시 한번 깨닫게 되었다.

다음 편에서는 스크럼 도입 중기에서 겪었던 일들을 정리해보겠습니다. 감사합니다. ^^
신고
Posted by 윤청하

댓글을 달아 주세요

  1. 2009.11.05 17:58 신고 권미정  댓글주소  수정/삭제  댓글쓰기

    서로 잘 알지 못하면 서로 도움을 줄 수 없기 때문..
    대답 명쾌하다. 완전 공감~

티스토리 툴바