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

카테고리

Chungha Story (41)
Agile Experience (22)
My Family (0)
Life Style (7)
Programming (8)
Android (2)
Total
Today
Yesterday

달력

« » 2024.3
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31

최근에 올라온 글

최근에 달린 댓글

쉬워 보이는 스크럼

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

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

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

제 생각에는 갑작스럽게 스크럼을 바로 도입하는 것보다 애자일 개발팀이 되기 위해 하나씩 바꿔나가는 것이 좋다고 생각합니다.
애자일 개발팀으로써 살짝 자리를 잡은 뒤에 스크럼을 도입해보면 더욱 효과적일것 같습니다.
아래의 프로세스들이 팀에 살짝  정착되고 나서 스크럼을 도입한다면 더욱 효과적일것 같습니다.
  • 지속적인 피드백을 주고 받는 설계와 구현
  • 사용자 스토리를 이용한 요구사항 정리 
  • 업무 추정을 담당자에게 위임 
  • 빌드 자동화 / 일일 빌드 
Posted by 윤청하
, |
오늘 가산에 있는 LG전자 MC연구소에서 Agile Gathering이라는 제목으로 세미나가 있었습니다. 
여차저차 허락을 받고 점심도 안먹고 가산으로 넘어갔습니다. 

리더쉽은 자신이 선택하는 것

첫번째 시간은 애자일 컨설팅의 김창준 대표님이 애자일 적용(혹은 반대)를 위한 조직에서의 리더쉽에 대한 내용으로 워크샾을 진행하셨습니다. 워크샾은 시뮬레이션 형태로 진행되었습니다. 참석자들중 몇분은 관찰자의 역할을 맡고 나머지는 한 회사의 구성원(사장,이사,팀장,사원)이 되어 시장(market)의 요구사항에 맞는 시제품을 개발하는 것이었습니다. 처음에는 어색했지만 나중에는 완전히 몰입해서 정말 제품을 만들어야 한다는 중압감이 생겼습니다+_+! 
약 1시간 넘게 시뮬레이션을 진행한뒤에 피쉬보울 방법으로 회고를 진행하였습니다. 그중에서 가장 인상에 남았던 것은 김대표님이 말씀해주신 매니저와 리더의 다른점, 리더쉽의 본질, 리더쉽의 4가지 유형이었습니다.
매니저는 조직에서 정할 수 있지만 리더는 정해줄 수 없다. 리더는 지휘 여하를 막론(경영진에서 신입사원에 이르기까지)하고 누구나 될 수 있다. 단지 우리는 리더가 되는 것(혹은 리더쉽을 발휘하는 것)을 선택하는 것이다. 단지 안할뿐..
리더쉽은 모든 사람이 창의적으로 문제해결에 기여할 수 있게 환경을 개선하는 것이다. 이에는 4개지 유형이 있다.
motivation leadership, organization leadership, innovation-idea leadership, jig leadership...
애자일에 관심있다고 하는 사람들이 모여서 회사 제품 개발 시뮬레이션을 해도 잘 안되기는 마찬가지였습니다.
중요한건 자신이 현재 상황에서 리더쉽을 발휘할 것인지 아닌지를 선택하는 것입니다.
(다들 가만히 있는데 먼저 나서서 행동을 취하는 것도 리더쉽 입니다. (jig leadership))

짝프로그래밍, 잘하면 고효율~ 못하면 가문의 역적

두번째 시간은 LG CNS의 채수원 과장님이 짝프로그래밍에 대해서 발표해주셨습니다. driver-navigator 라는 패턴을 이용하여 짝프로그래밍 도입하는 것에 대해서 말씀해 주셨습니다. 물론 짝프로그래밍의 장단점, 사례도 말씀해 주셨습니다.
개인적으로 짝프로그래밍을 좋아하지만 사용가능한 분야 혹은 짝이 한정되어있다고 생각합니다. 
정말 필요한 경우에, 고효율이 예상되는 경우에만 사용하는 것이 바람직하다고 생각합니다.

스크럼 vs 칸반

세번째 시간은 LG전자의 MC연구소에 계시는 분이(이름이 기억..안..나..요;;..ㅠㅠ) 스크럼과 칸반에 대해서 아주 이해하기 쉽게 설명해 주셨습니다. 칸반은 아주 심플하게 다음의 3가지를 만족하면 됩니다.
  • Visual Card : 비쥬얼은 필수!
  • Limit Work-In-Progress : 한 스텝에서 동시에 진행될 수 있는 백로그를 제한
  • Measure Lead-time : 지속적으로 리드타임을 측정하여 최소가 될수 있도록 함
