데드라인 없이 좋은 소프트웨어 개발하는 법 : 애자일 프로젝트 스터디

데드라인 없이 좋은 소프트웨어 개발하는 법 : 애자일 프로젝트 스터디

데드라인 대신 애자일 속도

윈도우 7, 윈도우 8, 윈도우 10 등 몇 년에 한 번씩 업데이트되는 소프트웨어는 워터폴 방식으로 진행되어 정확히 단계별 시작과 끝을 알 수 있다. 하지만 페이스북 앱은 계속 진화하기 때문에 어느 것이 완성된 버전인지 알 수 없다.
워터폴 방식에서는 프로덕트를 만드는 팀이 마케팅이나 세일즈 팀에 “몇 월 며칠까지 이번 버전의 프로덕트가 완성될 것입니다.”라고 말할 수 있지만 애자일 방식에서는 그런 약속을 하기가 매우 어렵다.
애자일 방법론을 활용하면 고객은 최소기능제품을 일찍 받아볼 수 있고, 회사는 고객의 피드백을 통해 다음 제품을 더 훌륭하게 만들 수 있다. 그렇지만 프로덕트 사이클이 매우 짧고 계속 진화하기 때문에 무엇이 완성이고, 언제 완성품이 되는지를 정확하게 정의하기 힘들다.
또 프로덕트로 꾸준히 진화하는 애자일 방식에서는 데드라인이 없다. 그렇지만 애자일 방식에서도 마케팅이나 세일즈 팀이 언제 새 프로덕트가 나와서 홍보나 판매를 할 수 있는지 알 수 있어야 한다. 그래서 프로덕트 매니저는 지속적으로 발전해나가는 제품에 몇 단계의 랜드마크를 만들어 고객과 대화한다. “다음 달 말까지는 다음 버전의 페이스북이 나올 거예요.”가 아닌 “다음 달 말까지는 타임라인의 동영상 기능이 추가될 거예요.” 정도의 약속을 한다. 그리고 데드라인이 없기 때문에 유동적으로 외부 요청을 반영한다. 그 경우 프로덕트 매니저는 홍보 및 판매 팀과 계속적으로 의사소통을 해야 하며, 홍보 및 판매 팀도 최대한 유연하게 계획을 세워야 한다.
애자일은 데드라인을 정해놓고 일하지 않기 때문에 각 사이클마다 얼마나 일이 진행되는지를 알 수 있는 ‘애자일 속도’Agile velocity가 필요하다. 즉 다음 달 말까지 완성하기 위해 모든 자원을 투입하고 야근하고 해서 완성하는 것이 아니라 “계속 이 속도로 가면 다음 달 말까지 완성할 수 있겠다.”라고 예측하는 것이다.
애자일 스크럼에서의 개발 사이클을 ‘스프린트’Sprint 라고 한다. 장거리 달리기가 아닌 여러 번의 단거리 전력 질주로 프로덕트를 완성해나가는 것이다. 스프린트는 대부분 1~2주로 잡는다.
개발 팀의 리더를 맡은 엔지니어링 매니저는 계속해서 팀의 역량을 키움으로써 각 스프린트를 통해 보다 많은 긍정적인 변화를 제품에 반영하고, 기존에 있던 기능이 퇴화하지 않도록 노력한다. 이렇게 해서 발전을 거듭하는 조직과 발전하지 못하는 조직이 만들어내는 제품의 시장 경쟁력은 몇 달이 지나고 몇 해가 지나면서 분명하게 드러나기 마련이다.
워터폴 방식에서는 프로젝트 진행에 있어 데드라인이 제일 중요한 반면, 애자일 방식에서는 각 스프린트별 프로젝트 진행 속도, 즉 애자일 속도가 제일 중요하다.

애자일 태스크 단위 : 테마 >에픽 >스토리

