대규모 상품개발팀에 애자일 적용시 유의사항
대규모 소프트웨어 상품개발을 위한 팀원은 100명을 넘어 500명, 1,000명까지 필요할 수 있다. 대규모 상품개발에 애자일을 적용할 때는 ‘의사소통의 복잡성’에 특히 유의해야 한다. 의사소통의 복잡성을 줄이기 위해서는 ‘착수전 준비’, ‘개발팀 간 협업 강화’, ‘적절한 통제제도 운영’가 필요하다.
① 착수전 준비
조직의 성숙도가 낮은 상황에서 높은 수준의 애자일 프랙티스를 적용하면 상품개발이 실패할 가능성이 높다. 1개의 군함을 N개의 쾌속정으로 바꾸긴 했지만 쾌속정이 자율적으로만 움직일 뿐 목표방향을 상실한 것과 같다.
대규모 프로젝트는 어떤 방법론을 사용해도 난이도가 높다. 따라서 조직이 애자일을 적용할 준비가 되지 않았다면, 대규모 상품개발을 위해서는 상품개발팀이 익숙한 방법론을 적용하는 것이 좋다. 익숙한 방법론을 적용하여 실패하면 적어도 내부 갈등은 최소화 할 수 있다. 왜냐 하면 대규모 프로젝트는 목표달성이 힘들다는 것을 알고 있기 때문이다. 그리고 결과가 실망스럽고 몸이 고달프고 비용은 초과해도 모든 프로젝트는 끝이 있다는 희망으로 버틴다. 그러나 애자일을 적용하여 대규모 프로젝트가 실패하면 애자일이 희생양이 되고 정치게임으로 이어질 가능성이 높다.
애자일을 적용하는 대규모 프로젝트의 성공 가능성을 높이기 위해서는 다음과 같은 전제조건이 필요하다.
• 상품개발과 관련된 조직 모두가 애자일 적용경험이 있다.
• CEO가 전사차원의 애자일 적용을 후원한다.
• 상품개발팀은 이전에 같이 일해본 경험이 많고 팀웍이 좋다.
• 상품관리자와 개발팀 리더는 애자일의 가치를 이해하고 애자일 적용경험이 있다.
대규모 상품개발 프로젝트에 애자일을 적용하기로 했으면 복잡도가 증가할 가능성을 최대한 줄여야 한다. 복잡도를 줄이는 활동은 다음과 같다.
- 상품 컨셉에 대해 내부 이해관계자의 공감대를 확보한다.
개발착수전 상품 컨셉에 대한 내부 이해관계자(특히 경영층)의 공감대는 필수적이다. 상품개발 과정에서 내부 이해관계자가 상품컨셉에 대해 이견을 제시하면 큰 혼란을 초래한다. 외부 고객을 대상으로 고객가치에 대한 검증도 수행했다면 더욱 좋다.
- 신상품 개발에 적용할 기술 아키텍처 리스크를 확인하고 조치한다.
상품개발을 진행하면서 기술 아키텍처 문제가 발생하거나 아키텍처를 변경하지 않도록 사전에 기술 아키텍처의 적정성을 검증하고 문제점을 조치한다.
- 상품개발팀이 지켜야 할 규칙(Ground rule)을 확정한다.
고속도로에서 교통의 흐름에 따라 차량을 자율적으로 운행 할 수 있지만 모든 운전자가 준수해야 할 규칙이 있다. 대규모 애자일 개발도 마찬가지이다. 각 스크럼팀의 자율성을 최대한 보장하지만, 모든 스크럼팀이 지켜야 할 규칙이 있다. 예를 들어 개발언어, 빌드주기, 개발도구, 스프린트 주기, 작업완료 기준은 상품개발팀원 모두가 준수해야 한다. 단, 상품개발팀이 지켜야 할 규칙은 외부에서 지시하는 것이 아니라 내부에서 협의를 통해 결정하는 것이 좋다.
- 복수의 스크럼 또는 전체 스크럼에 해당되는 이슈가 발생할 때 이를 조정하는 리더를 지정한다.
애자일에서는 ‘관리자’란 단어를 싫어한다. 명칭을 관리자로 하던 리더로 하던 여러 스크럼에 공통된 이슈가 발생할 때 이를 조율할 수 있는 사람을 지정해야 한다. 관련된 스크럼이 많을수록 전문적인 역량을 가지고 최종 결정을 내릴 수 있는 사람이 필요하다. 팀간 조율이 필요한 영역은 ‘상품 요구사항’, ‘기술 아키텍처’, ‘프로젝트 관리’이다. 상품관리자는 전담인력 이지만 기술리더와 프로젝트 리더는 평소 다른 업무를 수행하면서 이슈 발생시 이를 조율하는 업무를 수행 할 수 있다. 아래 세가지 유형의 이슈를 조정하는 리더의 책임과 역할, 권한은 애자일 성숙도에 따라 다르다.
• 상품 요구사항의 우선순위와 범위를 조율할 상품관리자 지정
동일한 상품에 대한 요구사항은 한 명의 상품관리자가 전체를 총괄해야 한다. 상품관리자는 N개의 스크럼에 속한 상품책임자(Product Owner)와 협의하여 상품 요구사항의 범위와 개발 우선순위에 대한 최종결정을 내린다. 개별 스크럼의 상품요구사항은 상품책임자가 관리한다.
• 기술 인프라, 아키텍처 이슈를 조율할 기술리더 지정
프로젝트 착수 이전에 아키텍처 적합성을 검증했지만 프로젝트 진행도중 기술이슈가 발생 할 수 있다. 전체 프로젝트 관점에서 기술이슈를 조율할 기술리더를 사전에 정해야 한다.
• 스크럼간 업무 의존성 이슈(예: 일정)를 조율할 프로젝트 리더 지정
스크럼간 업무 의존성을 사전에 파악하고 이슈 발생시 해결하는 것은 대규모 상품개발의 복잡성을 관리하는 활동이다. 간단한 이슈는 스크럼 실무자간 협의 또는 ‘전체 스크럼 미팅 (scrum of scrums)’을 통해 해결 할 수 있지만 스크럼간 의존성 이슈가 자주 발생하거나 해결이 지연되면 프로젝트 리더가 이슈 조기해결을 위해 조정역할을 수행해야 한다. 전통적인 프로젝트 관리자는 톱 다운으로 계획을 지시하고 이행을 모니터링 했지만, 애자일을 적용하는 프로젝트 리더는 스크럼팀의 자율적 결정을 존중하고 예외적인 이슈를 조정하는 것이 좋다.
- 고객중심으로 의사결정 하는 조직문화를 구축한다.
모든 스크럼팀은 고객중심으로 판단하고 의사결정 해야 한다. 내부 조직의 이해관계를 고려하면 의사결정이 어려워지고 팀간에 건전하지 못한 갈등이 발생한다. 고객중심으로 의사결정 하는 문화를 구축하는 것은 쉽지 않다. 경영층이 적극적으로 지지하고 솔선수범해야 가능하다. 고객관점에서 판단하고 의사결정 하면 느릴 수는 있어도 잘못될 가능성은 낮고, 상품개발팀 내부 정치활동도 줄어든다.
② 개발팀간 협업 강화
대규모 상품개발팀에서는 내가 속한 팀보다 전체 팀 관점에서 의사결정 하는 것이 중요하다. 팀 관점의 의사결정을 촉진하기 위해서는 개발팀간 협업을 강화해야 하며 그 방안은 다음과 같다.
- 전체 개발팀원을 가까운 장소에서 근무하게 한다.
오며 가며 다른 개발팀과 만날 가능성이 높아지면 의사소통도 증가하고 협업의 가능성도 높아진다. 한 층에서 모두가 근무하면 팀 전체가 참여하는 스탠딩 미팅도 가능하다. 상품개발 대쉬보드를 운영하는 것도 투명한 정보공유에 도움이 된다.
- 다른 개발팀과 업무를 협의하는 정기•비정기 회의체를 운영한다.
각 스크럼의 리더가 참여하는 전체 스크럼 미팅(scrum of scrums)이 정기 협의체의 대표적인 예다. 협의체 명칭은 ‘개발팀 리더 협의회’와 같이 일상적인 용어를 사용해도 무방하다. 특정 이슈 발생시 일부 팀의 관련자만 참석하는 비정기 회의체 운영도 활성화 시켜야 한다.
- 스프린트 계획은 2단계로 나누어 운영한다.
1단계 스프린트 계획은 각 스크럼을 대표하는 상품책임자가 참석하여 전체 프로젝트의 스프린트 계획을 의논한다. 1단계 스프린트 계획에서는 상품관리자가 상품책임자들과 협의하여 스크럼팀들이 해당 스프린트에서 구현할 상품요구사항을 확정한다. 상품레벨의 통합 백로그 관리는 상품관리자의 책임이다.
2단계 스프린트 계획은 스크럼팀별로 운영하며 일반적인 스프린트 계획과 동일하다. 상품개발팀내 모든 스크럼팀은 동일한 스프린트 일정과 주기를 적용해야 한다. 스크럼팀들은 모든 스프린트를 같이 시작하여 같이 종료해야 한다. 스크럼팀별 백로그 관리는 상품책임자의 책임이다.
조직에 따라 상품관리자를 상품책임자, 상품책임자를 영역별 상품책임자(Area Product Owner)라고 부르기도 한다.
- 스프린트 리뷰는 전체 스크럼팀을 통합하여 운영한다.
스프린트 리뷰는 해당 스프린트에서 개발한 소프트웨어가 제대로 작동하는지 확인하는 내부 시연활동이다. 모든 스크럼팀을 통합한 스프린트를 리뷰를 운영해야 팀간 인터페이스가 제대로 동작하는지 확인 할 수 있다. 회고는 스크럼 팀별로 운영해도 무방하다. 또한 스프린트 리뷰는 동영상으로 제작하여 이해관계자들에게 공유하는 것이 바람직하다.
스프린트 계획과 스프린트 리뷰에 대한 내용을 정리하면 그림 *와 같다.
대규모 상품개발시 스프린트 계획과 스프린트 리뷰, 출처 LeSS(Large Scale Scrum) 프레임웍 https://less.works/less/framework/index.③ 적절한 통제제도 운영
대규모 상품개발시 팀간 협업이 미흡하여 발생하는 품질문제는 조기에 파악하고 조치해야 한다.
- 전체 통합 빌드를 운영한다.
상품개발은 동일 브랜치(Branch)내에서 작업하는 것을 원칙으로 한다. 정기적으로 모든 소스코드를 통합하여 빌드하는 활동을 통해 품질이슈를 조기에 발견해야 한다. 전체 소스코드를 통합하는데 시간이 오래 걸릴수록 심각하고 고치기 힘든 품질오류가 발생할 가능성이 높다.
- 품질오류가 일정수준 이상이면 품질부터 안정화 한다.
품질을 확보하지 않은 상태에서 개발을 지속하면 문제 해결을 위한 품질비용이 높아진다. 통합빌드에서 오류가 일정수준 이상이면 개발범위를 줄이더라도 품질부터 안정화 시킨다. 품질오류의 목표는 개발인원당 특정 수로 정하는 것이 좋다. <The age of agile, 2018>에서는 개발자당 4개를 권고한다.
https://brunch.co.kr/@kbhpmp/160
