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

카테고리

Chungha Story (45)
Agile Experience (22)
My Family (4)
Life Style (8)
Programming (8)
Android (2)
Total164,391
Today14
Yesterday11
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 신고 행복한길용이  댓글주소  수정/삭제  댓글쓰기

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

티스토리 툴바