애자일에서 일, 즉 태스크Task의 기본 단위는 스토리Story다. 스토리는 ‘어떤 사용자가, 어떤 목적을 위해, 어떤 행동을 할 수 있다.’라는 식으로 표현된다. 예를 들어 레스토랑 주문 시스템을 만든다고 할 때 “메뉴를 만든다.”라고 하지 않고 “고객으로서, 음식을 주문하기 위해, 메뉴를 볼 수 있다.”라고 한다. “메뉴를 만든다.”라고 하는 앞의 문장은, 그림과 음식 설명, 가격으로 구성된 메뉴 데이터베이스를 만들고 적당한 페이지를 만드는 일로 종료될 수 있다. 하지만 고객이 메뉴를 보기 위해 어떤 과정을 거치는지, 메뉴를 보면서 음식을 쉽게 주문할 수 있는지에 대한 내용이 같이 고려되어야 한다는 것을 표현하기에는 뒤의 문장이 더 적절하다. 즉 태스크의 단위는 기능이 아닌 사용자 경험을 정의한다.
이러한 스토리들이 모여 고객을 만족시키는 큰 스토리가 되는데, 이를 에픽Epic이라고 부른다. “고객으로서, 메뉴에서 고른 내용을 주문할 수 있다.” “고객으로서, 주문한 음식의 금액을 편리하게 지불할 수 있다.” “고객으로서, 주문한 음식이 언제 나오는지 알 수 있다.” 등의 스토리는 전체적으로 다음과 같은 에픽에 포함될 수 있다. “고객으로서, 테이블의 태블릿을 통해 음식과 관련된 일을 처리할 수 있다.”
레스토랑 주문 시스템은 고객과 주방, 그리고 그 사이에 음식을 서빙하는 종업원 모두를 돕기 위한 것이므로, 다음과 같은 에픽들을 포함할 것 같다.
“셰프로서, 음식을 주문이 들어온 순서대로 만들고 종업원에게 준비된 음식을 알릴 수 있다.” “종업원으로서, 준비된 음식을 주문자의 좌석으로 전달하고 추가 사항을 주방에 전달할 수 있다.” 이 시스템이 발전하면 “레스토랑주인으로서, 자주 찾는 고객에게 더 큰 만족을 줄 수 있다.”와 같은 에픽이 추가될지도 모르겠다.
이와 같은 에픽들이 모이면 “태블릿과 클라우드 서비스를 통한 레스토랑 시스템”이라는 테마Theme가 완성된다.
스토리를 더 작은 단위의 일로 나누면 태스크, 더 세분하면 서브 태스크가 된다. 실제 애자일 팀에서 매일 아침에 모여 하는 스탠드업 미팅에서 다루는 일의 단위는 태스크나 서브 태스크인 경우가 대부분이다.
 

관리 도구 아닌 진행 도구가 필요하다

애자일 프로젝트의 진행 상황을 모니터하고 팀이 효율적으로 일할 수 있도록 하는 애자일 방법이 많이 개발되어왔다. 이 중 가장 흔하게 쓰이는 방법으로 ‘스크럼’과 ‘칸반’이 있는데, 서로 상충된 개념이 아니어서 둘을 섞어 쓰는 개발 팀도 종종 볼 수 있다.
데드라인에 맞추어 프로젝트를 진행하는 워터폴 방식에서는 관리자가 주어진 일을 개별 팀원에게 나눠주고 주어진 시간과 비용 안에서 해결하기 위해 개발된 ‘관리 도구’가 필요하다. 반면 애자일 방식의 도구들은 팀 전체가 일정한 속도로 제품을 생산하여 고객에게 효율적으로 가치를 전달하는 데 필요한 ‘진행 도구’로서 개발되어왔다.
스마트 워치는 그저 오늘의 운동량을 보여줌으로써 우리에게 점심 식사 후 ‘조금 걸어볼까?’ 하고 생각하게 만든다. 실적이나 성과를 개선하는 것은 상황을 숫자로 표현하는 것에서 출발한다. 스크럼이든 칸반이든, 애자일 도구에서의 성과 측정은 개인의 성과보다 ‘고객에게 전달될 가치를 전체 팀이 전달하고 있는 속도’를 표현하는 데 초점이 맞추어져 있다. 어떤 팀원의 ‘소극적 참여’로 팀 전체의 성과가 영향을 받을 때 매니저의 압박보다는 같이 일하는 팀원들의 압박이 긍정적인 결과를 가져오는 경우가 많다.
 

