애자일스럽게 팀 운영하기
애자일, 들어보긴 했는데 어떻게 써먹지?
목차
1. 차근차근 살펴보는 애자일 프로세스
2. 현재 상황을 빠르게 파악하려면?
3. 어떤 SaaS가 애자일 시스템에 적합할까?
하나라도 해당되면, 재밌게 읽을 수 있어요!
1. 프로덕트 백로그를 어떻게 작성해야 효과적일지 모르겠다.
2. 개발 팀 혹은, 개발자가 속한 팀을 어떻게 리드해야 할지 모르겠다.
3. PO를 꿈꾼다.
차근차근 살펴보는 애자일 프로세스
이전 글에서 애자일이 무엇이고, 애자일의 기본 요소인 '유저 스토리'를 다뤘다.
애자일의 전반적 개념을 알았으니, 이제 팀과 프로젝트를 어떻게 하면 애자일스럽게 운영할 수 있는지 알아보자! 애자일 프로세스는 아래와 같이, 크게 5가지 단계로 구성할 수 있다.
1. 관련된 모든 스토리를 리스팅 하기
2. 릴리즈로 스토리 묶기
3. 각 스토리의 상대적 크기 파악하기
4. 개발을 진행하면서, 팀의 속도 트래킹 하기
5. 유동적으로 릴리즈 수정하기
1. 관련된 모든 스토리를 리스팅 하기
프로덕트에 어떤 스토리가 필요한지 최대한 많이 수집하는 시간을 가장 먼저 갖는데, 이 시간을 '스토리 계획 워크숍'이라고 부른다. 스토리 계획 워크숍의 핵심은 '넓게 보기'다. 팀의 목표, 핵심 가치, 아이디어의 방향 등을 기준으로 최대한 넓게 보면서, 많은 스토리를 찾아야 한다. 이렇게 모든 스토리를 모아 놓은 게 '프로덕트 백로그'(='마스터 스토리 리스트')가 된다. 해당 백로그를 채울 때, 고객에게 제공하는 가치를 기준으로 우선순위를 매겨서 스토리를 배열한다. 참고로 지금 단계에서 매긴 우선순위는 추후 유동적으로 바뀔 수 있다.
스토리 계획 워크숍에서 몇 가지 도구를 사용하면, 스토리를 더 효율적으로 찾을 수 있다.
플로우 차트에서 스토리 찾기
플로우 차트는 유저와 프로덕트 사이의 인터렉션을 보여주는 차트이다. 유저가 어떤 테스크(Task)를 했을 때, 프로덕트가 어떻게 반응하는지를 시각적으로 보여준다. 대략적인 플로우 차트를 그려보고, 이 차트 속에서 유저 스토리를 찾아볼 수 있다.
스토리 맵에서 스토리 찾기
플로우 차트가 너무 딱딱하다고 느껴지면, 스토리 맵을 이용 해보자. 플로우 차트와 스토리맵, 모두 유저가 프로덕트를 이용하는 흐름을 보여준다. 둘의 차이점으로, 플로우 차트는 유저와 프로덕트, 모두에 집중한 반면에 스토리 맵은 유저에 더 집중한다. 유저가 어떤 목표를 이루기 위해 각 단계마다 어떤 행동(Activity)을 하고, 이 행동(Activity)을 실현하기 위해 구체적으로 어떤 테스크(Task)로 진행하는지를 위주로 보여준다. 예를 들어, '숙소 검색하기'가 행동(Activity) 면, '날짜 필터 설정', '검색창에 도시 입력' 등이 태스크(Task)가 된다.
페이퍼 프로토타입에서 찾기
팀에서 프로토 타입을 종이로 스케치해본다. 팀원 각자가 프로덕트를 종이 위에 그려보고, 서로 의견을 나눈다. 이후, 모두가 동의하고 얼라인 되는 종이 결과물이 나오면, 이 결과물에서 어떤 스토리가 필요한지 생각한다.
2. 릴리즈로 스토리 묶기
애자일은 고객에게 최소 가치를 지속적으로 제공하는 걸 목표로 한다. 따라서, 모든 스토리를 한 번에 구현하는 게 아니라, 각 이터레이션마다 몇 개의 스토리를 선택해 구현 및 배포한다. 스토리 중에는 함께 있으면, 큰 시너지를 낼 수 있는 것들이 있다. 따라서, 고객에게 더 큰 가치를 전달하기 위해, 함께 있으면 시너지를 일으킨 스토리끼리 그룹화해서 배포해야 한다. 이러한 스토리 그룹을 '릴리즈'라고 한다. 예를 들어, A와 B 스토리가 서로 시너지를 일으킨다면, 하나의 릴리즈로 묶어서 배포한다.
프로덕트 백로그에서 스토리 사이의 우선순위를 매겼듯이, 릴리즈 내에서도 우선순위를 매겨야 한다. 이 우선 순위를 기준으로, 유동적인 이터레이션 전략을 짤 수 있다. 예를 들어, 이터레이션이 끝나가는데, 릴리즈를 모두 완성시키지 못했다면? 고객에게 가치를 전달하기 위해선 무조건 배포를 해야 한다. 따라서, 릴리즈 중에서도 순위가 가장 낮은 스토리를 빼거나, 구현 퀄리티를 낮추는 식으로 문제를 햇징할 수 있다.
릴리즈는 '출시할 만한 최소한의 기능을 모아 놓은 세트(MMF, Minimal Marketable Feature Set)'이라고도 불린다. 이 명칭에서 알 수 있듯이, 릴리즈는 2가지 요소를 모두 가져야만 한다.
Minimal 최소한
애자일에서 신속하게 고객에게 가치를 전달해야 한다. 만약 구현할 스토리가 너무 많다면, 딜레이가 발생해 고객에게 가치를 늦게 전달할 수 있다. 따라서, 구현을 확신할 수 있을 정도로 릴리즈 범위를 생각해 스토리를 골라야 한다.
Marketable 출시할 만한
애자일의 정수는 '최소한의 가치를 지속적으로 제공한다'에 있다. 단순히 스토리를 구현해 배포했다는 것만으로 만족한다는 건, 팥 없는 찐빵과 같다. '스토리를 구현 및 배포'했다는 말은 '지속적으로 제공했다'를 뜻할 분이지, '최소한의 가치를 충족했다'를 보장하지 않는다. 따라서, 릴리즈 계획을 세울 때, 어떤 스토리끼리 묶어야 가치를 더 높일 수 있는지 고민해야 한다.
위 2가지 요소 중 1개라도 빠진다면...?3. 각 스토리의 상대적 크기 파악하기
고객에게 지속적으로 가치를 전달하기 위해선, 각 이터레이션마다 릴리즈(=스토리 그룹)를 성공적으로 구현해야 한다. 구현 가능성을 높이기 위해선, '(1) 릴리즈를 완성시키기 위해 필요한 리소스'와 '(2) 이터레이션에서 우리가 가용할 수 있는 리소스'를 비교해 이터레이션 스케줄링을 해야 한다. 만약 주어진 기간은 짧은데, 구현할 스토리를 지나치게 많이 계획했다면? 배포를 못하거나, 스케줄이 꼬여버릴 수 있다. 반대로, 주어진 기간은 넉넉한데, 구현할 스토리를 적게 계획했다면? 더 많은 스토리를 구현할 기회를 놓치는 셈이다.
릴리즈는 스토리의 그룹이다. 따라서, 각 스토리에 필요한 리소스를 알아내면, 자연스럽게 릴리즈에 필요한 리소스도 알아낼 수 있다. 프로덕트 백로그에 있는 모든 스토리의 리소스를 추정하는데, 여기서의 '추정'은 '절대적 추정'이 아니라 '상대적 추정'이다. '절대적 추정'은 각 스토리를 개별적으로 분석해 리소스를 추정하는 방식이고, '상대적 추정'은 특정 스토리를 기준점으로 삼고, 다른 스토리를 비교해 추정하는 방식이다. 상대적 추정을 사용하는 이유는 크게 2가지다. 우선, 스토리 추정은 결과를 정확히 예측하는 것보다, 통제 가능한지를 알아내는 데 있다. '닭 잡는 데 소 잡는 칼을 쓴다!'라는 말이 있듯이, 통제 가능 유무를 알아내는 데 '절대적 추정'은 과하다. 두 번째 이유는, 스토리 하나하나에 드는 리소스를 분석하는 게 어렵고 오래 걸린다. 여러 스토리를 개별적으로 두고 크기를 판단하는 것보다, 스토리끼리 비교를 통해 상대적 크기를 알아내는 게 훨씬 쉽다.
소프트웨어 추정의 주된 목적은 프로젝트의 결과를 예측하는 것이 아니다. 프로젝트의 목표가 통제가 가능할 만큼 충분히 현실적인지 알아보기 위한 것이다.
- 스티브 맥코넬
A 스토리 구현에 필요한 리소스가 3이라고 해보자. B, C, D 스토리의 구현 리소스를 추정할 때, A 리소스를 기준으로 한다. A 스토리와 비교했을 때, B 스토리는 쉬워 보이고, C 스토리는 비슷해 보인다. 이와 다르게, D 스토리는 매우 어려워 보인다면? A 스토리의 리소스가 3이었으니깐, B, C, D 스토리는 각각 2, 3, 5 정도로 추정할 수 있다.
플래닝 포커
플래닝 포커란?
모든 팀원이 각 스토리의 추정치를 정하고, 결과를 다 함께 비교하는 게임
프로덕트 백로그는 주로 PO가 관리하지만, 각 스토리의 리소스 추정은 PO 혼자서 하지 않는다. 스토리 리소스는 팀원의 퍼포먼스에 의존하므로, 오히려 PO 보다 팀원이 더 정확하게 추정할 수도 있다. 따라서, 다 같이 모여서 각 스토리에 얼마큼의 리소스가 들어가는지 플래닝 포커를 통해 알아내는 게 좋다. 모든 스토리에 얼마큼의 리소스가 들지 각각의 팀원이 판단하고, 결과를 서로 공유한다. 이후, 논의를 통해 스토리의 최종 리소스 추정치를 결정한다.
4. 개발을 진행하면서, 팀의 속도 트래킹 하기
릴리즈의 구현 가능성을 알기 위해, (1) 릴리즈 구현에 필요한 리소스와 (2) 팀의 가용 리소스를 알아내서 비교해야 한다. 예를 들어, 이번 릴리즈에서 필요한 리소스는 10인데, 팀의 가용 리소스가 8이라면 그만큼 구현 가능성이 매우 낮아진다. 각 릴리즈에 필요한 리소스를 앞 단계에서 알아냈으니, 이제 팀의 가용 리소스를 알아낼 차례다.
팀 속도 차트
팀의 가용 리소스는 처음부터 알기 어렵고, 여러 번의 이터레이션을 통해 알아낼 수 있다. 릴리즈 A와 릴리즈 B에 필요한 리소스는 14, 18이라고 해보자. 그리고, 이 두 번의 릴리즈를 모두 성공적으로 구현했다면? 팀의 평균 가용 리소스는 16 (=avg(14, 18))이다. 반대로, 릴리즈 A는 성공적이었으나, 릴리즈 B에서 4의 리소스가 필요한 스토리를 구현하지 못했다면? 이때, 가용 리소스는 14(=avg(14, 18-4))가 된다. 즉, '팀의 가용 리소스'는 '지금까지 완성된 스토리의 리소스 / 이터레이션 횟수'으로 결정된다.
번다운 차트
번다운 차트란?
번다운 차트는 팀이 유저 스토리를 완성하는 속도를 보여주는 그래프로, 대략 언제쯤 모든 스토리가 구현 완료되는지 보여준다.
프로덕트 백로그에 쭉 나열한 스토리를 모두 언제쯤 구현할 수 있는지 알고 싶다면, 번다운 차트를 사용한다. 번다운 차트의 x축은 각 이터레이션을 나타내고, y축은 해당 이터레이션이 끝나고, 남아있는 유저 스토리의 전체 리소스를 뜻한다. 이터레이션이 진행되가면서 구현한 유저 스토리가 점점 많아질 것이고, 그만큼 남은 유저 스토리는 줄어든다. 결과적으로, 우하향 그래프가 보이며 대략 몇 번의 이터레이션 끝에 백로그에 있는 스토리를 모두 구현할 수 있는지 예측할 수 있다.
5. 유동적으로 릴리즈 수정하기
인생사는 한 치 앞을 볼 수 없다. 예상과 다르게 팀 퍼포먼스가 낮을 수도 있고, 새로운 스토리가 추가되거나, 뒤늦게 버그를 발견할 수도 있다. 반대로, 혁신적인 방법을 찾거나 새로운 팀원이 합류할 수도 있다. 이러한 상황에 맞춰 릴리즈를 유동적으로 수정해야 한다. 이는 릴리즈를 구성하는 유저 스토리의 크기가 충분히 작은 덕분에 가능하다. 예를 들어, 여러 번의 이터레이션 결과, 팀의 평균 가용 리소스는 12였고, 다음 릴리즈에서 요구하는 리소스는 16이라고 해보자. 그러면, 해당 릴리즈를 구성하는 유저 스토리 중 일부를 그다음 번 릴리즈로 옮기는 등의 액션을 취하면 된다.
현재 상황을 빠르게 파악하려면?
애자일 시스템으로 팀을 운영한다면, 일부 차트를 적극 사용해보자. 시각화 차트는 팀의 현재 상황을 한눈에 파악할 수 있게 도와주고, 팀의 넥스트 액션을 제시하는 인사이트가 된다.
릴리즈 상황판
현재까지 어떤 스토리를 완성했고, 아직 남아 있는 스토리가 무엇인지 보고 싶다면 릴리즈 상황판을 만든다. 각 릴리즈를 x 축에 시간순으로 배열하고, y 축으로 스토리를 우선순위 순으로 배열한다. 이를 통해 현재까지 어떤 스토리가 완료됐고, 아직 남아 있는 스토리를 한눈에 파악할 수 있다.
이터레이션 칸반 보드
현재 이터레이션에서 유저 스토리 개발 현황을 빠르게 파악하고자 한다면, 칸반 보드를 사용하면 된다. 칸반 보드를 통해 현재 어떤 스토리가 완료됐는지, 어떤 스토리가 진행되고 있는지, 아직 시작하지 않은 스토리가 무엇인지를 한눈에 볼 수 있다. 이 칸반 보드와 남아 있는 이터레이션 기간을 함께 고려해, 스토리를 유연하게 관리할 수 있다.
번 다운 차트와 팀 속도 차트
스토리 구현 속도가 얼마나 빠른지, 모든 스토리가 언제 끝날 것인지 보고 싶다면, 팀 속도 차트와 번 다운 차트를 함께 보면 좋다.
어떤 SaaS가 애자일 시스템에 적합할까?
1. 개발자가 극찬하는, 먼데이(monday)
요즘 국내 SaaS 시장이 엄청나게 활성화되고 있는데, 저번 달(21년 8월)에 고위드에서 SaaS 경험 공유 커뮤니티, 'SaaS Cracker'라는 서비스가 나오기도 했다.
노션, 지라, 먼데이 등 프로덕트 백로그 툴도 다양하다. 나 같은 경우는 노션으로 프로덕트 백로그를 관리한다. "백로그 관리로 노션이 최고야!"라는 이유는 아니고, 문서 작업, 위키, 팀원 관리 등을 모두 노션으로 하다 보니 자연스럽게 그렇게 됐다. 여러 개의 툴을 쓰면 오히려 관리 비용이 너무 많이 들 것 같아서, "노션으로 그냥 다 해버리자!"라는 심보(?) 때문이랄까?
솔직히 말하자면, 노션은 애자일 시스템에 최적화된 건 아니다. 그렇다면 어떤 툴이 애자일 시스템 + 프로덕트 백로그 관리에 가장 좋을까? 개인적 견해로, 먼데이가 가장 애자일을 위한 툴인 듯하다. UI가 직관적이기도 하지만, 무엇보다 데이터 시각화 기능이 매우 좋다. 릴리즈 상황판, 이터레이션 칸반 보드, 번다운 차트 등 모두 구현 가능하다. 노션이 범접할 수 없는 영역이랄까? 최근에 프리 A 투자에 성공한 AI 스타트업 CTO와 밥을 먹었는데, 먼데이를 극찬해서 더 신뢰성이 간다.
2. 그..그치만 노션짱은 포기할 수 없는걸!
(그.. 그치만 노션짱! 출처 : <나무위키, 그치만 드립>)그럼에도 노션을 고집하는, 뚝심 노션러라면 Notion Charts라는 서비스를 이용해보자! 노션의 DB와 연동해 DB 데이터로 시각화한 url을 생성해준다. 이 url을 노션에 임베디드 시키면, 데이터 시각화를 어느 정도 할 수 있다. 무엇보다 5개까지 무료 생성이 가능하니 아낌없이 써보자!
관련 아티클
http://www.yes24.com/Product/Goods/6289137