특히 칸반은 수시로 인터럽트(QA, 유지보수등)가 발생하는 개발팀에서 유용하게 사용되어 어질수 있다고 생각했습니다. 
즉, 스크럼과 칸반을 개발팀의 업무 특성에 따라 적절히 조합해서 사용한다면 좋을 것 같습니다.

회고

회고에 참석하지 못했습니다.ㅠㅠ 반성중.. 
김창준님이 진행하신 시뮬레이션에 대해서 좀더 자세한 설명이 있었으면 했습니다. (왜 손을 잡는지, 감옥의 역할은 무엇인지 등..)
색다른 경험이었고 즐거웠습니다. 근데 뭘 했다고 이렇게 졸립죠...ㅠㅠ;;
Posted by 윤청하
, |
저는 스크럼, 테스트 주도 개발, 짝프로그래밍, XP의 원칙과 가치 등을 처음 접했을 때 큰 영감을 받았던 기억이 있습니다.
이런 것을 팀에 도입한다면 한단계 발전하는 팀이 될 수 있을 거라는 확신이 들었습니다.
고민했던 생각들을 실천하고 주변사람을 선동하는데 익숙한 저는 바로 실행에 옮겼습니다.
우리는 XXX 문제들이 있기 때문에 YYY를 도입해서 해결해야 합니다.
그리고 우리는 YYY를 도입했습니다.

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

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

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

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

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

통로에 위치하게된 War Board!

우리의 War Board!

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



Posted by 윤청하
, |

전의 상실 후의 스프린트

약 2달전부터 7명의 팀원중 4명이 매우 중요하고 긴박하게 준비되는 프로젝트에 투입되었습니다. 엎친데 덮친 격으로 프로젝트 예상 일정이 크게 틀어져서 프로젝트 맴버들은 야간 작업과 주말 작업에 시달려야 했습니다. 프로젝트는 어느정도 마무리되었지만 4명의 팀원들은 사기가 바닥으로 떨어졌습니다. 물론 나머지 3명의 팀원들의 사기도 좋지 못했습니다.
그 후 팀장님께서는 여기서 고삐를 늦추면 다들 마이너스 사기로 돌아설 걱정에 스프린트를 진행하셨습니다. 물론 예상 작업량도 줄였고, 휴가도 넉넉히 할당하였습니다. 그리고 어제 그 스프린트가 종료되었고, 팀내 회고를 진행하였습니다. 이번 스프린트의 결과는 처참했습니다. 제대로 끝난 스토리가 없었죠.ㅠㅠ

비난 없는 회고 : 무엇이 잘못되었을까?
  • 스프린트 준비가 없었다
    다들 사기가 저하된 상태였던지라 스프린트 백로그에 대한 준비가 미흡했습니다. 따라서 초기 예측도 크게 빗나간 스토리가 많았습니다.
  • 얼렁뚱땅 데일리 미팅
    우리는 스프린트 백로그에 대응하는 스토리와 이를 세분하여 데일리 미팅에서 사용하는 테스크로 관리합니다. 준비가 없다보니 테스크는 미리 정의 되지 못했으며, 데일리 미팅에서 테스크를 즉석으로 마련해 내는 진 풍경이 발생했습니다. 따라서 스토리의 남은 예상 시간은 갱신되지 못했으며, 번다운 챠트도 엉망이 되었습니다. 테스크 관리가 제대로 이루어 지지 않아서 협업이 어려웠고 지연되는 스토리가 대거 등장하였습니다.
  • 스토리 및 테스크의 정의 미흡
    스토리와 테스크에는 종료 조건(데모 방법, 리뷰 방법, 테스트 방법 등)이 명시되어야 하는데 대부분 대충 제목만 적는 경우가 많았습니다. 또한 테스크의 크기는 큰 경우가 많았습니다.(1일~3일 단위) 이번 스프린트에서 리뷰도 거의 이루어 지지 않았으며, 데모를 한 스토리는 없었습니다.

다음 스프린트에서 더 잘하려면 무엇을 해야 할까?

