4장. 애자일 전환#2
#4-2 애자일 방법론
#4-2 애자일 방법론
* 엔터프라이즈 애자일 방법론 만들기
애자일 방법론을 만들기 위해 전사 TF가 만들어졌다. 회사에서 방법론 관련하여 잔뼈가 굵은 전문가들이 합류했다. 이들은 스크럼과 XP에 대해 꼼꼼하게 공부했다. 각종 출판된 책을 읽고, 서로 토의했다. 그리고 당시 시장에서 활용된 사례들을 모았다.
[애자일 프로세스 관련 만화]하지만, 걱정은 점점 커졌다. 애자일에 대해 알게 되면 알게 될수록 답답함을 느꼈다. 방법론으로 만들기에는 무엇인가가 부족했기 때문이다. 방법론은 프로젝트를 수행할 때 어느 단계에 어떠한 역할자가 무슨 일을 해야 하고, 그것의 입력물과 결과물이 무엇인지를 정확히 설명해야 한다. 하지만 스크럼, XP에는 그런 내용이 부족했다. 심지어 주로 마인드셋 위주의 설명이 대부분이었다.
일반적으로 방법론에서는 요구정의, 분석, 설계, 개발, 테스트 이렇게 5단계를 말한다. 하지만 스크럼과 XP는 설계 및 개발 단계 이외에는 다루지 않았다. 스크럼은 ‘스프린트’라고 명명한 이터레이션 동안 무슨 액티비티들을 수행해야 하는지에 대한 관리 기법 또는 팀 운영에 대한 이야기만 있었다. XP는 엔지니어링 기법들 하나하나는 훌륭했지만, 이를 전체 프로젝트에 어느 단계에 어떻게 녹여야 되는지에 대한 설명이 부족했다. 조각난 파편으로 보였다.
이 프로세스를 기반으로 방법론을 만들게 되면, 요구사항을 어떻게 줄 것인지 패키징을 어떻게 하고 고객에게 딜리버리 하기 전 전체적인 테스트는 어떻게 할 것인지, 아키텍처는 언제 어떻게 만들 것인지 등에 대한 고민이 별도로 해야 하는 상황이었다. 이를 전체 엮을 수 있는 틀이 필요했다.
[스크럼 프로세스]여러 날의 리서치를 통해 팀은 DaD(Disciplined Agile Delivery)라는 프로세스를 찾았다. DaD는 스캇 엠블러라는 컨설턴트가 정의한 엔터프라이즈 애자일 프로세스였다. 당시 스캇 엠블러가 IBM 래쇼날에 일하고 있었던 때라 명분도 좋았다.
'09년 당시 전 세계 최고 IT기업은 구글이나 페이스북이 아닌 IBM이었다. 당시 글로벌 회사에 벤치마킹을 가거나 할 때 IBM은 늘 목록의 가장 상단에 있었다. 심지어 IBM은 2008년 현재 그들 조직의 70% 이상이 모두 애자일 방식으로 개발한다는 리포트가 있었다. 이러한 문서는 주변을 설득할 때 꽤나 도움이 되었다.
DaD는 애자일에서 가장 많이 언급되는 프로세스인 스크럼과 XP가 중심에 있지만, 이 전후를 고객이나 대형 회사에 설명할 수 있는 프레임과 논리를 가지고 있었다 (이 프로세스는 스캇 엠블러라는 컨설턴트가 정의하고 현재까지 발전시키고 있다.)
사실 이 프레임과 논리 때문에, DaD는 당시 많은 애자일 전문가들로부터 비난을 받았다. 실천보다 틀만 제공한다는 비판도 있었다. '15년 이후 Scaled Agile Framework, Nexus, Less 등이 추가로 등장하면서 엔터프라이즈 애자일에 대한 접근이 자연스러워졌고, 회사마다 상황에 맞는 애자일 프로세스를 만들어 보유하고 있게 됐지만 '10년 당시는 그렇지 않았다. 이를 피하기 위해서였는지, 스캇은 이 프로세스를 하이브리드 애자일 방식이라고 소개했다.
이때부터 하이브리드 애자일이라는 말이 국내 시장에 널리 알려졌던 것으로 기억한다. 그리고 국내에서도 하이브리드 애자일이라는 말이 자주 등장하기 시작했다. 이는 SI 사업이 중심이었던 현실을 반영한 것이기도 했다. 애자일에 사상처럼 “필요한 만큼만” 요구사항을 처음에 정의하고 이터레이션을 돌며 이를 개선하기보다, 고객과 계약이 이루어질 시기 예산과 기간에 대해 확정하기 위해, 기능 리스트를 최초 정의하고 해야 할 양에 대해서 못 박은 다음 이터레이션을 통해 최소의 범위만 변경을 하는 형태로 애자일 활용이 필요했다.
심지어 현재까지도 하이브리드 애자일이라는 용어는 논쟁 속에 있으며, 이는 애자일을 더럽히는 방식이라는 것과 더 나은 애자일로 가기 위한 주춧돌이라는 설명이 대립되고 있다.
[현재까지도 하이브리드 애자일에 대해 논쟁 중인 애자일 얼라이언스 홈페이지]당시 회사는 리서치만으로는 부족하다고 판단했다. 방법론 전체를 설계하고 향후 경영진까지 함께 이야기할 필요가 있다고 생각했다. 때문에, 직접 스캇 엠블러를 한국에 초대하기로 했다. 그리고 그와 함께 애자일 전환에 대한 전체 전략을 수립했다.
* DaD
우리는 그의 조언과 함께 DaD 방법론에 대해 공부했다. DaD는 모든 단계에 이터레이션을 돌릴 수 있게 되어있었고, 크게 인셉션 > 개발 > 전환 > 상품화 4단계로 정의되어 있었다.
[DaD 초기 그림]인셉션 단계는 워터폴 방식의 요구정의와 아키텍처 설계를 포함하는 콘셉트이었다. 인셉션 단계에는 다음의 6가지를 한다.
만들 제품에 대한 비전을 세우고 공유한다.
초기 요구사항을 정의한다.
초기 팀을 구성한다.
러프한 릴리즈 계획을 세운다.
초기 아키텍처를 셋업 한다.
툴이나 사무실 등 프로젝트 환경을 구성한다.
DaD에서 추천하기에 인셉션 단계는 짧으면 짧을수록 좋다. 다만, 이 기간은 필요한 사람을 얼마나 빨리 구할 수 있는지, 조직이 얼마나 유연하거나 문서화를 필요로 하는지, 얼마나 팀이 커야 하는지에 따라 달라진다.
비전은 큰 요구사항 리스트, 기술적 이슈 그리고 위험 등을 사전에 식별하는 것이고, 초기 요구사항은 이와 관련된 것 중 가장 우선순위가 높은 15개 정도의 사용자 스토리를 작성하는 것부터 시작한다. 아키텍처는 시스템의 기술적 요구사항을 추정하고 스케줄링한다. 이때 아키텍처 다이어그램을 그리거나 화면 흐름 또는 컴포넌트를 식별하는 형태로 개념을 잡는다. 릴리즈 플래닝은 대략적 예산과 스케쥴링을 하고 향후 이터레이션을 통해 구체화하기로 한다. 그리고 이에 각각 맞는 제품/릴리즈 번다운 차트와 이터레이션 번다운 차트를 각각 셋업 한다.
[제품 번다운 vs. 이터레이션 번다운]컨스트럭션 단계에는 주로 설계/개발을 연속적으로 수행한다. 2~4주 단위로 이터레이션을 나누고 초기 작성한 사용자 스토리를 보다 구체화하여 개발을 수행한다. 그리고 매 이터레이션 종료 시 쇼케이스를 수행하고 회고를 진행한다. 사전에 정의했던 지표로 프로젝트 상태를 나타내고 제품 번다운 차트를 정의한 툴을 통해 업데이트한다.
그리고 전환 단계에는 컨스트럭션 단계와 길이 가 동일한 한 개 또는 두 개 정도의 이터레이션을 돌리며, 전체를 정리한다. 이를 통해 고객에게 전달될 기능들의 완전성을 다시 한번 검증한다. 그리고 제품화를 수행한다.
DaD 자체는 정말 잘 정리가 되어 있었다. 하지만, 우리는 이 DaD의 내용을 보다 한국 실정에 맞게 변환하는 것이 필요했다.
먼저, 사용하는 사람들을 위해 용어가 워낙 생소할 것이라 생각하여 용어를 조금씩 변경하는 것이 필요했다. 우리는 인셉션 대신에 요구정의란 용어를 사용했다. 그리고 이전 대형 프로젝트의 경험을 반영하여 요구정의 단계와 중첩되도록 아키텍처 단계를 추가했다. 이전의 대형 프로젝트 경험으로부터 반드시 선행되어야 하는 실행 아키텍처 구축 없이 개발을 시작하는 것을 막고자 했다.
우리는 이 내용을 기반으로 요구정의 > 아키텍처 > 구축 > 이행의 크게 4단계로 프로세스를 구성하고, 각각의 단계는 모두 이터레이션 기반으로 업무를 수행할 수 있게 했다. 또한 과거 워터폴 프로세스와 다르게 단계의 중첩도 허용했다. 그리고 “지속적인 개선"의 콘셉트에 맞게 이를 상속받아 업에 맞는 애자일 방식을 달리 구축해 낼 수 있도록 했다. 이러한 이유로 우리는 우리의 애자일 방법론을 Generic 애자일이라고 불렀다.
* 역할자의 정의
역할자들 또한 변화가 필요했다. 기본적으로 스크럼의 역할자들을 따랐는데, 그것은 제품 책임자, 스크럼 마스터, 개발자였다. 그들은 각각 백로그에 대한 책임, 팀의 병목을 해결하는 책임, 개발을 하는 책임을 나뉘어 가졌다. 우리는 스크럼에 없는 역할자 한 가지를 추가했는데, 그것은 아키텍트였다. 아키텍트는 구축이 시작되기 전, 개발을 수행하기 위한 사전 준비를 수행할 수 있도록 했다.
[스크럼의 역할자]그리고 산출물은 기존 워터폴에 비해 현저하게 줄였다. 사용자 스토리가 중심이 되어 문서는 필요한 만큼만 작성될 수 있도록 했다. 다만, 동작하는 제품을 통한 시연을 강조하여, 시연을 통해 제품의 피드백을 고객을 포함한 이해관계자들에게 받을 수 있도록 준비했다. 작성하는 문서의 종류만 해도 기존에 비해 절반 이하로 줄었다. 전통적인 산출물들이 보다 익숙한 인력들을 위해 산출물 매핑 표를 제시했다. 예를 들어 사용자 스토리는 비즈니스 설계서, 화면 설계서, 인터페이스 설계서를 대체할 수 있고 테스트 시나리오는 사용자 스토리의 인수 조건으로 대체할 수 있다고 했다. 이를 통해 기존과 어떻게 달라지는 지를 제시했다.
또한 애자일은 다양한 기법들을 상황에 따라 사용할 수 있는 것이 중요하기에 참조할 수 있는 지식들을 모아 제공하려고 했다. 스크럼과 XP의 스프린트 플래닝, 회고, 테스트 주도 개발, 리팩터링 같은 기법들 전체에 대해 정리를 시작했다. 이를 매뉴얼처럼 활용해 볼 수 있는 위키 형태를 제공하여 사람들이 활용하기 바랐다. 문서를 통해 이 기법들은 어떠한 상황에서 이 기법을 쓰면 좋은지 어떻게 써야 하는지에 대해 방법론 TF에서 제시했다.
[애자일 프랙티스]방법론은 점점 더 훌륭한 겉 모양새를 갖추어 나가기 시작했다.
