35. 상품관리자가 유의할 애자일의 원칙

성공적인 소프트웨어 신상품 개발가이드

아래 열두 가지 애자일 원칙은 애자일 선언을 뒷받침하는 원칙이다. 이 중 몇 개를 제외하고는 실천이 어려울 뿐 애자일이 아니라 소프트웨어 공학의 원칙이라 불러도 될 만큼 교과서적인 이야기이다. 신상품 개발 관점에서 애자일 원칙을 살펴보면 다음과 같다.    

- 우리는 가치 있는 소프트웨어를 빠르고 지속적으로 전달하여 고객을 만족 시키는 것을 최우선으로 한다. 

모든 기업이 알고 있는 상식과 같은 내용이다. 가치 있는 상품을 고객에게 빨리 전달하면 고객은 만족할 것이다. 그것을 지속적으로 수행할 수 있는 체계를 갖춘 기업만이 지속적인 성장을 할 수 있다. 그러나 안타깝께도 주주가치 제고에 집중하는 기업이 의외로 많다. 주주가치를 중시하는 경영층을 위해 일하는 직원에게 높은 수준의 동기부여를 기대하기 힘들다. 주주가치 중심과 고객중심의 조직문화에 대해선 13장을 참조하기 바란다. 

- 비록 개발 후반부일지라도 요구사항 변경을 기꺼이 환영한다. 애자일 방법론은 고객의 경쟁력 우위를 위해 변화를 원동력으로 사용한다. 

변경을 좋아하는 사람은 기저귀가 젖은 아기밖에 없다는 말이 있다. 현실에서 프로젝트 후반부 요구사항 변경은 재앙에 가깝다. 상품개발팀이 요구사항 변경을 꺼리는 이유는 요구사항 변경으로 피해를 보기 때문이다. 피해의 구체적인 내용은 잔업이 늘어나는 것과 품질이 낮아져 개발자의 자긍심에 상처를 입는 것이다. 따라서 상품개발팀은 살아남기 위해 변경을 재앙처럼 인식하고 변경예방에 집중한다. 상품개발팀이 변경을 예방하기 위해 변경을 최대한 까다롭게 하면 고객 또는 내부 이해관게자는 없어도 되고 있으면 좋은 (nice to have) 요구사항을 상품기획서에 최대한 반영한다. 그 결과 검토가 미흡한 요구사항이 요구사항 변경을 초래하는 악순환으로 이어진다. 상품개발팀을 믿고 존중하는 조직문화의 구축 없이 상품개발팀이 요구사항 변경을 환영할 것을 기대해서는 안된다.  

‘린’과 ‘애자일 방법론’은 필요한 변경은 빨리 저렴한 비용으로 실행하고, 불필요한 변경은 최소화하기 위한 많은 기법들을 제공한다. 

- 동작하는 소프트웨어를 2주에서 2개월 주기로, 가능한 더 짧은 주기로 인도한다. 

짧은 주기는 개발주기와 릴리즈 주기로 나누어 생각할 수 있다. 개발주기는 이터레이션과 같이 특정 기능의 개발 및 검증 기간을 의미하고 릴리즈 주기는 출시주기를 의미한다. 개발주기와 릴리즈 주기가 같은 것이 이상적이지만 다를 수도 있다. 예를 들어 6개월 주기의 릴리즈를 위해 2주 개발주기 12개를 수행할 수 있다. 짧은 개발주기를 적용하면 결함이나 잘못된 아키텍처를 조기에 발견하여 적은 비용으로 수정할 수 있고, 짧은 릴리즈 주기를 적용하면 고객 관점에서 잘못된 요구사항을 빨리 확인할 수 있다. 

릴리즈는 너무 자주해도 고객의 불만을 초래 할 수 있다. 무엇이 변경되었는지도 모르는데 ‘업데이트 사항이 발생했습니다.’라는 모바일 앱의 잦은 메시지는 고객을 불편하게 만든다. 짧은 릴리즈 주기는 고객 관점에서 ‘가치 있는 소프트웨어’를 전제로 할 때 의미 있다. 결함 수정을 위한 업데이트라 할지라도 고객이 가치를 느끼지 못하는 잦은 릴리즈는 고객을 불편하게 만들 수 있다. 

