2장. 팀#3
#2-2 일기(2/2)
#2-2 일기(2/2)
* 이터레이션 별 목표 정의 및 사용자 스토리 추정
(08년 3월 21일) 파일럿 이터레이션 —릴리즈 플래닝
개발자들을 모두 모아놓고 “이터레이션 별 목표설정과 스크럼의 이해” 이란 제목의 릴리즈 플래닝 미팅을 시작했다. 첫 애자일 시도이기 때문에 모두가 프로세스를 이해하는 것이 매우 중요했다.
난 우선 프로젝트에 대한 개략적인 설명을 했다. 대략적으로 마일스톤에 대해 공유하면서, 얼마만큼 개발할 시간이 있는지 우리가 제어하지 못할 주변 요소들이 어떤 것들이 있는지 설명했다.
프로젝트 마일스톤 및 리스크 설명사용자 스토리와 스크럼 보드와의 관계를 설명한 뒤, 우선 기능 크기를 함께 추정하기로 했다. 각각 기능이 무엇인지 설명한 뒤, 자신이 해야 할 일을 카드 한 장씩에 나누어 일이 얼마나 걸릴지 적어보자고 했다. 무도가 함께 할 수는 없어서, 3~4명씩 한 조가 되어 추정했다. 한 개의 기능을 추정하려고 하니, 팀원 중에 한 명이 다음과 같은 질문을 했다.
“기준이 좀 필요한 것 같아요. '완료'라는 것이 테스트를 포함한 것인지 아니면, 제외한 것인지가 필요합니다. 그게 있어야 기능이 얼마나 걸릴지 좀 더 잘 추정할 수 있지 않을까요? 테스트 이외에도, 뭔가 단계 같은 게 필요하지 않을까요?”
"적절한 제안입니다. 우선 그것부터 정하죠. 기능의 '완료'를 위해 무엇을 해야 할까요?"
우리는 한 기능을 개발하기 위해 해야 할 일을 나열하기 시작했다. 그리고 함께 합의하여 팀이 함께 “완료”라고 정의했다.
사용자 스토리가 작성되기 시작하면서, 팀원들의 추가적인 의견 개진이 시작되었다.
“기능 개발만 일이 아니잖아요? 나머지 시간은 아무것도 안 했다는 게 될 수도 있는데, 회의나 교육 등등도 태스크로 적어 보여줘야 하는 것이 아닐까요? 이를 드러내는 것도 중요할 것 같아요.”
"아.. 그것도 중요하겠네요"
팀원들은 이 의견에 함께 공감했다. 기능을 적던 내용에 회의 또는 교육 등의 준비과정까지 함께 적었다. 그렇게 적어 현황판에 붙이고 나니, 정작 기능 개발이 무엇인지 구별이 가지 않았다.
“이 현황판을 고객이 볼 것이라면, 기능이 뭔지 구별을 좀 해야 할 것 같아요…”
또 다른 팀원이 제안했다. 우리는 이 내용도 받아들여, 기능 개발 태스크는 노란색 종이를 쓰고, 다른 태스크는 파란색 종이를 쓰기로 했다.
정작 붙여놓고 보니, 자연스레 그룹별로 대략적인 업무량이 도출되었다. 팀 공통은 35 포인트의 업무를 할당하였고, 팀 드라이버는 개발환경 구축으로 0.5포인트만 두었다.
상대방으로 한 그룹의 스토리 포인트가 너무 적다 보니 해당 그룹의 담당자들이 우리에게 자신들의 스토리 포인트가 적은 이유를 설명할 수밖에 없었다.
"현재 해야 할 일이 명확하지 않고, 고객과 인터뷰를 해야 더 확실하게 추정할 수 있으니 일단 이 정도로 진행하자."
팀 전체는 그 이야기를 듣고 모두들 고개를 끄덕였다. 실제로 고객 말에 업무량이 고무줄처럼 늘어날 수 있는 상황이었다.
팀 A, B, C는 각각 37.5, 32.5, 32.5에 해당하는 스토리 포인트를 추청 했다. 팀 D를 제외하고 스스로 산정한 량에 대해 차이가 있는 팀이 있었지만 어차피 이터레이션 동안 정해진 일을 모두 다 끝내는 것이 목표기 때문에, 시간이 남는 경우 다른 팀을 돕겠다는 다짐을 서로 하면서 회의를 마쳤다. 현재 정해지지 않은 것이 많아 일단 한 개의 2주간 파일럿 이터레이션에 대한 계획만 짜기로 하고 2주간의 이터레이션을 시작했다.
[스크럼 보드에 기능을 도출하는 팀원들]미팅 후 우리는 팀 내에 흐르는 즐거운 분위기를 느낄 수 있었다. 산더미 같은 분석, 개발 산출물을 대할 때의 굳은 표정들과 도서관 같은 분위기는 사라지고 팀당 서로 적극적으로 커뮤니케이션하며 개발 내용과 환경에 대해 이야기했다.
배운 점 : 퍼실리테이션을 잘하기 위해서는 사전 인터뷰가 필수이다. 마찬가지로 릴리즈 플래닝 전에, 소그룹 별 사전 인터뷰를 수행하면 더 원활한 진행이 가능하다. 소그룹 중 일부는 당장 릴리즈 플래닝을 전체 팀과 함께 할 수 없는 상황 일 수도 있다.
* 스탠드업 수행
(08년 3월 24일) 파일럿 이터레이션 — 1일 차
고객과의 첫 미팅을 가졌다. 프로젝트 관리자는 고객이 개발팀 사무실에 자주 와야 프로젝트가 성공한다고 했다. 그는 좋은 책상과 의자를 준비하여 고객의 명패를 붙여두었다. 이 덕분인지, 실제로 프로젝트에 대해 의사 결정권이 있는 고객이 자신의 사무실 대신 하루에 반나절 이상 우리 프로젝트에 상주했고 난 회의 서두, 말미 혹은 시간이 날 때마다 우리 프로젝트가 고객이 가까이서 도와주는 가장 이상적인 프로젝트의 형태라는 말을 자주 했다. 왜냐하면 팀원들이 고객들에게 직접 질문하고 이슈에 대해 빨리 의사결정을 하는 것으로 추후의 문제점을 조기에 막을 수 있기 때문이다.
고객과의 첫 회의에서 나는 “우리가 스크럼을 한다”라는 이야기는 하지 않았다. 대신에, 우리는 이전과 다른 방식으로 진척 관리를 할 것이고 이터레이션을 통한 관리 방법이 현 상황에 보다 효과적일 것이라고 설득했다. 고객은 빠른 시기에 결과물을 확인할 수 있다는 생각에 호의적인 반응을 보였다.
(08년 3월 25일) 파일럿 이터레이션 — 2일 차
“스탠드 업”이라는 이름 대신 “커피 타임”이란 보다 친숙한 이름의 회의로 아침 9:30 분 미팅을 시작했다. (이 시간도 함께 의논하며 결정했다) “어제 한 일”, “오늘 할 일”, “ 문제점” 순으로 모두가 한 명씩 순서를 돌아가며 이야기했다. 다만, 문제가 하나 발견되었는데 현재 단체 업무 교육 및 개발환경 세팅 교육이 있었기 때문에 “어제 한 일”은 이미 모두가 공유한 내용이었다. 때문에 이를 스킵하고 새로 온 소프트웨어 아키텍트를 소개하고 간단하게 오늘 진행할 프로젝트 업무를 이야기하고 회의를 마쳤다.
배운 점 : 스탠드 업 미팅이 15분 정도이지만, 이 시간 자체도 참여자 모두에게 의미 있는 시간을 만드는 것이 중요하다. 모두 동일한 일(전체 교육)을 수행하고 있다면, 과감하게 스탠드 업 미팅을 하지 않을 수도 있다.
(08년 3월 28일) 파일럿 이터레이션 — 5일 차
커피 타임 회의를 가졌다. 이 미팅을 통해 얻을 수 있는 것이 많았지만 가장 좋았던 점은 시간이 짧기 때문에 회의 내용을 주제 중심의 논의로 이끈다는 것이다. 이 미팅은 이상하게 앉아서 할 때보다 서서할 때 10분 정도 시간이 단축되는 사실을 관찰할 수 있었다. 허리가 아팠던 개발자를 제외하고 몇몇 개발자들에게는 이 이유를 들어 계속 서서 하자고 이야기했다.
과거 5명이 스탠드업을 하는 경우, 10분 정도의 시간이 적당했다. 이 비율로 볼 때 현재 우리 프로젝트 팀원은 12명이므로 20분 정도로 제한시간을 정했다. 그리고 팀이 함께 다음과 같은 그라운드 룰을 정했다.
“말할 때 주제 밖으로 벗어나지 않기”
“다른 사람이 이야기할 때 끼어들지 않기"
스탠드업 미팅을 통해 흥미로운 사실 하나를 알게 되었다. 가장 커뮤니케이션을 가장 자주 한다고 믿었던 관리자급 3명(중간관리자, 아키텍트, 유지보수 담당자)이 중요한 주제에 대해 서로 다르게 이해한 부분을 찾게 된 것이다. 로컬 개발 환경 구축에 대한 이야기였는데, 유지보수 담당자는 방화벽 문제로 로컬 개발 환경이 잘 되지 않으니, FTP로 직접 개발서버에 반영하는 것을 가르치고 있었다. 아키텍트는 방화벽 문제를 모르고 있었고 중간관리자는 업무를 가르치던 유지보수 담당자와 이미 모든 문제가 해결되어 있다고 생각했다. 사실 서로 '이슈'를 터놓고 얘기할 공간이 없었던 것이다.
배운 점 : 문제를 감지하면, 조금이라도 빨리 실제 담당자들과 이야기하여, 상황을 종료시키는 지혜가 필요하다.
(08년 4월 2일) 파일럿 이터레이션 — 8일 차
커피타임 미팅 후 한 팀이 커뮤니케이션에 문제가 있는 것을 알아챘다. 팀 B의 두 멤버가 서로 대화하지도 않고 내내 모르는 사람인양 토라져 있었다. 이 들 둘은 스크럼 보드를 함께 업데이트하는 것조차 꺼리고 있었다. 무엇을 해야 할까, 고민하기 시작했다.
(08년 4월 3일) 파일럿 이터레이션 — 9일 차
프로젝트 관리자는 짝이라는 개념에 대한 효용에 의문을 품기 시작했다. 왜냐하면 사이가 나쁜 짝의 경우 서로 전혀 협업이 되지 않고 처음에 둘이 일을 잘못 나눈 경우 한 명이 고생을 해도 옆 사람이 전혀 도와주지 않았기 때문이다.
팀 B는 각각 8년 차, 6년 차 남-녀 개발자로 구성되었는데 이들 둘은 짝 프로그래밍을 하기는커녕 처음부터 받은 기능 목록을 둘로 나누고 나눈 기능을 각자 개발하기로 결정했다. 게다가 중간에 전혀 대화를 하지 않고 있었다. 이런 상황에 남성 개발자가 곧 개인적인 사정이 생겨, 자주 휴가를 내야 하는 상황이 발생하면서 더욱 심각해졌다.
여성 개발자는 자주 휴가를 내는 남성 개발자에 대해 불만을 갖기 시작했다. 남성 개발자가 버거운 일을 맡고 있을 때에도 조금도 남성 개발자를 도와주려 하지 않았다. (나중에 알게 된 사실이지만, 여성 개발자의 일은 업무 범위 조정에 따라 이미 없어진 뒤였다. 하지만, 커피타임에 여성 개발자는 자신의 상황에 대해 전혀 말하지 않았다.)
배운 점 : 짝 프로그래밍은 “코드 공동 소유”라는 기법과 함께 진행해야 하고, 개인적 성향에 따라, 거부반응을 보일 수도 있다. 또한 짝 프로그래밍은 상황에 따라서는 그다지 좋은 방식이 아닐 수 있는다. 예를 들어 두 명의 개발자의 역량이 부족할 때 두 사람이 해야 할 일이 매우 어려운 경우나, 두 명의 개발자의 역량이 매우 좋은데, 두 사람이 해야 할 일이 매우 쉬운 경우의 두 가지 모두 팀 입장에서 보면 큰 낭비가 일어나는 일일 수 있다.
* 쇼케이스 수행
(08년 4월 4일) 파일럿 이터레이션 — 10일 차
파일럿 이터레이션 마지막 날이었다. 오전부터 개발팀은 매우 분주했다. 구현한 기능을 대한 시연을 하기로 한 날이다. 어제 밤늦게까지 작업한 개발자들도 있었다. 오전 10시부터 점심시간까지를 시연 시간을 정했다.
프로젝트 관리자를 불러 회의실에 앉히고 한 팀씩 시연을 시작했다. 고객에게도 이야기를 했지만, 고객은 중요한 일이 생겼다며, 회의에 참여하지 못했다. 팀은 기운이 빠졌다. 고객에게 시연을 해야, 2주간 고생한 작업에 대한 검증이 완료된다고 팀은 알고 있었다.
하지만, 고객이 오지 못한 상황이 천만다행이었다. 시연이 시작되지 마자 문제가 생겼다. 첫 시연하는 팀이 구현한 제품의 수준은 누가 보아도 형편없었다. 프로젝트 관리자을 포함한 모두가 얼굴이 찌푸려졌다. 결국 프로젝트 관리자가 의자를 박차고 “이게 내가 당신들을 신뢰한 결과냐?”라고 화를 내고 회의실 밖으로 나갔다.
잠깐의 패닉 상태에 빠졌다가, 팀원들은 '우리끼리라도 해보자'라고 하며 다른 네 팀의 시연을 진행했다. 다른 네 팀의 시연은 결과가 나쁘지 않았다. 서로 게 준 피드백으로 화면 표준에 엇나간 것과 개선 사항에 대한 수정 목록을 스크럼 보드에 추가했다.
[업데이트된 스크럼 보드]이후 우리는 자연스럽게 프로젝트 관리자의 반응에 대해 무엇을 할 수 있을 지에 대해 고민했다. “오늘 같은 일이 다시 발생하지 않기 위해, 어떻게 하면, 시연 전에 전체 기능의 수준을 어떻게 올릴 수 있을까?”
팀은 회의를 통해 “팀이 개발한 내용에 대해 스스로 테스트를 먼저 수행하고, 이 테스트가 끝나면 다른 팀에 의한 재 검증 테스트를 하자”라는 결론을 냈다. 보다 구체적으로 이터레이션 2주 차 시연 전날에 오전에는 함께 테스트를, 오후에는 오전에 발견한 결함에 대한 수정을 하기로 팀이 결정했다.
미팅이 끝난 직후 난 프로젝트 관리자을 만나러 갔다. 긴 시간의 이야기를 통해 프로젝트 관리자에게 다른 네 팀은 시연의 결과가 나쁘지 않았으며, 기능에 대해 내가 먼저 점검하지 않고 프로젝트 관리자에게 시연에 참여하라고 한 것은 잘못된 선택이었다고 말했다. 이 것을 통해 우리는 어떻게 프로세스를 개선할 것이라는 이야기도 했다. 프로젝트 관리 자은 다음 이터레이션에는 보다 나은 기능 구현을 기대한다고 말하고 이터레이션을 마쳤다.
------------------------
지금까지 여러분은 애자일을 최초로 시작한 어떤 팀이 2주간의 이터레이션 동안 어떤 일들을 겪었는지 볼 수 있었다. 최초에는 많은 팀이 그렇듯 문제와 갈등이 있었다. 다만, 돌아보면 한 가지씩 서로 배워나가며 현재 상황에서 개선하기 위해 끊임없이 협업할 수 있는 멋진 팀이었던 것 같다.
결론적으로 말하면 이 프로젝트는 크게 성공했다. 제 때에 프로젝트가 잘 수행되었고 고객은 만족해했다. 내 첫 번째 팀으로 수행한 애자일 프로젝트는 이렇게 마무리되었다.
지금 와서 생각하면, 사실 프로젝트의 가장 큰 성공 요인은 프로젝트 관리자의 능력이었다. 그는 강력한 고객의 신뢰를 받고 있었고, 협상에도 능하여 프로젝트에 필요한 충분한 예산을 최초부터 확보해두었다. 그리고, 좋은 사람을 뽑는 능력 또한 가지고 있었다. 괜찮은 개발자들이 그가 만든 훌륭한 놀이터에서 뛰어놀 수 있었고, 나 또한 그랬다.
또 다른 성공요인은 스크럼이었는데, 스크럼은 팀원의 협업을 보다 견고하게 묶어주는 역할, 고객과의 신뢰를 보다 두텁게 만드는 역할을 했다. 함께 한 액티비티들 덕분에, 우리의 전담 고객은 개발자 한 명, 한 명에 대해 실제로 관심을 갖고 대화할 수 있는 상대가 되어주었고, 그들과 하는 회고와 같은 이벤트에 자주 참석했다. (개발자들의 회의에 고객이 계속해서 참여하는 일은 당시에는 상상조차 못 하던 것이었다.) 신뢰가 쌓이니, 이전에 수행했던 많은 프로젝트들과 다른 것들이 관찰되었다. 고객은 외부로부터 팀을 보호해주려고 애썼고, 팀의 이야기를 경청했다.
프로젝트 종료 후, 성과를 인정받아 심지어 고객과 프로젝트 관리자가 동시에 승진하는 일까지 겹쳤다. 이후 프로젝트 성공 사례로 애자일이라는 이야기가 사내에 퍼져나가기 시작했다.