스크럼

애자일 스크럼 팀의 일상을 들여다보면 팀원들은 자신에게 할당된 태스크를 혼자서 묵묵히 해나간다.
애자일 보드에서 티켓을 하나 골라서 자신에게 할당하거나 이미 자신에게 할당된 티켓을 ‘진행 중’In Progress으로 옮겨놓고 일을 진행한다. 자신의 일을 마치고 나면 ‘리뷰’Review로 옮겨놓고, 리뷰가 끝나면 ‘완료’Done로 옮긴다. 2주에 한 번 정도 스프린트를 반복하며 스프린트 단위의 미팅, 그리고 매일 한 번씩 있는 스탠드업 미팅에 참여하는 것 외에는 혼자서 일한다.
기본적으로 다른 팀원의 진행 상황과 상관이 없어 남들과 같은 시간에 일할 필요가 없다. 그래서 출퇴근 시간도 자유롭고, 집에서 일해도 되며, 휴가도 마음대로 갈 수 있는 시스템이 가능하다.
이렇게 차분한 개발 조직이지만, 애자일 정신에 따라 고객에게 가치를 전달하는 최소 단위인 스토리를 팀이 함께 만들어낸다는 의미를 담기 위해 ‘스크럼’이라는 표현을 사용한다. 풋볼 경기에서 달리기를 잘하는 한 사람이 아무리 빨리 달려도 공을 던지는 사람과 호흡이 맞지 않아 점수를 내지 못하면 아무 소용없는 것처럼 엔지니어와 매니저와 UX 디자이너 등 모든 팀원이 각자의 역할을 잘 수행하여 고객이 사용할 수 있는 완결된 스토리를 만들어내지 못하면 스프린트는 아무 성과가 없는 것이나 마찬가지이기 때문이다.
    
스토리포인트 예측 미팅

스크럼을 진지하게 사용하는 팀에서는 예측 미팅을 따로 가지기도 한다. 팀 전체가 모여서 스토리들을 늘어놓고 각 스토리마다 ‘스토리포인트’Storypoint라고 하는 단위로 일의 크기를 매기는 자리다.
각 스토리가 얼마나 시간이 걸리는지를 예측하기 위해 포커와 비슷한 게임을 한다. 각 팀원은 1, 2, 3, 5, 8, 13, 20, 40, 100과 같은 피보나치수열과 비슷한 단위의 숫자가 적힌 카드를 가진다. 그리고 한 스토리의 사이즈에 대한 카드를 제시한다. 5명이 모여 투표했는데 3명이 2라고 하고, 1명이 8, 1명이 1이라고 했다면 8이라고 한 사람, 1이라고 한 사람의 의견을 들어보고 다시 한 번 투표한다. 이렇게 해서 수렴된 숫자로 스토리포인트를 매긴다.
만약 팀 전체가 최근 진행된 스프린트에서 50스토리포인트를 한 스프린트에 전달할 수 있었다면, 그 팀의 애자일 속도는 50이 된다. 다음 스프린트에 그만큼의 스토리를 전달할 수 있도록 노력하자고 약속하는 것이다.

 
스프린트 계획 미팅

1~2주에 한 번, 한 시간 정도 스프린트 계획 미팅을 갖는다. 스프린트 계획 미팅에서는 앞의 스토리포인트 예측 미팅에서 점수를 할당한 스토리들을 가지고 다음 스프린트 동안 어떤 스토리들을 처리할지 계획한다.
스토리보다 큰 그림인 에픽을 생각하면서 스토리의 우선순위를 정하는 것이 가장 이상적이다. 그렇지만 기존 프로젝트의 버그 해결이나 유지·보수 등 에픽에 해당하지는 않지만 꼭 필요한 일도 있으므로 우선순위는 그때 그때 변할 수밖에 없다.
스프린트 계획 미팅에서 누가 각 스토리 티켓을 수행할지 정하는 경우도 있고, 아니면 지금까지의 팀 속도(스프린트당 수행한 스토리포인트의 합)를 고려하여 스토리만 추가해놓고 스프린트 진행 중에 자신이 원하는 스토리 티켓을 선택하여 수행하기도 한다.

 
스탠드업 미팅