짧은 개발주기는 상품개발팀의 관점에서는 개발주기 동안은 추가 요구사항을 받지 않는 장점이 있다. 예를 들어 2주의 개발주기를 적용하고 있다면 2주 동안은 추가요구사항을 받지 않을 수 있다. 길어야 2주이니 다음번에 반영할 예정이니 고객에게 기다려달라고 요청할 수 있다. 

- 프로젝트 기간 내내 개발자들은 사업에 관련된 사람들과 매일 함께 일해야 한다. 

상품기획, 상품개발, 디자인, 품질인력은 프로젝트 시작부터 끝까지 한 장소에서 근무하는 것이 좋다. 그러나 대부분의 조직에서 인력운영의 효율성 때문에, 상품개발 초기의 품질인력, 상품개발 마지막 단계의 상품기획 인력 투입을 기피한다.    

상품관리자는 상품개발을 착수하면 다음 버전 상품기획을 준비하느라 여력이 없을 수 있다. 그래도 상품관리자는 여러 이해관계자들이 함께 일하는 시간을 늘리도록 노력해야 한다. 그것이 상품 성공의 가능성을 높이는 확실한 방법이다.   

- 동기 부여된 개인들로 프로젝트를 구성하라. 그들에게 필요한 환경과 지원을 제공해주고, 업무를 완료할 것이라 믿어라. 

상품개발팀이 업무를 수행할 때 장애물을 제거하고 필요한 지원을 하며 상품개발팀을 동기부여시키는 것은 상품관리자의 책무이다. 그러나 과정과 절차는 신뢰하고 일임하되 결과에 대해선 디테일하게 확인해야 한다. 

- 개발팀 내부에서 정보를 전달하고 공유하는 가장 효율적이고 효과적인 방법은 직접 얼굴을 보면서 대화하는 것이다. 

전자메일과 메신저의 활용 빈도가 높아지고 있지만 의사소통의 질은 대면대화에 비할 바가 아니다. 바로 옆자리 동료와도 메신저로 소통하느라 키보드 소리만 나는 조용한 사무실에서 훌륭한 상품이 나올 것이라 기대하기는 힘들다. 대면소통 없이 협업 툴에만 의존해서는 정보공유 이상을 기대하기 힘들다. 화상회의 툴을 활용하면 대면소통보다 회의가 빨리 끝나는 이유가 이 때문이다. 대면소통을 해야 마음속의 이야기를 편하게 할 수 있다. 시간이 지나 화상회의 툴이 대면회의만큼 편해지는 시기가 올 수 있지만 중요한 의사소통은 직접 얼굴을 보면서 해야 한다.  

《애자일 개발과 스크럼》(2014)에서는 대면방식의 의사소통을 다음과 같이 강조하고 있다.  

두꺼운 사양서를 벽 너머로 던져서 정보를 전달하던 폭포수형 방식에 존재하던 벽을 허물고, 하나의 프로젝트를 만들어 얼굴을 맞댄 채 의사소통 하여 정보를 전달하면서 문제를 해결해 나가는 것이 애자일 개발의 핵심이다. 

- 동작하는 소프트웨어가 진척 상황을 측정하는 가장 중요한 척도이다. 

문서가 아닌 동작하는 소프트웨어를 기준으로 프로젝트 진척률을 파악해야 한다. 상품관리자나 경영층이 궁금해 하는 정보 중 하나가 ‘동작하는(품질을 확보한) 소프트웨어 기준의 진척률’이다. 동작하는 소프트웨어 기반의 진척률은 상품개발팀을 질책할 때 활용하는 것 보다 동기부여 할 때 활용하면 더 큰 효과가 있다. 

- 애자일 방법론은 지속할 수 있는 개발을 장려한다. 후원자, 개발자, 사용자는 일정한 속도를 계속 유지할 수 있어야 한다. 

