6장. 애자일 교육기획#3
#6-3 애자일 분석/설계 방법
#6-3 애자일 분석/설계 방법
즉흥연기가 끝나고, 우리는 역할별로 분반했다. 전체 인원을 2개의 그룹으로 나누고 BA/QA 역할자를 한 강의실에 다른 한 강의실에는 Dev들을 이동시켜 각각 별도의 교육을 실시했다. BA와 QA도 서로 독립된 교육 형태로 수행하는 것이 보다 효과적이었으나 강의실 확보가 여의치 않아 함께 하기로 했다.
교육 후 바로 실전 프로젝트를 수행하는 과정이었기에 역할자 별로 무슨 일을 해야 하는지 가르치는 것이 중요했다. BA와 QA는 사용자 스토리의 개념, 애자일의 분석/설계 기법 등에 대한 내용을 Dev는 지속적인 통합 및 딜리버리, 자동화 테스트 등의 개념을 주로 가르쳤다.
이즈음 우리는 프로젝트 수행 중 고객 역할을 할 담당자를 섭외했다. T사에 부탁하여 실제 제품 기획 아이디어가 있는 인도에 있는 BA를 찾았다. 인도와는 3.5시간의 시차가 있어 글로벌 환경에서 커뮤니케이션이 일어나는 환경을 경험할 수 있을 것이라 기대했다.
교육 과정은 엄밀히 말하면 업무와 별반 차이가 없었다. 실전인 것처럼 교육에서 다양한 애자일 기법들을 익힐 수 있었다. 이 기법들은 몇 가지의 게임을 제외하고는 조나단 라스머슨이 쓴 “애자일 사무라이" (한글 번역명 애자일 마스터)라는 책의 기법을 거의 그대로 실제 프로젝트에 수행했다.
* 애자일 분석/설계 기법
[죠나단 라스머슨의 애자일 마스터]이번 절에서는 당시에 작성한 메모와 여러 가지 사진들을 기반으로 설명해 보겠다. 우리는 책 속의 내용을 그대로 현실에서 수행했고, 그 기법 하나하나의 가진 의미를 온전히 이해할 수 있었다.
1) 고객 만나기
고객을 원격 콘퍼런스 콜을 통해 만났다. 시차를 고려해서 조금 늦은 시간에 콜을 잡았다. 고객에게 팀원을 소개했다. 그리고 애자일 방식으로 수행할 때 우선순위화에 대한 중요성과 팀의 속도에 대해 설명했다.
[고객 인터뷰]2) 고객 비전 청취
고객의 비전을 청취했다. 가상 고객을 통해 인도의 사회문제 중 하나를 들을 수 있었다. '13년 당시 인도에는 지독한 가난 때문에 자신의 심지어 피를 팔아 삶을 이어나가는 사람들이 있었다. 이들은 헌혈을 하고 자신의 피에 대한 대가로 돈을 받아 음식을 샀다. 실제 문제는 너무 자주 헌혈을 하는 사람들에게서 발생했다. 거의 매일 헌혈하여 빈혈로 쓰러져 길거리에서 죽는 사람들이 있었다. 이들을 하는 사람들을 위해 그들의 정보를 보관하고 헌혈한 지 20일 전에는 헌혈을 하러 오면 집으로 돌려보내고, 시스템을 통해 건강을 보장하려는 니즈가 있었다.
[비전 청취]3) 비전의 문서화
그리고 고객에게 들은 제품의 비전을 문서화하는 것이 필요했다. 우리는 엘리베이터 피치라는 기법을 사용했다. 엘리베이터 피치란 문자 그대로 엘리베이터에서 만난 의사결정자에게 1분 이내에 원하는 스폰서십을 얻기 위해 진행하는 피치를 말한다. 이전 장에서 설명한 적이 있는 캐즘을 건너서의 저자 죠프리 무어는 엘리베이터 피치를 다음의 형태로 정리했다.
이를 통해 타깃 고객을 명확히 하고, 고객의 힘든 점(Pain Point)을 해결하기 위해 제품을 만드는지 알 수 있다. 또한 이 제품의 가장 중요한 특징과 경쟁사 제품과의 차별점등을 정리할 수 있다. 경쟁사 제품이 없는 경우는 이러한 제품이 없을 때 어떻게 문제를 해결해왔는지를 적는다.
[죠프리 무어의 엘리베이터 피치]4) 제품 박스 만들기
팀이 모두 함께 하는 활동으로 엘리베이터 피치에서 얻은 정보를 기반으로 제품을 만드는 목적이 무엇인지를 팀원들이 모두 함께 수행하는 기법이다. 제품을 시장에 판다고 가정했을 때, 겉포장재에 문구를 어떻게 쓰면 특장점이 잘 드러날지 고민한다. 그리고 박스, 색종이, 가위, 풀 등을 이용해 팀이 함께 꾸며본다. 이를 통해 팀은 제품의 중요성과 가치에 대해 공감대를 형성할 수 있다.
[제품 박스 만들기]5) 역할과 목표 만들기
제품의 비전에 대한 공감대를 형성한 후 사용자에 대한 고민을 시작한다. 타깃 사용자가 누구인지를 식별하고 그들의 목표와 그 목표를 어떻게 시스템적으로 지원할 것인가를 고민하여 기능을 정의한다. 필요한 최대 많은 기능을 도출해 낸다. 이때 도출된 기능은 아주 작은 것부터 큰 것까지 존재하기 때문에, 필요한 경우 크기를 맞출 필요도 있다.
누가(Who): 사용자는 누구인가?
무엇을(What): 사용자의 목표가 무엇인가?
어떻게(How): 어떻게 시스템적으로 그 목표를 지원할 것인가?
예) 누가: 기부자
무엇을: 자신이 마지막으로 헌혈을 했던 때를 확인하고 싶다.
어떻게: 기부 히스토리
(회사 내에서 코칭을 다니며 이 기법을 현실에서 쓸 때는 다른 애자일 코치의 제안으로 왜(Why?)를 추가했다. 사용자의 가치를 처음부터 심도 있게 고민하게 해주는 요소였다. 예) 너무 짧은 기간에 다시 헌혈하지 않도록 건강을 보호한다)
[역할과 목표 만들기]6) 기능 피라미드 만들기
역할과 목표 만들기 활동을 통해 식별한 기능들을 우선순위화 한다. 가장 위칸 가장 왼쪽 위이 가장 우선순위가 높다. 같은 행에서는 오른쪽으로 갈수록 우선순위가 낮다. 긴급성과 중요도를 기반으로 우선순위를 잡을 수 있고, 가장 중요한 것은 같은 우선순위는 없다는 것이다. 이때 기능적, 비기능적 기능을 큰 단위로 함께 식별하여, 모든 기능이 아닌 가장 먼저 수행해야 할 10개 정도만 먼저 우선순위화 한다.
[기능 피라미드 만들기]7) 퍼소나 및 사용자 시나리오 만들기
먼저, 가장 높은 우선순위에 있는 기능의 타깃 사용자에 대해 고민한다. 그리고 아래의 4가지 특성으로 사용자에 대한 정보를 채운다. 이를 통해 사용자의 문화적, 지역적 특성을 이해하고 그에 맞는 시스템을 만들 수 있다.
인물정보(Biographic): 태어난 곳, 교육, 일터
인구통계학적 정보(Demographic): 성, 나이, 인종, 언어
심리학적 정보(Psychographic): 성격, 특성, 관심사, 라이프 스타일
기술친숙 정보(Technographic): 커뮤니케이션 스킬, IT 장비에 친숙도
퍼소나를 완성한 뒤에는 기능 피라미드에서 가장 우선순위가 높은 기능에 대해 사용자가 어떻게 사용할 지에 대한 사용자 시나리오를 적는다. 그 기능을 사용할 상황적 설명과 더불어 하루 동안 일어날 일을 설명한다.
[퍼소나 만들기]8) 페이퍼 프로토타입 만들기
기능 피라미드를 통해 높은 우선순위가 나온 기능에 대해 사용자 시나리오 기반의 프로토타입을 만든다. 페이퍼로 이를 만들기 때문에 디자인이나 컴포넌트가 어디에 붙어있어야 할지 고민하지 않는다. 대신에 이를 팀이 함께 만들며 토론하고 향후 시스템을 실제 만들 때에 대한 고민을 메모한다.
[페이퍼 프로토타입]9) 사용자 스토리 작성하기
기능 피라미드와, 페이퍼 프로토타입 결과, 그리고 사용자 시나리오를 보고 사용자 스토리를 작성한다. 이를 작성할 때는 앞에서 작성했던 역할과 목표를 참조하면 더 쉽다. 모든 사용자 스토리를 지금당장 당세하게 쓸 필요는 없다. 기능 피라미드의 우선순위대로 작성하여 최초 30개 정도만 작성해도 충분하다. 이터레이션 내에서 이를 더 구체화하면 된다.
As 사용자
I want 사용자의 목표
So that 사용자가 얻는 가치
예)
As 관리자
I want 최근 기부자로부터의 감동적인 피드백을 보여주고 싶다
So that 이를 통해 더 많은 기부자가 시스템을 사용할 수 있도록
[사용자 스토리 작성하기]10) 사용자 스토리 추정하기
작성된 사용자 스토리는 팀 전체가 함께 업무량을 추정한다. 팀 전체가 함께 업무량을 추정하는 이유는 업무량을 추정하는 것보다 팀이 함께 고민하고 정보를 교환하며 토론을 통해 공감대를 이루는 것이 중요하기 때문이다.
[사용자 스토리 추정하기]11) 팀 속도 추정하기
팀 전체와 스토리의 완료기준에 대해 고민하고, 사용자 스토리 추정 후 팀 전체와 함께 한 개의 이터레이션 동안 어느 정도의 스토리를 완료할 수 있는지 고민해 본다. 이를 통해 대략적으로 이터레이션 별로 끝내야 할 양 및 끝낼 수 있는 양에 대해 함께 이야기한다.
[팀 속도 추정하기]12) RAID(위험: Risk, 가정: Assumption, 이슈: Issue, 의존성: Dependency)
사용자 스토리가 준비되면, 마지막으로 RAID라는 활동을 한다. 이것은 프로젝트의 위험을 사전에 도출하여 관리하는 행위이다. RAID를 이루는 네 가지의 요소는 사전적 정의에 의하면 아래와 같이 정의될 수 있지만, 실제로 현장에서 이를 구별하는 것은 크게 의미가 없다. 때문에 이를 사전에 정리하고 고민하는 것에 방점을 두고 최대함 많이 도출하여 관리하는 것이 필요하다. 당시 재밌는 방식으로 RAID를 조사했는데, 팀원을 4~5명 단위로 나누고, 그들끼리 이슈를 도출하게 한 뒤, 이 RAID들을 빙고 판에 넣고 서로 빙고 게임을 한다. 이를 통해 RAID들에 대해 함께 식별한다. 이후 한 개씩 토론하며, 중요도와 긴급도를 고민하여 가장 우선순위가 높은 RAID부터 누가 어떻게 해결할지 고민한다.
- 위험(Risk): 일어날 가능성이 있으나, 일어나지 않은 일
예) 고객의 변심으로 프로젝트 방향을 바꿀 수 있다.
- 가정(Assumption): 이렇게 될 것이다라는 가정으로 일을 진행하여, 가정대로 일이 안될 경우 팀에 병목을 만들 수 있는 일
예) 팀원 모두 영어로 커뮤니케이션하는 것이 익숙하다.
- 이슈(Issue): 식별되고 실제 일어난 일
예) 서버가 노후되어 최근 시스템 성능이 떨어지고 있다.
- 의존성(Dependency): 다른 팀 또는 이해관계자와의 의존관계
예) 3월 11일까지 A팀에서 우리와 연관된 모듈을 완성하여 제공해줄 것이다.
[RAID]12) RAID 완화 또는 해결 계획
식별한 RAID 마다 어떻게 수행할지, 담당자가 누구인지, 언제까지 해결할지에 대해 작성한다.
[RAID 완화 계획]강의를 통해 위에서 말한 12가지 기법을 활용하여 업무를 상세화하고 계획을 세웠다. 강의장 벽면 전체는 이젤 패드와 포스트잇으로 덕지덕지 붙어있었다. 우리는 이를 좀 정리할 필요가 있었다. 비전부터 시작하여 RAID까지 순서대로 쉽게 볼 수 있도록 한쪽 벽면에 정리했다. 그리고 팀원은 누구나 프로젝트 기간 중 언제나 수정할 수 있도록 했다.
만들어 놓고 보니, 결과물로 다양한 문서들이 있었다. 하지만, 과거에 작성했던 문서들과의 가장 큰 다른 점이라면 작성한 개인이 아닌 팀원 모두가 이 문서의 내용을 속속들이 이해하고 있었다.