스탠드업 미팅은 각자가 선택한 태스크의 상황을 팀에게 이야기하고, 진행이 더딘 경우에는 어떠한 도움이 필요한지 설명하는 자리다. 이때 프로젝트 매니저나 팀원들 중 하나가 스크럼 마스터 역할을 맡아 회의를 진행한다. 스크럼 마스터 역할은 보통 돌아가면서 맡는다.
전통적인 생산관리 담당자처럼 ‘어제 하기로 한 것을 하지 못했으니 오늘 저녁은 늦게까지 일해야 할 것’과 같은 압력을 넣는 방식이 절대 아니다. 제품을 사용하는 고객의 문제를 우선적으로 해결하느라 개발 태스크를 소화못 하는 일도 흔하기 때문에, 어느 정도 예측에 어긋나는 것은 이미 팀의 애자일 속도에 포함되어 있어야 한다. 다만 다른 팀의 누군가(보통 DBA와 같은 제한된 리소스)의 도움이 필요하다든지 등의 일은 프로젝트 매니지먼트 팀을 통해 신속히 해결해야 한다.
 

스탠드업 미팅의 특징
1. 아침에 한다. 너무 늦을 경우 하루가 짧아지거나 학교에 다니는 아이가 있는 팀원들이 손해를 보고, 너무 이를 경우 참석률이 좋지 않다. 매니저급일수록 아이가 있을 확률이 높다는 것이 함정이다.
2. 어제 한 일, 오늘 할 일을 말하고, 진행을 막는 일이 있다면 누구의 도움이 필요한지 이야기한다.
3. 10분을 넘기지 않는 것이 원칙이다. 이를 위해 서서 진행한다.
4. 중간중간 소멸 차트Burndown Chart를 보며 서로 약속한 스토리들을 이번 스프린트가 끝날 때 전달할 수 있을지 체크한다.

스프린트 리뷰 미팅

스프린트 리뷰 미팅은 지속적인 개선이라는 관점에서 매우 중요하다. 이 미팅을 통해 스토리가 전달된 과정을 점검하고, 만약 전달되지 않은 스토리가 있다면 다음 스프린트에서 어떻게 약속을 더 잘 지킬 수 있을지 검토한다. 만약 팀의 애자일 속도가 점점 빨라진다면 아마도 스프린트 리뷰 미팅을 팀원들이 정직하고 성실하게 했기 때문일 것이다. 각각의 부품을 만들어낸 팀원들이 완성된 스토리들의 데모를 보며, 지난 스프린트에서 열심히 일한 결과를 축하하는 자리이기도 하다.
스프린트 리뷰에서는 간단히 공유 문서를 열어 잘된 점, 잘못된 점, 개선책을 적는다. 잘된 점은 함께 기뻐하고 축하하며, 잘못된 점은 함께 개선책을 논의한다. 그리고 개선책을 정리해서 다음 스프린트는 더 효율적이고 좋은 업무 경험이 될 수 있도록 노력한다.
 

칸반