신상품 개발 업무를 정해진 일정에 규칙적으로 수행하면, 계획수립에 대한 부담을 없애준다. 예를 들어, 매월 마지막 주에 다음달에 릴리즈할 기능을 정의하고, 매월 첫 주에 그 달에 출시할 기능에 대한 개발계획을 수립하고, 매주 금요일 오후에 진행 현황을 리뷰하고 매월 마지막 주에 그 달에 완료한 기능을 리뷰하는 식이다. 반복적인 업무를 정해진 시점에 수행하면 조직내 업무 리듬 또는 루틴이 정착된다.

업무 루틴이 정착되면 일정한 업무수행 속도를 지속할 수 있다. 업무수행 속도는 ‘업무의 양’과 ‘업무 수행기간’이 결정하는데 속도를 유지하기 위해서는 업무의 양보다 업무 수행기간을 우선해야 한다. 다시 말해 목표한 기능을 모두 개발하지 못해도 정해진 일자에 릴리즈를 해야 한다. 기차가 탑승 손님과 무관하게 정해진 시간에 출발하는 것과 같다. 

이런 루틴은 마라톤을 달리는 것과 비슷하다. 아주 짧은 기간 속도를 높이는 것은 가능하지만, 평소 근무시간은 큰 차이가 없어야 한다. 잔업의 빈도와 강도에 편차가 많을수록  ‘지속 가능한 속도’를 유지하기 어려워진다. 잔업의 빈도와 강도가 높아질수록 상품의 품질은 낮아지고 개발속도는 느려진다.

- 기술적 탁월함과 좋은 설계에 대한 끊임없는 관심은 기민성을 강화시킨다. 

개발자의 생산성은 사람에 따라 10배 이상 차이가 난다. 개발자 역량을 높이기 위해 짝 프로그래밍(pair programming)을 하거나 회사 내에서 코드를 개방하고 공유하기도 한다. 가치를 제공하는 것은 기술이다. 기술의 뒷받침 없이 말로만 기민할 수는 없다. 상품관리자는 실력 있는 엔지니어를 알아볼 수 있어야 하고, 우수 인력을 프로젝트에 투입하기 위한 노력을 아끼지 말아야 한다.     

- 안 해도 되는 일을 최대한 하지 않는 단순함이 핵심이다. 

안 해도 될 일을 하지 않는 것도 중요하지만 단순한 것을 복잡하게 만들어도 안 된다. 요구사항이나 사용자 인터페이스를 단순하게 유지하는 것은 상품관리자와 UX 디자이너의 책임이다. 상품기능을 최소한으로 유지하는 것이 단순함 유지의 핵심이다. 

- 최고의 아키텍처, 요구사항, 설계는 자기 조직화 팀으로부터 나온다. 

자기 조직화 팀은 팀이 계획하고, 의사결정하고, 실행한다. 팀이 수행하는 모든 일은 팀이 결정한다. 자기 조직화 팀은 각자의 역량도 필요하지만 앞에서 설명한 상품개발팀에 대한 신뢰와 존중을 전제로 한다. 따라서 자기 조직화 팀은 현실에서 구현이 매우 힘들며 상품관리자나 프로젝트관리자가 어떻게 할 수 있는 문제가 아니다.  

- 팀은 정기적으로 더 효과적으로 일할 수 있을지를 돌아보고, 이에 따라 행동방식을 조율하고 조정한다. 

팀이 수행할 프로세스를 팀이 결정하게 하면 과거 수행했던 프로세스 경험에서 개선점을 도출한다. 개선점을 적용하여 잘되는 것은 유지하고 보완사항은 다시 반영한다면 선순환의 프로세스 개선체계가 정착된다. 

기업에서 다른 팀과 완전히 독립적인 팀은 존재하지 않는다. 자율은 다른 조직과의 긴밀한 협업을 전제할 때 의미가 있다. 예를 들어 대규모 상품을 개발하는 팀이 N개 있을 때 각 팀이 각자 자율만 추구하면 엄청난 혼란이 있을 것이다. 특히 팀과 팀 간의 업무 의존관계(선행작업/후행작업), 공통 표준은 자율로 결정해서는 안 된다.

지금까지 네가지의 애자일 선언과 열두가지의 애자일 실천원칙을 살펴보았다. 애자일 선언, 애자일 원칙, 애자일 프랙티스의 관계는 아래  그림과 같다.