2장. 팀#2
#2-2 일기(1/2)
#2-2 일기(1/2)
필자는 운이 좋았다. 훌륭한 애자일 코치와 더불어 당시 스크럼을 제대로 경험해 볼 기회가 있었다. 그리고 그때를 시작으로 이후 수행하는 프로젝트마다 일하는 방법을 조금씩 개선해 나갔다. 있었던 일을 가능하면 상세하게 기록으로 남기고 개선하면 좋겠다는 생각에, 일기 형태의 문서를 쓰기 시작했다. 업무가 끝나면 매일 글을 쓰면서, 혼자서 하는 회고를 진행했다.
아래 작성된 내용은 08년 봄, 필자와 애자일 코치가 함께 했던 프로젝트에 대한 이야기이다. 분야는 공공사업이며, 8개월간 수행해야 하는 SI 사업이었다. 고정된 납기/스케줄/예산이 있었고 그 안에서 필자는 나름대로 스크럼 프로세스로 일하려고 애썼다.
* 사전 준비
(08년 3월 14일) 사전 준비 — 애자일 시작하기
프로젝트 전체 인원 13명의 개발자와 관리자를 모아놓고 첫 미팅을 가졌다. (난 두 개의 팀 중 한 팀의 스크럼 마스터 겸 리더 역할을 하기로 했다.) 필자는 프로젝트 관리자과의 약속을 기반으로 “우리 프로젝트는 애자일 방식으로 진행할 것이다”라고 말했다. 그들에게도 나에게도 모든 것이 처음이었다.
우선 개발자들에게 내가 이해하고 있는 애자일 방식에 대해 짧게 설명했다. X 축은 시간, Y축은 가치인 그래프를 그려 우리가 진행할 방식은 계획 중심이 아니라 가치 중심이라고 이야기하고 공감을 구했다. 물론 사전에 프로젝트 관리자에게 먼저 설명하여 관리자에게 사전 동의를 구했다. 그리고 진척 관리는 “짝”의 역할을 기반으로 하기로 했다.
두 명이 한 그룹씩 짝을 짓고, 두 명이 할 만큼의 양의 일을 스스로 판단하여 가져 가고, 책임도 두 사람의 공동 책임으로 하자고 제안했다. 또한 “짝 프로그래밍”에 대해 언급하고 방식에 대해 설명했다. 혹시 짝 프로그래밍을 원하는 팀원이 있으면, 하면 더 좋다 라고만 이야기했다. 팀원들은 어리둥절해하면서도, 크게 본인들에게는 예상치 못한 문제가 발생하지 않을 것이라고 생각하면서 특별한 반응 없이 이 내용을 받아들였다.
[짝 프로그래밍 사진]관리자들에게는 팀원들을 믿고 진척을 투명하게 표시할 수 있는 대시보드 이외에는 신경 쓰지 말아야 한다고 강조했다. 처음부터 욕심을 내지 않고 애자일의 기법 중 팀에 바로 적용할 수 있다는 것부터 먼저 시작했다.
전체적인 애자일 설명을 처음에 한 것 말고는 대부분 실제 해보기 직전에 기법을 설명했다. “스탠드 업 미팅”, “사용자 스토리”, “회고”, “2주 단위 이터레이션”, “지속적인 통합”, “스크럼 보드”, “짝 프로그래밍” 정도를 활용했다. “테스트 주도 개발” 같은 어려운 엔지니어링 기법은 처음부터 고려하지 않기로 했다.
13명의 인원 중 설계/개발을 수행할 11명을 5그룹으로 나누었다. 그리고 처음 2주 이터레이션 동안 작업할 내용을 함께 논의하여 결정했다.
팀 1(팀 공통 (2명)) : 공통기능을 전담으로 개발할 팀이다.
팀 2(팀 드라이버 (3명)) : 프로토타이핑을 2주간 진행하여 기술검증을 수행하고, 2주간 개발하기 위한 소스코드 템플릿을 받아, 다른 개발자들에게 제공하고 트러블슈팅을 돕는다.
팀 3,4,5((각 2명, 총 6명)) : 각 업무의 프로세스를 그리고, 기존 기술 구조에 화면 한 개씩을 만들어 보는 작업을 수행한다.
부가적으로 팀원 모두가 지켜야 하는 그라운드 룰을 정하자고 제안했다. 팀원들은 그동안 과거 프로젝트를 진행하면서 하면서 가장 큰 문제라고 생각했던 것이 개발에 집중할 시간을 뺐는 계획에 없던 회의였다고 이야기했다. 내가 우선 누군가가 “회의시간 및 의제는 반드시 사전에 공지한다”라고 화이트 보트에 적으니, 다른 개발자 한 명이 손을 들어 “그 ‘사전’이라는 게 얼마 정도의 시간인지 정해야 할 것 같아요.”라고 의견을 보탰다. 잠시의 토론 끝에 “회의시간 및 의제는 반드시 1시간 전에는 공지해야 한다” 로 수정했다.
또한 전체 팀원이 모여 있을 때, 이터레이션 길이에 대해 한번 더 논의했다. 관리자는 1주일 단위의 이터레이션을 원했고, 개발자들은 스크럼이 그렇듯이 적어도 4주는 되어야 한다고 이야기했다. 관리자는 전체 프로젝트가 8개월인데, 분석 단계와 통합 테스트 단계를 제외하면, 6개월밖에 안 되는데, 4주에 한 번씩 확인을 할 경우 문제점을 알아챌 수 있는 시점이 너무 늦는다고 이야기했고, 개발자들은 1주일 단위의 이터레이션을 할 경우 1주일에 실제 개발할 수 있는 시간이 3일이 채 안될 수도 있다고 맞섰다. 이 줄다리기는 결국 “2주”로 결론이 났다. 꽤 길어질 수도 있는 논쟁거리였는데, 회의 시간을 60분으로 정한 타임박스의 도움이 컸다.
다음에는 함께 사용자 스토리를 적어 스크럼 보드에 적어 놓을 생각이다. 첫 미팅은 많은 공감을 일으켰다. 하나 즐거웠던 점은 이번 프로젝트에서 나는 관리자가 아닌 퍼실리테이터였다. 이 생각이 혼자서 한 것이 아니기를 기대한다.
* 스크럼 보드를 만들다.
(08년 3월 17일) 사전 준비 — 스크럼 보드 #1
오늘 스크럼 보드를 만들기 위한 패널 3개와 라벨지를 사 왔다. 포스트잇도 잔뜩 사 왔다. 모두에게 스크럼 보드를 사용하는 이유를 설명했다. 관리자에게는 전체 프로젝트 진척사항을 확인할 수 있다고 했다. 또한 다음 이터레이션을 위한 팀 예상 속도를 구할 수 있다고 설명했다. (이전 이터레이션에서 완료한 사용자 스토리 총 수 / 사용 가능한 맨 데이).
좋았던 점 — 스크럼 보드를 사 왔다.
아쉬운 점 — 오늘 우리를 담당하는 고객과 첫 대면했는데, 특별한 이유 없이 우리 팀에 대해 부정적인 인식을 가지고 있다는 것을 알게 되었다. 또한 방법론을 테일러링 하려고 들어온 타조직의 인력은 내가 애자일 방식으로 프로젝트를 한다고 하니 “누군가 시도하지 않는 것을 하는 너의 열정이 다른 사람에겐 독이 될 수 있다는 것을 알아야 한다”라고 말했다. 내가 원하는 것은 개발할 때 좀 더 즐겁게 일하는 것이다. 그게 뭐가 그리 문제란 말인가? (당시는 주변의 이야기에 귀가 잘 안 들렸던 것 같다.)
(08년 3월 18일) 사전 준비 — 스크럼 보드 #2
스크럼 보드를 만들었다. 다음과 같이 보드의 섹션을 나누었다.
[준비 중] — [진행 중] — [완료] — [진척도] — [예상외 작업] — [다음으로]
“준비 중”에는 이번 이터레이션에서 구현하기로 한 작업 태스크를 붙이고, “진행 중”에는 현재 우리 팀원 중 누군가가 작업하고 있는 일, 완료는 개발 및 단위 테스트가 완료된 것을 붙여놓기로 했다. “진척도”는 번다운 차트로 남은 일의 양을 표시하고, “예상외 작업”은 갑자기 밀려들어오는 작업을 붙이고 이터레이션 안에서는 못 들어오게 하기 위해 만들었다. “다음으로” 에는 고객이 중간에 우선순위를 바꾸어 이터레이션 내에서 개발이 필요 없게 되는 내용을 붙이려고 했다. (실제로 프로젝트 시작 전, 특정 업무 영역이 고객 의사결정에 따라 개발대상에서 전체가 사라질 수도 있는 상황이었다.)
[스크럼 보드 그림]현황판을 붙일 때 사용자 스토리를 어떻게 작성할지 그리고, 어떻게 추정할 지에 대해 고민했다. 프로젝트에 참여한 대부분의 개발자는 현재 업무의 수행 경험이 없었던지라, 얼마나 양이될지 의견을 내기 조차 버거워했다.
필자는 주변 다른 팀 중 경험이 많은 분들에게 공수 측정에 대한 도움을 청하려고 했고, 이 생각을 팀원들에게 이야기했다. 팀원들은 필자의 기대와 달리 이 접근에 대해 부정적으로 반응했다. 팀원들은 우리가 작업할 것인데, 그쪽(유지보수팀)이 산정해온 공수를 그대로 받아들이는 것은 무리한 일이라고 이야기했다. 대신에 팀은, 실제 개발에 대한 공수를 측정할 수 있도록 2주간 파일럿 이터레이션을 수행하기 원했고 이와 더불어 우리가 해야 하는 일들의 공수를 스스로 측정하고 싶다고 이야기했다.
우리 프로젝트는 추가적인 아키텍처를 별도로 만들 필요가 없었다. 유지보수의 개발환경을 일부 활용하면 당장 설계/개발에 들어갈 수도 있는 상황이었다. 하지만, 유지보수팀은 자신들이 커밋하는 저장소를 공유하는 것을 원하지 않았다. 자신들이 수정/배포하는 소스코드와 우리 개발팀이 수정하는 코드가 겹칠 수 있다는 것을 문제 제기하며, 개발환경을 별개로 할 것을 요구했다. 실제로도 사고라도 나면 개발팀뿐만이 아니라 유지보수팀에게도 큰 문제가 될 상황이 발생할 수 있었다. 일단 우리는 추후 소스코드 병합(Merge)의 고통을 줄이기 위한 방안을 마련해 줄 것을 소프트웨어 아키텍트에게 의뢰했다. 아키텍트는 유지보수와의 협업 후에 유지보수의 공통부분을 jar 파일로 제공하고, 우리가 참조할 수 있는 안을 가져왔다.
물론 겹치는 부분도 일부분 있었으나, 그 패키지는 명명규칙 자체를 달리하여 일단 형상에 반영하고, 추후 병합해야 할 시기에 형상 서버를 확인하며, 유지보수팀과 함께 검증하기로 했다. 이렇게 가능하게 하기 위한 환경에 대해서는 차근차근 아키텍트가 준비하기로 했으나, 우리는 당장 개발할 수 있는 환경을 필요로 했다. 아키텍트의 작업이 끝나기만 기다릴 수 없었다. 유지보수팀은 협의 끝에 일부 및 패키지 구조에 대해 우리가 개발 환경에 디플로이 하는 것을 허락했고 소프트웨어 아키텍트가 개발환경을 만드는 동안, 그 패키지 영역을 이용하여 이터레이션 개발을 위한 파일럿 이터레이션을 수행하게 되었다. (많은 회사들이 이 “파일럿 이터레이션”을 '이터레이션 0''라고 부른다)