일본어인 ‘칸반’에 해당하는 우리말은 ‘간판’이지만, 뜻은 ‘게시판’에 가깝다.
도요타에서 생산 운영의 효율화를 위해 게시판을 활용해서 만들어낸 기법이다. 왼쪽은 원재료, 오른쪽은 모든 공정이 끝난 제품을 표시함으로써, 그 사이에 일어나는 공정들에 재료가 얼마나 투입되고 있는지를 쉽게 표현할 수 있다.
칸반 방식에서는 스프린트를 나누지 않는다. 일이 새로 들어오면 백로그Backlog에 쌓고, 맡은 일을 다 한 사람이 백로그에 있는 일 중 하나를 선택해서 수행한다.
도요타의 유명한 ‘저스트인타임Just-in-Time 운영 방법’에 따라 현재 진행 중인 티켓 수를 제한하는 것이 칸반의 핵심 개념이다. 1일 생산량이 1만 대가 넘는 도요타의 경우, 원재료가 공장에 들어와 완제품이 될 때까지 시간을 소요할수록 더 많은 비용이 들기 때문에 이에 대해 고심하다 만든 방법이다.
동시에 진행할 수 있는 일의 수를 제한해버리면 전체 효율이 올라간다는 것이 핵심이다. ‘군더더기를 뺀다’는 의미로 린Lean 방법이라고도 부른다.
소프트웨어 개발에서 동시에 진행 중인 태스크의 숫자를 제한하면 팀이 적은 수의 일에 집중하도록 유도할 수 있다. 애자일 팀에서 동시에 처리하는 태스크가 너무 많으면 결과적으로 완료하는 시간이 점점 늦어져 고객에게 빠르게 가치를 전달하는 애자일 개념에 어긋나게 된다. 스크럼에서 애자일 속도에 따라 스프린트를 통해 약속할 수 있는 스토리포인트를 제한하는 것도 이와 같은 맥락에서다.
스크럼에서 스프린트가 진행 중인 상황에서 어떤 엔지니어가 자신의 태스크를 일찍 끝냈다면 다른 엔지니어가 맡은 일을 도와주는 등 약속한 스토리를 고객에게 전달하는 데 최선을 다할 것이다. 칸반에서는 일을 끝냈을 때 다른 사람의 일을 도와주기보다는, 프로젝트 매니저와 상의해 백로그에 있는 다른 태스크를 맡는 것이 자연스럽다.
칸반에서는 사이클 안에 정해진 스토리포인트를 태우는 소멸 차트보다는, 태스크들이 백로그에서 완료Closed 상태가 될 때까지 걸리는 시간에 대한 콘트롤 차트Control Chart를 사용해 팀 개발 프로세스의 이상 징후나 문제가 있었던 태스크에 대한 대응책을 마련할 수 있도록 한다.  

스크럼 vs 칸반

스크럼이나 칸반 모두 애자일 프로젝트의 진행 방법으로 자리를 잡아가면서 많은 소프트웨어 도구들이 만들어지고 있지만, 어떤 도구와 어떤 방법론을 언제 사용해야 하는지는 팀 스스로가 결정해야 한다.
스크럼은 ‘이미 익숙한 일들을 해내는 전문가들’이 모여 고객에게 의미 있는 분량의 제품 업데이트를 제공하기에 적합하다. 사용하는 프로그래밍 언어와 라이브러리가 이미 친숙한 상태에서 프로덕트 매니저가 정리해둔 스토리를 하나씩 태스크로 나누어 만들어가는 과정이라면, 각 태스크의 스토리포인트에 대해 크게 의견이 갈리지 않을 것이다. 제품 시험 과정을 자동화하는 것을 포함한 모든 태스크를 한 스프린트로 마치는 것은 상당한 팀워크를 요한다.
잠재 고객은 있지만, 상당한 리서치를 요하는 제품을 개발할 때는 상황이 조금 다르다. 제품을 만들 때 쓸 기술 자체를 함께 개발해야 하는 경우에는 스프린트를 통해 고객에게 전달할 수 있는 의미 있는 분량의 스토리를 만들기가 힘들기 때문이다. 이때는 연구 과제를 포함한 태스크들을 세분화하고, 이들의 진척 상황을 꾸준히 관찰할 수 있는 칸반이 적합하다.
스토리포인트로 업무 부담이 정확히 관리되는 환경에서, 개개인은 자신만의 업무 속도를 쉽게 알 수 있다. 어떤 사람은 빠르고 어떤 사람은 느릴 것이다. 스크럼 마스터의 역할은 각자가 일하는 속도를 반영하여 계획을 세우고 프로젝트를 수행하는 것이다. 어떤 팀원이 일하는 속도가 너무 느리다고 해서 혼내거나 벌을 주는 경우는 없다. 다만 팀원의 업무가 전체 속도에 지장을 주는 일이 반복될 경우 3개월여의 공식적인 절차인 업무 개선 프로그램Performance Improvement Program을 거치게 된다. 그리고 이 기간 동안 업무 속도가 팀에서 필요한 만큼 개선되지 않으면 해고된다. _Aiden(송창걸)

이 포스트는 『실리콘밸리를 그리다 : 일하는 사람이 행복한 회사는 뭐가 다를까』에서 발췌, 재정리한 것입니다.