24. 애자일 방법론으로 프로젝트 진행하기
실리콘밸리 기업들은 어떻게 데드라인 없이 좋은 소프트웨어를 만드는가.
[22. 애자일은 일을 빨리 하는 것이 아니다.]에서 살펴본 바와 같이 애자일 방법론은 제조업에서 주로 활용되는 큰 호흡의 워터폴 방식과 반대로 작은 사이클을 반복하여 최소 기능 제품(MVP: Minimum Viable Product)을 진화시켜 나가는 과정이다.
애자일 방법론을 활용하면 고객이 최소 기능 제품을 일찍 받아보게 되고, 그 피드백을 통해 더 훌륭한 모습으로 다음 제품을 만들어 낼 수 있다. 그렇지만 프로덕트 사이클이 매우 짧고 계속 진화하여 나가기 때문에 어디가 완성이고, 언제 완성된 모습이 되는 것인지에 대해 정확하게 정의하기 힘들다.
소프트웨어에 적용해 보면 윈도즈 7, 윈도즈 8, 윈도즈 10, 이렇게 몇 년에 한 번씩 업데이트되는 소프트웨어는 워터폴 방식으로 진행되어 정확히 단계별 시작과 끝을 알 수 있지만, 페이스북 같은 경우 계속 진화하기 때문에 어느 것이 완성된 버전인지 알 수 없다.
워터폴 방식에서는 프로덕트를 만드는 팀에서 마케팅이나 세일즈 팀에서 “몇 월 며칠까지 이번 버전의 프로덕트가 완성될 것입니다.”라는 말을 할 수 있지만 애자일 방식에서는 그런 약속을 하기가 매우 어렵다.
워터폴 방식과 애자일 방식의 프로젝트 진행 방식의 특성을 정리하면 다음과 같다.
워터폴 vs. 애자일 프로젝트 진행 방식
데드라인
- 워터폴: 데드라인을 정하고 데드라인에 맞춰 자원을 투입하거나 있는 자원을 최대한 활용한다.
- 애자일: 계속 진화하므로 데드라인이 별 의미가 없다. 팀의 프로젝트 진행 속도(throughput)를 측정한다.
외부 요청에 반응
- 워터폴: 계획이 이미 끝났기 때문에 외부 요청은 다음 버전까지 반영할 수 없거나 변경하려면 큰 비용이 발생하므로 반영을 최소화한다.
- 애자일: 프로덕트 사이클이 짧으므로 프로덕트 매니저가 엔지니어링 매니저와 협력하여 외부 요청을 빠르게 반영한다.
프로덕트 매니저의 역할
- 워터폴: 프로덕트 매니저가 필요 없다. 처음에 기획자가 모든 기획안을 만들어서 넘기면 개발팀에서 데드라인에 맞춰 구현한다.
- 애자일:팀의 프로젝트 진행 속도를 측정하여 이 속도로 진행하면 언제쯤 완성될 것인지를 측정한다. 끊임없이 외부 팀과 소통하여 외부 팀의 요구를 반영하고 프로덕트 완성 시점과 우선순위를 업데이트한다.
엔지니어링 매니저의 역할
- 워터폴: 데드라인에 맞춰 프로젝트를 끝내는 것을 관리한다. 데드라인을 못 맞출 것 같으면 외주를 주거나 팀원들에게 지속적인 동기부여(또는 위협)를 한다.
- 애자일: 팀이 매 스프린트마다 일정한 속도로 프로덕트를 만들도록 관리한다. 버그 등을 관리하여 기능이 퇴화되지 않도록 한다.
일의 단위
- 워터폴: 구현해야 할 기능을 기준으로 정한다. “레스토랑 메뉴 선택 화면을 구현한다."
- 애자일: 사용자의 경험을 기준으로 스토리를 정한다. “식당 손님으로서, 레스토랑에서 주문을 하기 위해, 메뉴에서 음식을 선택할 수 있다.”
프로젝트 도구
- 워터폴: 데드라인에 맞춰 기능을 구현하고 인력을 투입할 관리 도구가 필요.
- 애자일: 스프린트당 프로젝트의 속도를 측정하고 다음 스프린트에서 할 수 있는 일들을 예상할 수 있는 진행 도구가 필요.
데드라인과 애자일 속도 (Agile Velocity 또는 Throughput)
워터폴 방식에서는 각 버전 별 데드라인을 정해 놓고 마케팅팀이나 세일즈팀과 소통한다. 프로덕트 팀에서 “이번 애플 행사에는 아이폰 X를 완성해서 내놓을 거예요.”라고 이야기하면 마케팅, 세일즈 팀은 그 데드라인에 맞춰 마케팅 캠페인과 판매 계획을 수립한다. 프로덕트 팀에서는 데드라인을 못 맞추면 다른 팀들의 계획에 차질이 생기므로 많은 문제가 생긴다. 그래서 항상 데드라인에 쫓기면서 “그때까지 못하면 큰일 난다”는 마음가짐으로 야근을 불사하며 열심히 한다. 그리고 계획이 이미 데드라인에 맞추어 꽉 짜여 있기 때문에 엄청나게 중요한 문제가 아니면 프로젝트의 계획을 변경할만한 외부의 요청을 반영할 수 없다.
프로덕트로 꾸준히 진화하는 애자일 방식에서는 데드라인이 존재하지 않는다. 그렇지만 애자일 방식에서도 마케팅이나 세일즈 팀이 언제 새 프로덕트가 나와서 홍보나 판매를 할 수 있을지 알 수 있어야 한다. 그래서 Product Manager는 지속적으로 발전해 나가는 제품에 몇 단계의 land mark를 만들어 고객과 대화하기 쉽도록 한다. “다음 달 말까지는 다음 버전의 페이스북이 나올 거예요"가 아닌 “다음 달 말까지는 타임라인의 동영상 기능이 추가될 거예요.” 정도의 약속을 할 수 있다. 그리고 데드라인이 없기 때문에 유동적으로 외부의 요청을 반영할 수도 있다. 그 경우 프로덕트 매니저는 홍보/판매 팀과 계속적으로 커뮤니케이션을 해야 하며, 홍보/판매 팀도 최대한 유연하게 계획을 세워야 한다.
애자일은 데드라인을 정해놓고 일을 하지 않기 때문에 각 싸이클마다 얼마만큼 일이 진행되는지를 알 수 있는 애자일 속도(agile velocity)를 알고 수 있어야 한다. 즉 다음 달 말까지 완성하기 위해 모든 자원을 투입하고 야근하고 해서 완성하는 것이 아니라 “이 속도로 계속 가면 다음 달 말까지 완성할 수 있겠다”라는 예측을 하는 것이다.
애자일 스크럼에서의 개발 사이클을 “스프린트(sprint)"라고 한다. 장거리 달리기가 아닌 여러 번의 단거리 전력 질주로 프로덕트를 완성해 나가는 것이다. 한 스프린트는 대부분 1주나 2주로 잡는다.
개발팀의 리더십을 맡은 엔지니어링 매니저는 계속해서 팀의 역량을 키움으로써 각 스프린트를 통해 보다 많은 긍정적인 변화를 제품에 반영하고, 기존에 있던 기능이 퇴화(regression) 하지 않도록 노력한다. 이렇게 해서 발전을 거듭하는 개발팀이 있는 조직과 발전하지 못하는 조직이 만들어내는 제품의 시장 경쟁력은 몇 달이 지나고 몇 해가 지나면서 분명하게 드러나기 마련이다.
워터폴 방식에서는 프로젝트 진행에 있어 데드라인이 제일 중요한 반면, 애자일 방법에서는 각 스프린트 별 프로젝트 진행 속도, 즉 애자일 속도가 제일 중요하다.
애자일에서의 일의 단위, Theme > Epic > Story > Task
Theme: “태블릿과 클라우드 서비스를 통한 레스토랑 주문 시스템.”
Epic: “고객으로서, 테이블의 태블릿을 통해 음식과 관련된 일을 처리할 수 있다.
Story: “고객으로서, 음식을 주문하기 위해, 메뉴를 볼 수 있다.”
Task: “음식 사진이 배열된 메뉴 화면을 구현한다.”
애자일에서 일의 기본 단위는 “스토리(Story)”다. 스토리는 ‘어떤 사용자가, 어떤 목적을 위해, 어떤 행동을 할 수 있다’라는 식으로 표현되는 일의 단위이다. 예를 들어 레스토랑 주문 시스템을 만든다고 할 때, ‘메뉴를 만든다’라고 하지 않고, “고객으로서, 음식을 주문하기 위해, 메뉴를 볼 수 있다”라고 하는 것이 스토리가 된다. ‘메뉴를 만든다’라고 하는 앞의 문장은, 그림과 음식의 설명, 그리고 가격으로 구성된 메뉴 데이터베이스를 만들고 적당한 페이지를 만드는 일로 종료될 수 있다. 하지만 고객이 메뉴를 보기 위해 어떤 과정을 거치는지, 메뉴를 보면서 음식을 쉽게 주문할 수 있는지에 대한 내용이 같이 고려되어야 한다는 것을 표현하기에는 뒤의 문장이 더 적절하다. 즉 일의 단위가 기능을 정의하는 것이 아니라 사용자의 경험을 정의하는 것이다.
이러한 단위의 스토리들이 모여 고객을 만족시키는 큰 스토리를 에픽(Epic)이라고 부른다. “고객으로서, 메뉴에서 고른 내용을 주문할 수 있다”, “고객으로서, 주문한 금액을 편리하게 지불할 수 있다”, “고객으로서, 주문한 음식이 언제 나올 것인지 알 수 있다” 등의 스토리들은 전체적으로 다음과 같은 에픽에 포함될 수 있다. “고객으로서, 테이블의 태블릿을 통해 음식과 관련된 일을 처리할 수 있다.”
레스토랑 주문 시스템은 고객과 주방, 그리고 그 사이에 음식을 서빙하는 종업원을 모두 돕기 위해 만들어지는 것이므로, 다음과 같은 에픽들을 포함할 것 같다. “셰프로서, 주문이 들어온 음식을 순서대로 만들고 종업원에게 준비된 음식을 알릴 수 있다”, “종업원으로서, 준비된 음식을 주문자의 좌석으로 전달하고 추가 사항을 주방에 전달할 수 있다”. 이 시스템이 발전하면 “레스토랑 주인으로서, 자주 찾는 고객에게 더 큰 만족을 줄 수 있다”와 같은 에픽을 추가하게 될지도 모른다.
이와 같은 에픽들이 모이면 “태블릿과 클라우드 서비스를 통한 레스토랑 시스템”이라는 Theme이 완성된다.
스토리를 더 작은 단위의 일로 나누면 태스크(Task), 더 세분하면 Sub-task가 된다. 실제 Agile team에서 매일 아침에 모여하는 스탠드업 미팅에서 다루는 일의 단위는 Task나 Sub-task인 경우가 대부분이다.
관리 도구 vs 진행 도구
애자일 프로젝트의 진행 상황을 모니터하고 팀이 효율적으로 일할 수 있도록 많은 애자일 방법(agile methodology)들이 개발되어 왔다. 이중 가장 흔하게 쓰이는 방법으로 Scrum과 Kanban이 있는데, 이 둘은 서로 상충된 개념이 아니어서 둘을 섞어서 쓰는 개발팀도 종종 볼 수 있다. 자주 이직을 하는 실리콘밸리의 스타트업 회사들의 특성상, 개발 방법론이나 사용되는 도구들은 대개 몇 가지로 정해지기 마련이다. 회사를 옮기더라도 개발 방법론이나 사용하는 기술, 그리고 조직 내 세분화된 역할이 거의 정해져 있어서 거의 2주~4주 안에 정상 속도로 프로젝트에 참여가 가능하다.
데드라인에 맞추어 프로젝트를 진행하는 워터폴 방식에서는 관리자가 주어진 일을 개별 팀원에게 나눠서 주어진 시간과 비용 안에 해결하기 위해 개발된 ‘관리 도구’가 필요하다. 반면 애자일 방식의 도구들은 팀 전체가 일정한 속도로 프로덕트를 생산하여 고객에게 효율적으로 가치를 전달하는데 필요한 ‘진행 도구’로서의 관점에서 개발되어 왔다.
스마트 워치는 그저 오늘의 운동량을 보여주기만 하는 것으로 우리는 점심 식사 후 ‘조금 걸어볼까?’ 하는 생각을 하도록 만든다. 퍼포먼스를 개선하는 것은 상황을 숫자로 표현하는 것에서 출발한다. Scrum이든 Kanban이든, 애자일 도구에서 표현하는 performance metric은 개개인의 퍼포먼스보다는 고객에게 전달될 가치를 전체 팀이 전달하고 있는 속도를 표현하는데 초점이 맞추어져 있다. 어떤 팀원의 ‘소극적 참여’에 의해 팀 전체의 퍼포먼스가 영향을 받는 일은 매니저의 갈굼(?) 보다는 팀원들의 peer pressure가 긍정적인 결과를 가져오는 경우가 많다.
스크럼(Scrum)
스크럼을 짜서 움직이는 운동선수들 처럼 여럿이 같이 움직이는 팀워크는 힘차고 역동적이다“스크럼을 짜서 움직이는 운동선수들처럼 여럿이 같이 움직이는 팀워크는 힘차고 역동적이다”라고 말하기에 애자일 스크럼 팀의 일상을 들여다보면 조금 쑥스럽다. 스크럼 팀원들은 자신에게 할당된 Task를 혼자서 묵묵히 해나간다.
애자일 보드에서 티켓을 하나 골라서 자신에게 할당하거나 이미 자신에게 할당된 티켓을 하나 골라 In Progress로 옮겨 놓고 일을 진행한다. 자신의 일을 마치고 나면 리뷰로 옮겨 놓고, 리뷰가 끝나면 Done으로 옮긴다. 2주에 한번 정도 스프린트(Sprint)를 반복하며 스프린트 단위의 미팅, 그리고 매일 한 번씩 있는 스탠드업(Stand-up) 미팅을 참여하는 이외에는 혼자서 일을 하게 된다. 기본적으로 다른 팀원의 진행상황과 상관없이 일이 진행되므로 다른 사람과 같은 시간에 일을 할 필요가 없다. 그래서 출퇴근 시간도 자유롭고, 집에서 일을 해도 되며, 휴가도 마음대로 갈 수 있는 시스템이 가능하게 된다.
이렇게 차분한 개발 조직이지만, 애자일 정신에 따라 고객에게 가치를 전달하는 최소 단위가 되는 스토리를 팀이 함께 움직여 만들어 낸다는 의미를 담기 위해 스크럼이라는 표현을 사용한다. 마치 풋볼 경기에서 달리기를 잘하는 한 사람이 아무리 빨리 달려도 공을 던지는 사람과 호흡이 맞지 않아 점수를 내지 못했다면 아무 소용이 없는 것과 같이, 엔지니어와 매니저와 UX 디자이너 등 모든 팀원이 각자의 역할을 잘 수행하여 고객이 사용할 수 있는 완결된 스토리를 만들어내지 못한다면 스프린트는 아무 성과가 없는 것이나 마찬가지이기 때문이다.
애자일 팀이 한 스프린트를 마쳤을 때 보통 몇 개 이상의 스토리를 전달하기 마련이다. 스프린트가 지나가는 동안 하나의 스토리도 전달하지 못하는 일이 반복된다면, 스토리의 크기에 비해 팀이 너무 작거나, 너무 짧은 스프린트의 길이를 선택했기 때문일 것이다. 팀의 크기를 갑자기 키우기는 어려울 것이므로 스프린트의 길이를 크게 가져가거나 더 작은 스토리로 쪼개는 수밖에 없다. 따라서 스토리의 크기가 과연 어느 정도 크기인가 팀의 입장에서 이해하는 일은 스프린트 계획(Sprint Planning) 미팅에서 일어나야 하는 중요한 일중의 하나이다.
스토리 포인트 예측(Estimation) 미팅
팀원 각자가 각각의 스토리가 얼마나 오래 걸리는 일이라고 생각하는지 카드를 통해서 표현하고 서로 합의하는 플래닝 포커스크럼을 진지하게 사용하는 팀에서는 Estimation 미팅을 따로 가지기도 하는데, 팀 전체가 모여서 스토리들을 늘어놓고 각 스토리마다 스토리 포인트(Story-point)라고 하는 단위로 일의 크기를 매기는 자리이다.
각 스토리가 얼마큼 시간이 걸리는 지를 예측하기 위해 포커와 비슷한 게임을 한다. 각 팀원들은 1, 2, 3, 5, 8, 13, 20, 40, 100과 같은 Fibonacci와 비슷한 단위의 숫자가 적힌 카드를 가진다. 그리고 한 스토리가 얼만큼의 사이즈라고 생각하는지 카드를 제시한다. 5명이 모여 voting을 했는데, 세 사람이 2라고 하고 한 사람이 8, 한 사람이 1이라고 했다면, 8이라고 한 사람, 1이라고 한 사람의 의견을 들어보고 다시 한번 voting을 한다. 이렇게 수렴된 숫자로 스토리 포인트를 매긴다.
만약 팀 전체가 최근의 스프린트 들을 통해 50 스토리 포인트를 한 스프린트에 전달할 수 있었다면, 그 팀의 애자일 속도가 50이 된다. 팀은 다음 스프린트에 그만큼 어치의 스토리들을 전달할 수 있도록 노력하자고 약속하는 것이다.
스프린트 계획(Sprint Planning) 미팅
1주일이나 2주일에 한번 정도 한 시간 정도의 시간을 할애하여 스프린트 계획 미팅을 갖는다. 스프린트 계획 미팅에서는 앞의 스토리 포인트 예측 미팅에서 점수를 할당한 스토리들을 가지고 다음 스프린트 동안 어떤 스토리들을 처리할 것인지 계획한다.
스토리보다 큰 그림인 에픽을 완성해 나가는 목표를 생각하면서 스토리의 우선순위를 정하는 것이 가장 이상적이다. 그렇지만 기존 프로젝트의 버그 해결이나 유지보수 등 에픽에 해당하지 않지만 꼭 필요한 일도 있으므로 우선순위는 그때그때 변할 수밖에 없다.
스프린트 계획 미팅에서는 누가 각 스토리 티켓을 수행할지 정하는 경우도 있고 아니면 지금까지 팀의 속도(스프린트 당 수행한 스토리 포인트의 합)를 고려하여 스토리만 추가해 놓고 스프린트 진행 중에 자신이 원하는 스토리 티켓을 선택하며 수행하기도 한다.
스탠드업(Stand-up) 미팅
스탠드업 미팅은 각 사람별로 선택한 태스크의 상황을 팀에게 이야기하고 진행이 더디게 된 경우에는 팀 전체로부터 어떠한 도움이 필요한지 설명하는 자리이다. 이때 스크럼 마스터(Scrum Master)라고 하는 역할을 Project Manager 혹은 팀원들 중 한 명이 돌아가면서 맡아 진행자 역할을 한다.
전통적 생산관리 기법에서의 매니저처럼 ‘어제 하기로 한 것을 하지 못했으니 오늘 저녁은 늦게 까지 일해야 할 것’과 같은 압력을 넣는 역할을 하는 것이 절대 아니다. 제품을 사용하고 있는 고객의 문제(Production Issues)를 우선적으로 해결하느라 개발 태스크를 소화 못하는 일도 흔히 있는 일이기 때문에, 어느 정도의 예측에 어긋나는 일은 이미 팀의 애자일 속도에 포함되어 있어야 한다. 다만 다른 팀의 누군가(보통 DBA와 같은 제한된 리소스)의 도움이 필요하다던지 하는 일은 Project Managent팀을 통해 신속히 해결할 수 있어야 한다.
스탠드업 미팅은 다음과 같은 특징을 가진다.
1. 보통 아침에 한다. 너무 늦을 경우 하루가 짧아지거나 학교에 다니는 아이가 있는 팀원들이 손해를 보게 되고, 너무 이를 경우 참석률이 안 좋아지는 특징이 있다. 매니저급일수록 아이가 있을 확률이 높다는 것이 함정이다.
2. 어제 한일, 오늘 할 일, 진행을 막는 일이 있다면 설명하고 누구의 도움이 필요한지 이야기한다.
3. 10분을 넘기지 않는 것이 원칙이다. 이를 위해 서서 진행하는데, 스탠드업 미팅이 20분 이상 진행될 경우 하루에 써야 할 에너지를 서서 다른 사람들 태스크에 관한 이야기를 듣다가 써버리게 되므로 스크럼 마스터가 가장 신경 써야 할 부분 중의 하나이다.
4. 중간중간 Burndown Chart를 보며 서로 약속한 스토리들을 이번 스프린트가 끝날 때 전달할 수 있을 것인지 체크한다.
Burndown Chart스프린트 리뷰(Sprint Review) 미팅
지속적인 개선(Continuous Improvement)이라는 관점에서, 스프린트 리뷰 미팅은 매우 중요하다. 이 미팅을 통해 스토리가 전달된 과정을 점검하고, 만약 전달되지 않은 스토리가 있었다면 팀이 다음 스프린트에서 어떻게 더 약속을 잘 지킬 수 있을 것인지 검토한다. 만약 팀의 애자일 속도가 점점 빨라진다면 아마 이 스프린트 리뷰 미팅에서 팀원들이 정직하고 성실하게 팀워크를 향상하기 위한 노력을 했기 때문일 것이다. 각각의 부품을 만들어낸 팀원들이 완성한 스토리들의 데모를 보며, 팀원들이 지난 스프린트를 통해 열심히 일한 결과를 축하하는 자리이기도 하다.
스프린트 리뷰에서는 간단히 공유 문서를 열어 잘된 점, 잘 못된 점, 그리고 개선책을 적는다. 그리고 잘된 점들에 대해 함께 기뻐하고 축하하며 잘못된 점에 대해서는 개선책을 함께 논의한다. 그리고 개선책 란에 정리해서 다음 스프린트는 더 효율적이고 좋은 업무 경험이 될 수 있도록 노력한다.
칸반(Kanban)
칸반 보드의 예일본어로 칸반은 우리말로 간판이라 읽히지만, 뜻은 게시판에 가깝다. 도요타에서 생산 운영의 효율화를 위해 게시판을 활용해 만들어낸 기법이다. 왼쪽은 원재료, 오른쪽은 공정이 끝난 제품을 표시함으로써, 그 사이에 일어나는 스텝들에 얼마만큼의 재료가 투입되고 있는가 하는 표현을 쉽게 할 수 있다.
칸반 방식에서는 스프린트를 나누지 않는다. 일이 새로 들어오면 Backlog에 쌓이고 일이 없어진 사람은 Backlog에 있는 일을 선택해서 수행한다.
도요타의 유명한 “Just-in-Time 운영방법”에 따라 현재 진행 중인 티켓의 수를 제한하는 것이 Kanban의 핵심 개념이다. 하루에 만대가 넘는 생산량을 자랑하는 도요타의 경우 원재료가 공장에 들어와 완제품이 될 때까지 많은 시간을 소요할수록 더 많은 비용이 들어가기 때문에 이를 줄이기 위해 고심하다 만든 방법이다. 동시에 진행할 수 있는 일의 수를 제한해 버리면 전체 효율이 올라간다는 관점이다. 군더더기를 뺀다라는 의미로 Lean 방법이라고도 부른다.
소프트웨어 개발에서 동시에 진행 중(work-in-progress)인 태스크의 숫자를 제한하면 팀이 몇 가지 적은 수의 일에 집중하도록 유도할 수 있다. 애자일 팀에서 동시에 처리하는 태스크를 너무 많이 가져가면 결과적으로 완료하는 시간이 점점 느려지기 때문에 고객에게 빠르게 가치를 전달하는 애자일 개념에 어긋나게 된다. 스크럼에서 애자일 속도에 따라 스프린트를 통해 약속할 수 있는 스토리 포인트를 제한하는 것과 같은 의미로 생각할 수 있다.
스크럼에서 스프린트가 진행 중인 상황에 어떤 엔지니어가 자신의 태스크를 일찍 끝냈다면 다른 엔지니어가 맡은 일을 도와주는 등, 약속한 스토리를 고객에게 전달하는데 최선을 다할 것이다. 칸반에서는 일이 끝냈을 때 다른 사람의 일을 도와주기보다는 다음 Backlog 태스크를 Project Manager와 상의해서 맡는 것이 자연스럽다.
칸반에서는 사이클 안에 정해진 스토리 포인트를 태우는 Burndown Chart보다는, 태스크들이 Backlog에서 Closed 상태가 될 때까지 걸리는 시간에 대한 Control Chart를 사용해 팀의 개발 프로세스의 이상 징후나 문제가 있었던 태스크에 대한 대응책을 마련할 수 있도록 한다.
Control Chart소프트웨어 프로젝트 관리
스크럼이나 칸반 모두 애자일 프로젝트의 진행 방법으로 자리를 잡아가면서 많은 소프트웨어 도구들이 만들어지고 있지만, 어떤 도구와 어떤 방법론을 언제 사용해야 하는지는 팀 스스로가 결정해야 할 과제로 남겨진다.
스크럼은 ‘이미 익숙한 일들을 해내는 전문가들’이 모여 고객에게 의미 있는 분량의 제품 업데이트를 제공하기에 적합하다. 사용하는 프로그래밍 언어와 라이브러리가 이미 친숙한 상태에서 Product Manager가 정리해 둔 스토리를 하나씩 태스크로 나누어 만들어가는 과정이라면 각 태스크의 스토리 포인트에 대해 크게 의견이 갈리지 않을 것이다. 제품을 시험하는 과정을 자동화하는 것까지의 모든 태스크를 한 스프린트를 통해 마친다고 하는 것은 상당한 팀워크를 요하는 일이다.
잠재적인 고객은 있지만, 상당한 리서치를 요하는 제품을 개발할 때에는 상황이 조금 다르다. 제품을 만들 때 써야 하는 기술 자체를 함께 개발해야 하는 경우에는 특별히 스프린트를 통해 고객에게 전달할 수 있는 의미 있는 분량의 스토리를 만들기 힘들기 때문이다. 이럴 때에는 연구과제를 포함한 태스크들을 세분화하고, 이들의 진척 상황을 꾸준히 관찰할 수 있는 칸반이 적합하다.
스토리 포인트로 업무의 부담이 정확히 관리되는 환경에서 각 개인은 자신만의 업무 속도를 쉽게 알 수 있다. 어떤 사람을 빠르고 어떤 사람을 느릴 것이다. 스크럼 마스터의 역할은 각 사람의 일의 속도를 반영하여 계획을 하고 프로젝트를 수행하는 것이다. 어떤 팀원이 너무 일을 느리게 한다고 해서 혼나거나 벌을 주는 경우는 없다. 다만 팀원의 업무가 전체의 속도에 지장을 주는 일이 반복될 경우 3개월여의 공식적인 절차인 업무 개선 프로그램(Performance Improvement Program)을 거치게 된다. 그리고 그 기간 동안 업무 속도가 팀에서 필요한 만큼 개선되지 않으면 해고된다.
글: Aiden. 엔지니어링 매니저. 데이터 수집을 통한 프로세스 개선에 관심이 많음.
그림: Chili. 디자이너. 생각을 그림으로 요약하는데 관심이 많음.
Project Group 실리콘밸리를 그리다 / 페이스북
