[Phase#1] 애자일 일기-스스로 실천하기

필자는 국내 S사에서 애자일 전도사(Agile Evangelist)로서 다양한 도메인의 크고 작은 프로젝트의 애자일 코칭을 담당해 왔다. 국내 S사의 애자일은 2000년대 후반부터 몇 개의 프로젝트에서 자생적으로 성장했다. 이후 다양한 사업부에서 상향식(Bottom-Up) 확산이 일어났고 2010년에 CEO가 선포하는 엔터프라이즈 애자일 전환이 진행됐다. 과거 사내에 적용했던 방법론들의 적용 방법과 달랐던 점은, 현장 중심으로 확산을 진행했다는 것이다. 전사 애자일 전도사가, 조직 별 애자일 코치를 양성하고, 이들이 중심이 되어 자신들의 방식에 맞는 애자일 기법들을 선택해 나갔다. 현재는, “우리는 애자일 방식을 쓰고 있다” 라고 굳이 밝히지 않더라도 많은 조직들이 애자일 기법을 쓰게 되었다.

애자일이란 말이 등장한 지 이제 거의 17년이 되어가지만, 여전히 지금 현재의 여러분이 처한 상황에서 무엇인가를 애자일이라는 이름으로 해결해보고자 하는 분들이 있으리라 생각한다. 이런 분들, 또는 현재 본인의 시도들이 어떤 방향인지 궁금해 하는 분들을 위해 08년 필자가 최초로 애자일을 적용하며 적었던 일기 부터 하나씩 공유하려 한다. 시작하기 전, 이 글이 일기이기에, 일부 매우 주관적인 내용이 있을 수도 있다는 것을 먼저 밝혀두고 싶다.

애자일을 적용하려는 많은 사람들에게, 애자일은 “팀이 지속적으로 자신들의 일하는 방법을 개선하려고 하는 한” 어떤 방식으로도 활용될 수 있다는 것을 말해주고 싶다. 어느 조직이든 그 조직에 맞는 애자일 방식을 찾아가기 마련이다. 다른 사람의 방식이 더 나아 보인다면, 그 방식을 모델로 자신의 조직을 변화시키기 위해 변화시키고 실천하면 된다. 애자일 방식에 옳고 그름이란 존재하지 않는다.

이 일기를 보면서, 궁금증이 많이 일어날 수도 있다. 논리적으로 부족한 내용이 있을 수도 있다. 하지만, 여기에서의 필자가 독자 여러분들과 함께 공유 하고싶은 가치는 “시도 + 개선”이라는 반복을 통해 고민하고 더 나아지려는 과정이다.

여기에서 말할 사례의 프로젝트는 과거 수행했던 대규모 차세대 SI 프로젝트 후의 유지보수 및 기능 개선을 수행하는 성격이었다. 이들은 8개월간 업무 기능을 만들어 추가하는 목표를 가지고 있었다. 개발자들 대부분이 파트너사 인력이었으며, 고객은 중간 과정은 관심이 없고 보통 결과만 확인하려는 성향이었다.

이 프로젝트 수행 당시 프로젝트 주변에 애자일을 한다고 특별히 알리지 않았다. 당시 사내에는 애자일을 기반으로 한 방법론이 없었고, 제안 당시에도 고객에게 폭포수 방식을 따른다고 이야기 했었다. 더군다나, 사내 품질기준에 부합하는 산출물은 결국 시기별로 만들 수 밖에 없었는데, 이를 충족하는 한 겉으로 보기에는 이전 폭포수 방식과의 차이가 없었다.

애자일 일기 — 스스로 실천하기

(08년 3월 14일) 사전준비 — 애자일 시작하기

프로젝트 전체 인원인 13명의 개발자와 관리자를 모아놓고 첫 미팅을 가졌다. 난 두 개의 팀 중 한 팀의 프로젝트 리더였다. 난 PM과의 약속을 기반으로 “우리 프로젝트는 애자일 방식으로 진행할 것이다”라고 말했다. 입사 이후 프로젝트 착수 이전에, 애자일 방식으로 프로젝트를 수행하겠다고 말한 것은 나도 이번이 처음이었다.

과거에 내가 적용한 애자일 방식은 전체적인 것이 아니라 부분적인 것이었다. 물론 혼자서 할 수 있는 리팩토링이나 테스트 주도 개발은 그 동안 여러 차례 시도했었다. 하지만, 팀과 함께 한 것은 몇 가지 XP나 스크럼의 기법들을 적용하여 팀의 일부 인원들 특히, 회사 정규직 후배들을 향해 실험을 한 정도가 전부였다.

우선 개발자들에게 내가 이해하고 있는 애자일 방식에 대해 5분여 동안 설명했다. X 축은 시간, Y축은 가치인 그래프를 그려 우리가 진행할 방식은 계획 중심이 아니라 가치 중심이라고 이야기하고 공감을 구했다. 물론 사전에 PM에게 먼저 설명하여 관리자에게 사전 동의를 구했다.

그리고 진척관리는 “짝”의 역할을 기반으로 하기로 했다. 두 명이 한 그룹씩 짝을 짓고, 두 명이 할 만큼의 양을 스스로 가져가고, 책임도 두 사람의 공동 책임으로 하자고 제안했다. 팀원들은 특별한 반응 없이 이 내용을 받아들였다. 또한 “짝 프로그래밍”에 대해 언급하고 방식에 대해 설명했다. 혹시 짝 프로그래밍을 원하는 팀원이 있으면, 하면 더 좋다 라고만 이야기 했다.

관리자들에게는 팀원들을 믿고 진척을 투명하게 표시할 수 있는 대쉬보드 이외에는 신경쓰지 말아야 한다고 강조했다. 처음부터 욕심을 내지 않고, XP나 스크럼의 기법 중 팀에 바로 적용할 수 있다는 것부터 먼저 시작했다. 전체적인 애자일 설명을 처음에 한 것 말고는 대부분 실제 해보면서 진행했으며, 수행하려는 프랙티스는 “스탠드 업 미팅”, “사용자 스토리”, “회고”, “2주단위 이터레이션”, “지속적인 통합”, “애자일 현황판”, “짝 프로그래밍” 정도이다. “테스트 주도 개발” 같은 어려운 프랙티스는 처음부터 고려하지 않기로 했다.

우선 13명의 인원 중 설계개발을 수행할 11명을 5그룹으로 나누었다. 그리고 처음 2주간 작업할 내용을 함께 논의하여 결정했다.

• 팀 공통 (2명) : 공통기능을 전담으로 개발할 팀이다.
• 팀 Driver (3명) : 프로토타이핑을 2주간 진행하여 기술검증을 수행하고, 2주간 개발하기 위한 소스코드 템플릿을 받아, 다른 개발자들에게 제공하고 트라블슈팅을 돕는다.
• 팀 B, C, D(각 2명, 총 6명) : 각 업무의 프로세스를 그리고, 기존 기술 구조에 화면 한 개씩을 만들어 보는 작업을 수행한다.

또한 회의를 통해 팀원 모두가 지킬 그라운드 룰을 정하자고 제안 했는데, 그 동안 프로젝트를 하면서 가장 큰 문제라고 생각했던 것이 집중할 시간을 뺐는 계획에 없던 회의였다고 팀원들은 이구동성으로 이야기 했다. 우선 “회의시간 및 의제는 반드시 사전에 공지한다” 이라고 화이트 보트에 적으니, 개발자 한 명이 손을 들어 다음과 같이 이야기 했다. “그 사전 이라는 게 얼마 정도의 시간인지 정해야 할 것 같아요.” 잠시의 토론 끝에 “회의시간 및 의제는 반드시 1시간전에는 공지 해야 한다” 로 수정했다.

또한 전체 팀원이 모여 있을 때, 이터레이션 길이를 정했다. 관리자는 1주일 단위의 이터레이션을 원했고, 개발자들은 스크럼이 그렇듯이 적어도 4주는 되어야 한다고 이야기 했다. 관리자는 전체 프로젝트가 8개월인데, 분석 단계와 통합테스트 단계를 제외하면, 6개월 밖에 안 되는데, 4주에 한 번씩 확인을 할 경우 문제점을 알아 챌 수 있는 시점이 너무 늦는다고 이야기 했고, 개발자들은 1주일 단위의 이터레이션을 할 경우 1주일에 실제 개발할 수 있는 시간이 3일이 채 안될 수도 있다고 맞섰다. 이 줄다리기는 결국 “2주”로 결론이 났다. 회의 시간을 60분으로 정한 타임박스의 도움이 컸다.

다음에는 함께 사용자 스토리를 적어 애자일 현황판에 적어 놓을 생각이다. 첫 미팅은 많은 공감을 일으켰다. 하나 즐거웠던 점은 이번 프로젝트에서 나는 관리자가 아닌 퍼실리테이터 였다. 이 생각이 혼자서 한 것이 아니기를 기대한다.

(08년 3월 17일) 사전준비 — 애자일 현황판 #1

오늘 애자일 현황판을 만들기 위한 판넬 3개와 LABEL 지를 사왔다. 포스트잇도 잔뜩 사왔다. 애자일 현황판을 사용하는 이유는,

전체 프로젝트 진척사항을 확인 할 수 있다.

초점요소(Focus Factor)를 계산 가능하게 하여 실제 일에 소요한 시간을 알 수 있고 다음 이터레이션을 위한 팀 속도를 구할 수 있다. (초점요소 = 이터레이션에서 완료한 사용자 스토리 총 수 / 사용가능한 맨데이)

부가 요구사항이 있을 때 증거에 기반한 일정 변경이 가능하다.

좋았다! — 애자일 현황판을 사왔다.

어쩌지? — 오늘 우리를 담당하는 고객과 첫 대면했는데, 특별한 이유 없이 우리 팀에 대해 부정적인 인식을 가지고 있다는 것을 알게 되었다. 또안 방법론을 테일러링 하려고 들어온 품질 조직의 인력은 내가 애자일 방식으로 프로젝트를 한다고 하니 “누군가 시도하지 않는 것을 하는 너의 열정이 다른 사람에겐 독이 될 수 있다는 것을 알아야 한다” 라고 말했다.

내가 원하는 것은 개발할 때 좀 더 즐겁게 일하는 것이다. 그게 뭐가 그리 문제란 말인가?

(08년 3월 18일) 사전준비 — 애자일 현황판 #2

애자일 현황판을 만들었다. 다음과 같이 보드의 섹션을 나누었다.

[준비중] — [진행중] — [완료] — [진척도] — [예상외 작업] — [다음으로]

“준비중”에는 이번 이터레이션에서 구현하기로 한 작업 대상을 붙이기로 했고, “진행중”에는 현재 우리 팀원 중 누군가가 작업하고 있는 일, 완료는 개발 및 단위테스트가 완료된 것을 붙여놓기로 했다. “진척도”는 소멸 차트로 남은 일의 양을 표시하고, “예상외 작업”은 갑자기 밀려들어오는 작업을 붙이고 이터레이션 안에서는 못 들어오게 하기 위해 만들었다. “다음으로” 에는 고객이 중간에 우선순위를 바꾸어 이터레이션 내에서 개발이 필요 없게 되는 내용을 붙이려고 했다. (실제로 프로젝트 시작 전, 특정 업무 영역이 상위기관의 의사결정에 따라 개발대상에서 전체가 사라질 수도 있는 상황이었다.)

현황판을 붙일 때 사용자 스토리를 어떻게 작성할 지 그리고, 어떻게 추정할 지에 대해 고민했다. 대부분의 파트너사 개발자는 현재 업무의 수행 경험이 없었던지라, 얼마나 양이 될지 의견을 내기 조차 버거워했다.

우리는 기존 유지보수팀과 협업이 가능한 상황이었기 때문에 그들에게 공수 측정에 대한 도움을 청했다. 그 쪽에서 온 대답은 “해당 업무에 경험 있는 개발자들에게 공수를 측정하게 하겠다.” 라는 것이었다. 도움을 받아 다행이라는 생각에 필자는 팀원들에게 이 이야기를 전달했다. 하지만, 팀원들은 내 기대와 달리 부정적으로 반응했다. 팀원들은 우리가 작업할 것인데, 그 쪽(유지보수팀)이 산정해온 공수를 그대로 받아들이는 것은 무리한 일이라고 이야기 했다. 대신에 팀은, 실제 개발에 대한 공수를 측정할 수 있도록 2주간 파일럿 이터레이션을 수행하기 원했고 이와 더불어 우리가 해야 하는 일들의 공수를 스스로 측정하고 싶다고 이야기 했다.

우리 프로젝트는 추가적인 아키텍처의 검증이 필요 없었다. 유지보수의 개발환경을 일부 활용하면 당장 설계/개발에 들어갈 수도 있는 상황이었다. 하지만, 유지보수팀은 자신들이 커밋하는 저장소를 공유하는 것을 원하지 않았다. 자신들이 수정/배포하는 소스코드와 우리 개발팀이 수정하는 코드가 겹칠 수 있다는 것을 문제제기 하며, 개발환경을 별개로 할 것을 요구했다. 실제로도 사고라도 나면 개발팀뿐만이 아니라 유지보수팀에게도 큰 문제가 될 상황이 발생할 수 있었다. 일단 우리는 추후 소스코드 병합(Merge)의 고통을 줄이기 위한 방안을 마련해 줄 것을 소프트웨어 아키텍트에게 의뢰했다. 아키텍트는 유지보수와의 협업 후에 유지보수의 공통 부분을 jar 파일로 제공하고, 우리가 참조할 수 있는 안을 가져왔다.

물론 겹치는 부분도 일부분 있었으나, 그 패키지는 명명규칙 자체를 달리하여 일단 형상에 반영하고, 추후 병합해야 할 시기에 형상 서버를 확인하며, 유지보수팀과 함께 검증하기로 했다. 이렇게 가능하게 하기 위한 환경에 대해서는 차근차근 아키텍트가 준비하기로 했으나, 우리는 당장 개발할 수 있는 환경을 필요로 했다. 아키텍트의 작업이 끝나기만 기다릴 수 없었다. 유지보수팀은 협의 끝에 일부 및 패키지 구조에 대해 우리가 개발 환경에 디플로이 하는 것을 허락했고 소프트웨어 아키텍트가 개발환경을 만드는 동안, 그 패키지 영역을 이용하여 이터레이션 개발을 위한 파일럿 이터레이션을 수행하게 되었다. (많은 회사들이 이 “파일럿 이터레이션”을 이터레이션 0 라고 부른다)

(08년 3월 21일) 파일럿 이터레이션 — 릴리즈 플래닝

개발자들을 모두 모아놓고 “이터레이션 목표와 기능 구현” 이란 제목의 첫 번째 릴리즈플래닝 미팅을 시작했다. 첫 애자일 시도이기 때문에 모두가 프로세스를 이해하는 것이 매우 중요했다. 우선 팀은 추정을 시작했다.

먼저 난 애자일 현황판에 대해 설명했다. 각각 항목이 무엇인지 설명하고 나서 별로 자신이 해야 할 일을 카드 한 장씩에 나누어 일이 얼마나 걸릴 지 적어보자고 했다. 자연스럽게 다음과 같은 질문이 나왔다 “어디서부터 어디까지 일하는 것을 말하는 건가요? 그게 있어야 얼마나 걸릴 지 알 수 있지 않을까요?” 우리는 한 기능을 개발하기 위해 해야 할 일을 나열하기 시작했다. 그리고 그 일을 다 마친 것을 팀이 함께 “완료” 라고 정의했다.

팀원들의 추가적인 의견 개진이 시작되었다. “기능 개발만 일이 아니잖아요? 나머지 시간은 아무것도 안 했다는게 될 수도 있는데, 회의나 교육 등등도 태스크로 적어 보여줘야 하는 것이 아닐까요?” 팀원들은 이 의견에 함께 공감했다. 이 말을 받아들여 그 개발 이외의 내용까지 함께 적었다. 그렇게 적어 현황판에 붙이고 나니, 정작 기능 개발이 무엇인지 구별이 가지 않았다. “이 현황판을 고객이 볼 것이라면, 기능이 뭔지 구별을 좀 해야 할 것 같아요…” 또 다른 팀원이 제안했다. 우리는 이 내용도 받아들여, 기능 개발 태스크는 노란색 종이를 쓰고, 다른 태스크는 파란색 종이를 쓰기로 했다.

정작 붙여놓고 보니, 자연스레 그룹별 추정 포인트의 합이 나왔다. 팀 공통은 35 포인트의 업무를 할당하였고, 팀 Drivers는 개발환경구축으로 0.5포인트만 두었다. 포인트가 낮은 것에 대해 아무도 묻지 않았으나 팀 Driver는 우리에게 자신들의 스토리 포인트가 적은 이유를 설명하는 분위기가 만들어졌는데, 재 프로토타이핑의 대상, 업무량이 모두 고객과의 대화 후 알 수 있기 때문이라고 했다. 팀 A,B,C 는 각각 37.5, 32.5, 32.5 에 해당하는 스토리 포인트를 가져갔다. 팀 Driver 를 제외하고 스스로 산정한 량에 대해 차이가 있는 팀이 있었지만 어차피 이터레이션 동안 정해진 일을 모두다 끝내는 것이 목표기 때문에, 시간이 남는 경우 다른 팀을 돕겠다는 다짐을 서로 하면서 회의를 마쳤다. 현재 정해지지 않은 것이 많아 일단 한 개의 2주간 파일럿 이터레이션에 대한 계획만 짜기로 하고 2주간의 이터레이션을 시작했다.

미팅 후 우리는 팀 내에 흐르는 즐거운 분위기를 느낄 수 있었다. 산더미 같은 분석, 개발 산출물을 대할때의 굳은 표정들과 도서관 같은 분위기는 사라지고 팀당 서로 적극적으로 커뮤니케이션하며 개발 내용과 환경에 대해 이야기했다.

배운점 : 퍼실리테이션을 잘하기 위해서는 사전 인터뷰가 필수이다. 마찬가지로 릴리즈 플래닝 전에, 소그룹 별 사전 인터뷰를 수행하면 더 원활한 진행이 가능하다. 소그룹 중 일부는 당장 릴리즈 플래닝을 전체 팀과 함께 할 수 없는 상황 일 수도 있다.

(08년 3월 24일) 파일럿 이터레이션 — 1일차

고객과의 첫 미팅을 가졌다.

고객에게 호의를 베풀기 위해 좋은 책상과 의자를 준비하여 고객이 상주 하도록 한 PM의 생각은 나에겐 굉장히 반가운 소식이었다. 실제로 프로젝트에 대해 의사 결정권이 있는 고객이 자신의 사무실 대신 하루에 반나절 이상 우리프로젝트에 상주했고 난 회의 서두, 말미 혹은 시간이 날 때마다 우리 프로젝트가 고객이 가까이서 도와주는 가장 이상적인 프로젝트의 형태라는 말을 자주 했다. 왜냐하면 팀원들이 고객들에게 직접 질문하고 이슈에 대해 빨리 의사결정을 하는 것으로 추후의 문제점을 조기에 막을 수 있기 때문이다. 고객과의 의사결정 및 커뮤니케이션이 훨씬 빠를 수 밖에 없기 때문이다.

고객과의 첫 회의에서 나는 “우리가 애자일을 한다”라는 이야기는 하지 않았다. 우리는 이런 방식으로 진척관리를 할 것이고 먼저 개발자들을 교육 시켜야 하기 때문에 이렇게 먼저 개발하는 방식을 취하겠다는 이야기를 했다.

고객은 빠른 시기에 결과물을 확인 할 수 있다는 생각에 호의적인 반응을 보였다.

(08년 3월 25일) 파일럿 이터레이션 — 2일차

“스탠드 업” 이라는 이름 대신 “커피타임”이란 보다 친숙한 이름의 회의로 아침 9:30 분 미팅을 시작했다. (이 시간도 함께 의논하며 결정했다)

“어제 한 일”, “오늘 할 일”, “ 문제점” 순으로 모두가 한 명씩 순서를 돌아가며 이야기 했다. 다만, 문제가 하나 발견되었는데 현재 단체 업무 교육 및 개발환경 세팅 교육이 있었기 때문에 “어제 한 일”은 이미 모두가 공유한 내용이었다. 때문에 이를 스킵하고 새로온 SA를 소개하고 간단하게 오늘 진행할 프로젝트 업무를 이야기하고 회의를 마쳤다.

배운점 : 스탠드 업 미팅이 15분 정도이지만, 이 시간 자체도 참여자 모두에게 의미 있는 시간을 만드는 것이 중요하다. 모두 동일한 일(전체 교육)을 수행하고 있다면, 과감하게 스탠드 업 미팅을 하지 않을 수도 있다.

(08년 3월 28일) 파일럿 이터레이션 — 5일차

커피타임 회의를 가졌다.

이 미팅을 통해 얻을 수 있는 것이 많았지만 가장 좋았던 점은 시간이 짧기 때문에 회의 내용을 주제 중심의 논의로 이끈다는 것이다. 지난번 프로젝트와 비교하니 이 미팅을 앉아서 할 때보다 비슷한 내용의 회의가 10분정도 단축 되는 사실을 관찰 할 수 있었다. 몇몇 개발자들에게는 이 이유를 들어 계속 서서 하자고 이야기 했다.

이 미팅의 시간으로 5명이 하는 경우 10분 정도의 시간이 적당했다. 이 비율을 이용하여 현재 우리프로젝트 팀원은 12명이므로 20분 정도의 시간을 정했다. 퍼실리테이터(나)의 강력한 의지로 회의가 “주제 밖으로 벗어나지 않게” + “누군가 이야기 할 때 끼어들지 않게” 방식으로 진행했다. 무엇보다 “거부반응 없는 즐거운 미팅” + “무슨 이야기든 꺼낼 수 있는 편한 분위기”가 중요했기 때문이다. 물론 실제 커피타임 미팅에 대한 진행방법에 대한 설명을 곁들였다.

미팅을 통해 서로가 오해한 사실 하나를 알게 되었다. 서로 커뮤니케이션을 가장 자주한다고 믿었던 일을 할당하는 3명(다른 업무 PL, 아키텍트, 유지보수 담당자)이 서로 다르게 이해한 부분을 찾게 된 것이다. 로컬 개발 환경 구축에 대한 이야기 였는데,

유지보수 담당자는 방화벽 문제로 로컬 개발 환경이 잘 되지 않으니, FTP로 직접 개발서버에 반영하는 것을 가르치고 있었다

아키텍트는 방화벽 문제를 모르고 로컬에서 개발 환경이 잘 잡혀 있다고 생각하고 있었다.

다른 업무 PL은 업무를 가르치던 유지보수 담당자와 전혀 아무런 이야기를 하지 못했다.

3명 모두 제 일을 잘하고 있다고 생각했으나 사실 서로 필요한 대화를 하지 않은 상태였다. 이번 미팅을 통해 3명의 생각을 하나로 가져갈 수 있는 계기를 마련했다.

배운점 : 문제를 감지하면, 조금이라도 빨리 실제 담당자들과 이야기 하여, 상황을 종료시키는 지혜가 필요하다.

(08년 4월 2일) 파일럿 이터레이션 — 8일차

커피타임 미팅 후 한 팀이 커뮤니케이션에 문제가 있는 것을 알아챘다. 팀 B의 두 멤버가 서로 대화하지도 않고 내내 모르는 사람인양 토라져 있었다. 이 들 둘은 애자일 현황판을 함께 업데이트 하는 것조차 꺼리고 있었다. 무엇을 해야 할까, 고민하기 시작했다.

(08년 4월 3일) 파일럿 이터레이션 — 9일차

PM이 짝 이라는 개념에 대한 효용에 의문을 품기 시작했다. 왜냐하면 사이가 나쁜 짝의 경우 서로 전혀 협업이 되지 않고 처음에 둘이 일을 잘못 나눈 경우 한 명이 고생을 해도 옆 사람이 전혀 도와주지 않았기 때문이다.

팀 B는 각각 8년차, 6년차 프리랜스 남-녀 로 구성되었는데 이들 둘은 짝 프로그래밍을 하기는 커녕 처음부터 받은 기능 목록을 둘로 나누고 나눈 기능을 각자 개발하기로 결정했다. 게다가 중간에 전혀 대화를 하지 않고 있었다. 이런 상황에 남성 개발자가 곧 결혼이라 자주 휴가를 내야 하는 상황이 발생하면서 더욱 심해졌다. 여성 개발자는 남성 개발자에 대해 불만을 갖기 시작했다 여성 개발자는 자신의 일을 이미 마쳤지만, 조금도 남성 개발자를 도와주려 하지 않았다. 위 상황을 보고 다음 짝을 지을 때는 보다 서로 편해 하는 상대로 티밍을 해야겠다고 생각했다. (나중에 알게 된 사실이지만, 여성 개발자의 일은 업무 범위 조정에 따라 이미 없어진 뒤였다. 하지만, 커피타임에 여성 개발자는 자신의 상황에 대해 전혀 말하지 않았다.)

배운점 : 짝 프로그래밍은 “코드 공동 소유”라는 프랙티스와 함께 진행해야 하고, 개인적 성향이 강한 개발자들에게 이를 제안하면, 거부반응을 보일 수도 있다. 또한 짝 프로그래밍은 상황에 따라서는 그다지 좋은 방식이 아닐 수 있는다. 예를 들어 두 명의 개발자의 역량이 부족할 때 두 사람이 해야 할 일이 매우 어려운 경우나, 두 명의 개발자의 역량이 매우 좋은데, 두 사람이 해야 할 일이 매우 쉬운 경우의 두 가지 모두 팀 입장에서 보면 큰 낭비가 일어나는 일일 수 있다.

(08년 4월 4일) 파일럿 이터레이션 — 10일차

파일럿 이터레이션 마지막 날이었다. 오전부터 개발팀은 매우 분주했다. 오늘 모두, 구현한 기능에 대한 데모를 하기로 한 날이다. 어제 밤 늦게까지 작업한 개발자들도 있었다. 오전 10시부터 점심 시간까지를 시연 시간을 정했다.

PM을 불러 회의실에 앉히고 한 팀씩 시연을 시작했다. 고객에게도 이야기를 했지만, 고객은 중요한 일이 생겼다며, 회의에 참여하지 못했다. 팀은 기운이 빠졌다. 고객에게 시연을 해야, 2주간 고생한 작업에 대한 검증이 완료된다고 팀은 알고 있었다.

하지만, 고객이 안 온 것이 천만 다행이었다. 시연이 끝나기 전에 문제가 생겼다. 5개 팀이 모두 시연에 참여했는데, 하필이면 첫 팀이 구현한 제품의 수준이 누가 보아도 형편 없었다. PM을 포함한 모두가 얼굴을 찌푸렸다. PM은 “이게 내가 당신들을 신뢰한 결과냐?” 라며 화를 내고 회의실 밖으로 나갔다.

PM이 없는 상황에서 다른 네 팀의 시연은 계속 진행했다. 다른 네 팀의 시연은 결과가 나쁘지 않았다. 서로게 준 피드백으로 화면 표준에 엇나간 것과 개선 사항에 대한 수정 목록을 애자일 보드에 추가했다.

그리고 우리는 자연스럽게 PM의 반응에 대해 무엇을 할 수 있을 지에 대해 고민했다. “오늘 같은 일이 다시 발생하지 않기 위해, 어떻게 하면, 시연 전에 전체 기능의 수준을 올릴 수 있을까?” 이 고민으로 자연스럽게 회고를 시작했다. 팀이 함께 고민하여 “팀이 개발한 내용에 대해 스스로 테스트를 먼저 수행하고, 이 테스트가 끝나면 다른 팀에 의한 재 검증 테스트를 하자” 라는 결론을 냈다. 그리고 이터레이션 9일차 오전에는 시연 전 테스트를, 오후에는 오전에 발견한 결함에 대한 수정을 하기로 팀이 결정했다.

미팅이 끝난 직후PL들은 PM을 만나러 갔다. 긴 시간의 이야기를 통해 PM에게 다른 네 팀은 시연의 결과가 나쁘지 않았으며, 기능에 대해 PL들이 점검하지 않고 PM에게 시연에 참여하라고 한 것은 잘못된 선택이었다고 말했다. 이 것을 통해 우리는 어떻게 프로세스를 개선할 것이라는 이야기도 했다. PM은 다음 이터레이션에는 보다 나은 기능 구현을 기대한다고 말하고 이터레이션을 마쳤다.

자, 지금까지 여러분이 읽은 내용은, 애자일을 최초로 시작한 어떤 팀이 2주간의 이터레이션을 통해 어떻게 발전하는지에 대한 모습이었다. 최초에는 많은 팀이 그렇듯 많은 문제와 갈등이 있었다. 다만, 다른 팀과 달랐던 점은 한 가지씩 서로 배워나가며 현재 상황에서 개선하기 위해 끊임없이 협업 했다는 것이다.

프로젝트는 어떻게 되었을까? 다행히도 납기를 맞추며, 많은 한계이익을 냈고, 무엇보다 고객이 만족한 프로젝트가 되었다. 고객은 이 뒤로 자신이 주관하는 모든 프로젝트는 애자일로 수행해야 한다고 이야기하기 시작했다. 고객이 가장 좋아했던 모습은, 직접적으로는 고객에게 보다 많은 가치를 주려고 노력했고 팀이 스스로 나아지려고 항상 노력했다는 점이다. 이 팀은 2009년 S사의 BP(Best Practice)로 CEO에게 보고되고, 향후 2010년 엔터프라이즈 애자일 전환에 가장 중요한 도화선이 된다.