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

카테고리

Chungha Story (46)
Agile Experience (22)
My Family (4)
Life Style (8)
Programming (8)
Android (3)
Total128,101
Today109
Yesterday102

2010년을 맞이해서 대대적인 조직개편이 이루어 졌고, 저희 팀 자리가 변경되었습니다.
저는 가장 먼저 떠오른 걱정이 War Board를 어디로 옮길까 였습니다. 
불행히도 변경된 자리는 비좁기로 유명한 곳이었습니다.ㅠㅠ
하지만 저희는 꿋꿋히 War Board의 위치를 저희 마음데로 통로로 선정하고 벽에 못까지 박아서 달았습니다.
결과적으로 War Board와 데일리미팅 진행은 완전히 아주 깨끗하게 공개되었습니다. 
이 통로는 개발자분들 뿐만 아니라 영업, 마케팅 등등의 분들도 다니시는 곳입니다.
본의 아니게 스크럼의 핵심 가치를 실행할 수 있었습니다.^^ 아싸~
그리고 저희 팀에서 스크럼을 한지 1년정도 되가는데 자리 이동을 계기로 더욱 견고해지는 것을 느낄 수 있었습니다. (보는 눈이 많아지니..자연스럽게..ㅋㅋ)

매일 아침 10:30에 진행하는 데일리 미팅

통로에 위치하게된 War Board!

우리의 War Board!

번다운 차트 및 돌발성/미지정 업무 관리



저작자 표시 비영리 동일 조건 변경 허락
신고
Posted by 윤청하

댓글을 달아 주세요

  1. 2010.01.22 18:15 신고 heestory.kr  댓글주소  수정/삭제  댓글쓰기

    ㅋㅋ어디서 많이 보던건데.......역시 숨어서(?)하는것보다 대놓고 해야 제맛.ㅋ

  2. 2010.02.08 15:19 신고 귀뫄뉘  댓글주소  수정/삭제  댓글쓰기

    나 일 많다~ 자랑하는것 같기도 하고 좋아보입니다 ^^
    근데 궁금한게 하나 있는데요. 스크럼 적용시 온라인 툴(MOSS 등등)을 이용하는것과 청하님이 하시는 오프라인을 이용하는 것과 장단점이 뭐가 있을까요? 저도 적용해보고 싶은데, 재밌는건 쪽지 직접 갖다 붙이고 하는 오프라인식이 좋아보이고.. 많고 다양한 히스토리까지 남기고 싶으면 온라인 도구를 이용하는게 좋을것 같고... 경험이 없다보니 참 고민입니다.

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

      이전에 온라인 툴을 몇개 사용해 봤습니다.
      저희가 겪었던 문제점들은 다음과 같습니다~
      1) 잘 안 들어가진다. - 쉽게 접할 수 있어야 하는데 그게 생각처럼 쉽지 않았습니다.
      2) 정리하기 힘들다. - 온라인 툴을 사용하게 되면 그 툴에서 제공하는 틀에 갖히게 됩니다. 따라서 맘데로 정리하기 힘들어집니다.
      3) 한번에 보기 힘들다. - 모니터가 엄청 크지 않은 이상;;;
      4) 생각보다 히스토리를 들춰 보지 않는다. - 히스토리가 중요하지만 생각보다 자세한 히스토리는 보지 않는것 같습니다. 요약된 히스토리는 꼭 필요했습니다. 그리고 남겨야 할 필요성이 있는 것들은 따로 남겼습니다.

      오프라인의 장점
      1) 잼있다.
      2) 쉽다.
      3) 있어 보인다. (나 일 많다~ 자랑하는것도 포함되겠죠..ㅋㅋ)

      스프린트 계획/회고 미팅때에는 오프라인이 정말 좋습니다. 모든 일이 동시 다발적으로 진행되기 때문에 회의 시간도 줄어듭니다. 그리고 팀원들이 더욱 액티브해집니다.

      저희는 일단 재미에 포커스를 두고 오프라인으로 완전히 바꾸었습니다.^^
      저도 많은 경험을 한 것은 아니지만 서로 나누다 보면 더 좋은 결과가 있을것 같습니다. 감사합니다~

    • 2010.02.09 11:07 신고 귀뫄뉘  댓글주소  수정/삭제

      좋은 경험담 알려주셔서 감사합니다. 큰 도움이 되었어요 ^^

  3. 2010.02.10 14:50 신고 충스  댓글주소  수정/삭제  댓글쓰기

    안녕하세요, Xper에서 링크 보고 들어왔습니다.

    차트가 정말로 있어 보입니다....^^
    번다운 차트에서 비정상적으로 꺾이는 부분에 부연 설명을 달아 놓으신 것이 인상적입니다.
    스프린트 회고 때 제안하여 다음번부터 적용해 보아야 겠습니다.

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

      역시 오프라인으로 그리는게 정감이 가는것 같습니다~~
      저 벽에 뭔가 계속 추가될 것 같습니다.
      이번 회고에서는 스프린트 기간이 표시되는 달력을 붙이자는 의견이 나왔습니다.
      팀내외의 일정들을 공유하기에 좋을것 같습니다~
      리플 감사드립니다.^^

  4. 2010.03.11 10:07 신고 ohgyun  댓글주소  수정/삭제  댓글쓰기

    xper 에서 링크타고 들어와 스크럼 적용기를 1편부터 쭉 읽어봤습니다.^^
    저도 소규모 팀내에서 적용해보려다 결국 포기했었는데,..
    정말 좋은 경험담이네요. 다시 시도해봐야겠습니다.
    좋은 포스팅 감사합니다.^^

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

      다 읽어주시다니~ㅠㅠ 너무 감사드립니다!
      포기하지 마세요~!^^ 전 이제 회사를 옮겨서 새로운 시작입니다.
      화이팅!~~ 감사합니다~

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 신고 행복한길용이  댓글주소  수정/삭제  댓글쓰기

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


스크럼의 빠른 피드백

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 신고 권미정  댓글주소  수정/삭제  댓글쓰기

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

티스토리 툴바