우리는 이번 스프린트를 거울 삼아 다음 스프린트에서 어떻게 하면 더 잘할 수 있을지 논의 하였습니다. 팀원들은 각자 다음 스프린트에서 꼭 했음 하는 것과 꼭 하지 말아야 할 것등을 적어서 서로 공유하였습니다. 많은 이야기가 오갔지만 우리는 예상되는 효과가 좋을것 같고 지키기 쉬울 정도로 명확한 규칙을 몇개 선정하였습니다.
  • 스토리의 남은 예상 작업일을 매일 갱신하자
    데일리 미팅에서 스스로 남은 예상 작업일을 갱신하는 작업은 긍정적인 부담감(혹은 책임감)을 제공하는 요소중에 하나입니다. 또한 정확한 번다운 챠트를 그릴수 있게 합니다.  
  • 테스크의 크기는 4시간 단위 이하로 제한한다
    테스크의 크기가 커질 경우 테스크의 정의를 대충 할 수 있다는 경험을 하였습니다. 조금 더 명확한 가이드 라인을 제시함으로써 테스크를 명확하게 나눌수 있으며, 나누어진 테스크는 협업을 쉽게 할수 있게 합니다. 단, 스프린트 미팅에서 잘게 나누어진 테스크를 산출하기 어려우므로, 준비 상태에 있는 테스크의 크기는 제한하지 않되, 테스크를 진행하기 위해서는 위의 제한을 지켜서 테스크를 산출해야 합니다.
  • 테스크에 테스트 방법을 명시하자
    테스크의 종료조건 중 테스트 방법을 명시함으로써 미리 테스트 환경을 고려하여 테스크를 진행할 수 있게 합니다. 우리팀의 업무 특성상 타 팀과의 연동이슈가 많습니다. 따라서 테스트 환경을 미리 고려하지 않는다면 테스크가 종료되더라도 정확하게 테스트되지 않을 수 있었습니다.
  • 스프린트 사이에 2일간 종료 및 준비기간을 갖자
    그동안 스프린트 사이에 여유가 없어서 데모, 회고, 준비등을 잘 할 수 없었습니다. 스프린트 종료후 하루는 데모 및 회고를 함으로써 스프린트 종료를 명확히 하고, 다음 하루는 다음 스프린트를 위한 스프린트 백로그 공유 및 테스크 산출을 함으로써 스프린트 진행에 착오가 없도록 할 것입니다.

정리

어떤 방법을 사용하던 지속적으로 신경쓰고 개선하지 않으면, 습관화 또는 형식화 되기 쉽습니다. 우리 팀은 스크럼이라는 도화지에 우리 나름의 방법을 하나씩 그리고 있습니다.
Posted by 윤청하
, |
11월의 마지막날 xper 정기모임을 강남역 근처에 위치한 토즈에서 진행하였습니다. 거의 60명에 가까운 분들이 참여하신것 같습니다. 평일 모임이라 시간이 부족한 까닭에 바로 발표를 진행하셨습니다. xper(http://xper.org/wiki/xp/)에서는 매월 정기모임을 갖습니다. xper 메일링 리스트(http://groups.google.com/group/xper)에 가입하시면 자세한 공지를 받으실 수 있습니다.^^

조직관리와 스크럼 - 고성원

Dragonfly사의 Special Force 2 팀장님이신 고성원님께서 팀에 스크럼을 성공적으로 도입하고 정착할 수 있었던 '팀 조직 관리의 방향성'에 대해서 발표해주셨습니다. 고성원 팀장님은 외모에서부터 special force가 느껴졌었습니다+_+ 멋있으셨음~

얼마전에 공중파에서 방영한 영상으로 발표를 시작하셨습니다. 일본의 한 사과농부가 어떤 화학 비료도 쓰지않고 사과농사에 성공한 이야기였습니다. (사과는 자연농법으로 재배하기 가장 어려운 품종중에 하나랍니다.) 그 성공의 해답은 흙을 믿었던 것입니다. 10년동안 실패했지만 포기하지 않고 자연의 모습을 그대로 재연함으로써 사과 자연농법에 성공하였습니다. 덕분의 그분의 땅은 그 어느땅보다 기름진 흙을 가지게 되었습니다. 이는 스크럼의 가치에 아주 적절하게 비유될수 있다고 하셨습니다. 즉, 그 농부는 사람(흙)을 믿는 세계 최고의 스크럼 마스터인 것입니다.

고팀장님은 스크럼 도입 이전 4년동안 '팀 조직 관리'에 대해서 고민하셨다고 합니다. 아마 개발팀 팀장이라면 누구나 했을법한 고민인 것 같습니다. (전 아직 팀장이 아니라ㅋㅋ) 그러던 중에 스크럼 책을 접하게 되셨고, 큰 영감을 얻으셔서 팀내 스크럼 적용을 강력하게 드라이브하셨다고 합니다. 스크럼을 도입하는 중간에 큰 위기는 없으셨고(중간에 윗분이 보드를 떼라고 했던게 가장 위기였었다고..), 회사에서 IPO를 진행하면서 회사내에 발표할 기회가 있으셨는데, 그때 신임을 크게 얻으셨다고 합니다. 그리고 팀원들에게 얻은 생생한 증언이 다음과 같습니다. (몇개만 적어봤습니다.)
  • 업무 목표가 분명해진것 같습니다. 
  • 유기적, 조직적으로 일하는 것 같이 느껴집니다.
  • 일과가 명확해 진 것 같습니다.
  • 긍정적 부담의 효과로 책임감이 높아졌습니다.
  • 완성품의 잣대를 스스로 결정할 수 있게 되었습니다.(디자이너)
  • 일과 개인 생활의 균형을 잡을 수 있게 되었습니다.
너무 긍정적인 것만 있어서 쪼금 아쉬웠습니다.^^ 하지만 발표 마지막에 보여주신 사진들을 보면서 정말 다들 변화에 매우 적극적이었을 것 같다는 느낌을 받았습니다~ (팀장님과 팀원들 모두 부러웠습니다.ㅠㅠ)

고팀장님은 팀원들과 매우 능동적인 커뮤니케이션을 하신것처럼 보였습니다. (양방향 관리모델..) 가장 인상적이었던 것은 팀원들에 대한 보상 중에 커뮤니케이션 만족도라는 것이 중요하다는 것을 말씀하신 것입니다. 저는 이게 보상일까라고 상상도 못해봤는데, 듣고 보니 정말 "아하!" 였습니다. 커뮤니케이션 만족도가 높다는 것은 소외감을 느끼지 않는 것이며, 조직의 구성원으로써 인정받고 있다고 느끼고 있다는 것일 겁니다. 개인적으로 혼자 프로젝트를 맡아서 업무를 처리할 때 커뮤니케이션 만족도가 매우 떨어졌던것 같습니다. 만약, 팀에서 데일리 미팅까지 않한다면, 그 외로움은 정말 커질겁니다. (상상만해도 외롭다는..ㅠㅠ)

국내 SI시장에서의 애자일 개발 적용 - 민신현

두번째는 SI업계에서 10년이상 몸담아 오신 SK C&C의 민신현님(PM)께서 SI시장에서의 애자일 개발 적용 사례를 발표해주셨습니다. 발표의 시작은 현재 국내 SI시장의 열악한 환경과 이유에 대해서 매우 알기 쉽게 설명해주셨습니다. 몸으로 와닿는 표현으로 발표를 해주셔서 비록 SI업계 경험은 없었지만 그 아픔은 진심으로 느낄수 있었습니다. (사실 저희 회사도 SI/용역에서 크게 벗어나지 않습니다.ㅠㅠ) 아르미라는 개발 프로세스는 산출물만 150가지가 넘는데, 실제 산출 문서만 4.5m의 두께에 이르는 경우도 있었다고 합니다.

민신현님은 다음과 같은 문제점을 해결하고자 하셨습니다.
  • 기존의 방법론은 실제 눈에 보여지는 결과물이 나오기 까지 너무 올래걸립니다.
  • 현재 내 위치를 알수가 없습니다. (얼마나 더해야 끝나는지..)
  • 바보 개발자를 양산하고 있습니다. (요구사항에 없는건 신경도 안쓰는..)
  • 산더미 같은 문서를 생산합니다. (프로그램 개발이 아닌 문서 개발.. 감리를 위한 산출물)
  • 서로 이해되지 않는 말로 커뮤니케이션 합니다. (공동체 의식이 없는 팀..)
그리고 재미를 부여하고자 했습니다. (한국 개발자의 재미 = ownership + 칼퇴근..ㅋㅋㅋ) 
그럼 어떻게 해결하셨을까요?
  • 6개월, 1년의 스케쥴은 예측하기 어렵습니다. 짧게 예측하자! 2~3주 이터레이션~
  • 설계 중간중간에 테스트 케이스를 작성 합니다(class diagram, use case 단계) - 자동화 테스트
  • 자동화 테스트만 믿을 수 없습니다. 수동 유저 테스트
  • 기반 시스템 가동합니다 - CI 서버(Hudson) 운영(데일리 빌드, 테스트 자동화), Trac, Doxygen
  • 정말 필요한 문서를 만듭니다. 위키를 통한 프로젝트 진행 사항 공유~ 및 문서화(링크)
  • 개발자들에게 고객과 개발된 프로그램으로 대화하라고 주문합니다~ 
  • Wireframe 방식의 GUI prototype 방식에서 user experience가 가능한 prototype 방식으로 변경(프로그램 구매)했습니다
  • SI 특성상 매 프로젝트마다 인원이 바뀌기 때문에 프로젝트 초반에 교육에 치중하였습니다
  • 매번 이터레이션마다 개발자들을 쉬게 하였습니다. (빨리 끝내는 개발자는 칼퇴근! 추후에는 동료들을 도와준다는.. 하지만 나중에는ㅋㅋ - PM이 지고가야할 짐이라고 하십니다..멋있다ㅠㅠ)
  • 매일 아침 30분간의 티타임~ 우리가 남이 아니다라는 것을 알게됩니다.
  • 고객과의 합의를 통해 새로운 프로세스를 적용하였습니다. (고객 설득 -> 감리 설득)
궂이 애자일이라고 표현할 필요는 없을 것 같습니다. 엄청난 고민과 개선의 결과라고 생각됩니다. (실제로 매우 성공적인 프로젝트를 진행하셨다고 합니다. 참여한 개발자들이 고맙다고 인사하고 선물까지 주셨더라는...)

이와같은 변화를 통해 민신현님은 정량적 공정 결과, 현재 내 위치, 미래의 위치를 얻으셨다고 합니다. 어떤 방법을 사용하여 개선하든, 일의 본질은 변하지 않는다가 정답인것 같습니다.

개인 회고

까먹을까봐 바로 정리하고 있는데 요즘 2달된 지윤이 덕분에 잠을 잘 못자서 인지 횡설수설한것 같습니다. 잘못된 내용있으면 리플 달아주시면 정말 백만개 감사할 것 같습니다^^

좋았던 점
  • 두 리더분의 강력한 카리스마와 경험을 공유할 수 있어서 좋았습니다.^^ (그 팀에 속한 팀원들이 부러웠습니다~)
  • 정시 퇴근에 대한 환상이 현실로 조금씩 다가오고 있다는 느낌이 좋았습니다~
아쉬운 점
  • 시간 관계상 사람들과 나눌수 있는 시간이 부족했던게 아쉬웠습니다. 그래도 너무 즐거웠습니다!
  • 민신현님께서 질문에 대한 답변에서 가장 후회가 되는 선택이 개발자들을 칼퇴근 시키고 대신 자신이 남아서 야근했던일이었는데, PM이 짊어져야할 짐도 있지만 함께 나누어 가져야 할 짐도 있지 않을까 상각해봤습니다. (입원까지 하셨다는 말씀에 눈물이 날뻔..ㅠㅠ)
아하!
  • 역시 사람을 믿어야 한다~
  • 리더의 역할이 중요하다. (나중에 내가 팀장이 되면 어떤 팀장이 되어야 겠다는 상상의 나래를 펼쳐보았습니다^^)
  • 금전적인 보상도 좋지만 커뮤니케이션 만족도를 높여주는 보상도 중요하다!
  • 현재 자신의 위치를 안다는 것이 매우 중요하다. (이를 통해 여유 있는 스케쥴링이 가능할 것 같습니다. 칼퇴는 그 다음에 꺼내야할 문제인듯...)
  • 커뮤니케이션을 위한 집중된 공간이 필요하다. (두분 모두 위키를 통해 공유하셨습니다. 우리 팀도 위키를 썼으면 좋겠네요~ㅎㅎ)
  • 티타임으로 '우리'라는 공통분모를 찾자. (현재 저희 팀에 스크럼을 적용하여 진행중인데 다소 형식화 되간다는 느낌이 들었습니다. 우리팀에게 당장 필요할듯 합니다.)

정말 재미있고 유익한 시간이었습니다. ^-----^ 감사합니다!

Posted by 윤청하
, |

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

교차 기능 개발팀 구성

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

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

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

XP 적용하기

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

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

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

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

문화 바꾸기

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

마무리

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

읽어주셔서 감사합니다!~ 
그냥 가지 마시고 리플로 피드백을 해주신다면 정말 정말 백만개 감사할 것 같습니다.^^
Posted by 윤청하
, |
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 윤청하
, |

스크럼의 빠른 피드백

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 윤청하
, |

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 윤청하
, |