애자일 프로세스를 가장 쉽게 이해하는 법
10년 전에 나온 고전 유튜브 영상을 보고
솔직히 그동안 "애자일이.. 애자일 하게.." 말은 많이 들었는데, 완벽하게 이해는 못했었다. 그런데 어느 날 본 유튜브 영상을 통해 "아 이거구나!"하고 깨달음을 얻었다. 대체 애자일하게 일하는 게 뭔지, 애자일 프로세스에서 PO(Product Owner)는 어떤 일을 해야 하는지 궁금하다면 이 영상을 추천한다.
Agile Product Ownership in a Nutshell (원본 영상)
출처 : https://youtu.be/502ILHjX9EE
무려 10년 전에 나온 영상이다. 그런데 너무 유익하고 재밌다. 단점은 한글 자막 지원을 하지 않는다는 것.
자동 번역으로 봤다가 완벽하게 이해하지 못한 부분이 있는 것 같아서 셀프로 정리해 보았다. (사실 요약과 번역과 의역 그 중간의 어딘가이다.)
User Story의 탄생
출처 : https://youtu.be/502ILHjX9EEPat이라는 Product Owner가 있다. 그녀는 열정적인 제품 비전을 가지고 있다. 그녀는 우리 제품이 무엇을 할 것인지 구체적으로 알지 못하지만, 왜, 어떤 문제를 해결하기 위해, 누구를 위해 제품을 만드는지 알고 있다. 그리고 이해관계자들이 있다. 그들은 개발 중인 시스템을 사용하고 지원하거나 어떤 방식으로든 영향을 받을 사람들이다. 이해관계자들의 요구사항과 팻의 아이디어는 유저 스토리가 되어 백로그에 기록된다.
출처 : https://youtu.be/502ILHjX9EE그리고 실제로 시스템을 구축하는 개발팀이 있다. 이 팀은 애자일팀이기 때문에 최종적으로 큰 릴리즈를 하기보다, 일찍 자주 릴리즈한다. 그들은 주당 4-6개의 스토리를 릴리즈 하고, 이것이 그들의 용량이다.
일부 스토리는 커서 두 개로 계산할 수 있고, 일부 스토리는 작아서 반개로 계산할 수 있다. (일부는 스토리 포인트로 부름) 이 속도를 유지하고 수동 테스트에 시간을 소비하지 않기 위해, 팀은 자동화된 테스트와 지속적인 통합에 큰 투자를 하고 있다. 따라서 대부분의 코드는 자동화된 단위 테스트를 가지고 있다.
오버플로우를 막는 방법
출처 : https://youtu.be/502ILHjX9EE문제는 많은 이해관계자들의 요구사항은 주당 4-6개만이 아니라는 것이다. 그때 오버플로우가 발생한다. 주당 10개의 사용자 스토리가 입력되는데, 출력은 4-6만 가능하다면 팀은 과부하될 것이다. 그로 인해, 멀티태스킹을 해야 하고, 동기 부여 상실, 낮은 생산성, 낮은 품질을 야기할 것이다. 이것은 결국 양측 모두에게 손해를 야기한다. 이는 프린터에 더 많은 종이를 밀어 넣어 더 빠르게 출력하려는 것과 비슷한다. 이것을 작동하지 않고 오히려 상황을 악화시킨다.
출처 : https://youtu.be/502ILHjX9EE그럼 어떻게 해야 할까? 스크럼에서 이 문제를 피하는 방법을 “어제의 날씨”라고 부른다.
“지난 몇 주 동안 매주 4-6개의 기능을 완료했어요. 그러니까, 이번 주에 어떤 4-6개의 기능을 구축할까요?”
PO의 역할은 전체 우주에서 가능한 모든 스토리 중에 다음에 어떤 4-6개의 스토리를 전달할지 결정하는 것이다.
출처 : https://youtu.be/502ILHjX9EE칸반에서 이 문제를 피하는 방식은 작업 중인 항목 또는 WIP를 제한하는 것이다. 팀이 한 번에 처리할 수 있는 최적 숫자를 5개라고 결정한 경우를 가정해 보자. 그들은 숫자 5가 과부하를 처리하지 않으면서, 모든 사람을 바쁘게 유지하기 충분하다는 것을 배웠기 때문에 한계치를 5로 결정했다. 그들은 한 스토리를 완료할 때마다 다른 스토리를 수락할 것이다. 그렇게 항상 5개의 진행 중인 스토리를 유지한다.
출처 : https://youtu.be/502ILHjX9EE하지만 부작용은 팀 앞에 큐가 형성된다는 것이다. 스크럼에서는 제품 백로그라고 부른다.
만약 이해관계자들이 매주 10개의 사용자 스토리를 요청하고 팀이 매주 4~6개의 스토리를 완료할 수 있다면, 이는 백로그가 계속해서 더 길어질 것을 의미한다. 눈 깜짝할 사이에 백로그는 6개월치나 쌓일 것이다. 이는 곧, 지금 팀이 전달하는 스토리가 6개월 전에 요청한 것임을 의미한다. 이것이 애자일 하다고 볼 수 있을까?
무한히 쌓이는 백로그 문제를 해결하는 법
출처 : https://youtu.be/502ILHjX9EE백로그 문제를 해결할 유일한 방법은 “아니요”라고 말하는 것이다. 이는 PO에게 가장 중요한 단어다. 새로운 요청에 대해 “예”라고 말하는 것은 쉽다. 하지만 PO의 가장 중요한 역할은 무엇을 구축하지 않을지 결정하고, 그 결정의 결과를 받아들이는 것이다. PO는 백로그에 어떤 것이 들어가고 어떤 것이 나가는지를 결정한다. 또한 순서를 정하고, 지금 무엇을 구축할지, 나중에 무엇을 구축할지, 그리고이 목록이 실제로 얼마나 길어져야 하는지를 결정한다.
출처 : https://youtu.be/502ILHjX9EE이것은 어려운 작업이므로 PO 혼자서 하지 않는다. 팀과 이해관계자들과 협력하여 우선순위를 정할 수 있도록 한다.
우선순위를 정하는 법
출처 : https://youtu.be/502ILHjX9EE우선순위를 정하기 위해 PO는 각 스토리의 가치와 크기에 대해 어느 정도 알아야 한다. 일부 스토리는 중요하며, 다른 스토리는 추가 기능에 불과하다. 일부 스토리는 구축하는 데 몇 시간만 걸리고 다른 스토리는 몇 달이 걸린다. 그렇다면 가치와 크기에는 상관관계가 있을까? 없다! 사용해 본 서비스를 떠올려보면, 하루 종일 사용하는 매우 중요한 아주 간단한 기능이 적어도 하나는 있을 것이며, 아무런 중요성이 없는 매우 복잡한 큰 기능이 하나 이상 있을 것이다. 가치와 크기는 PO가 지혜롭게 우선순위를 정할 수 있도록 도와준다.
예를 들어, 같은 크기인데 더 큰 가치를 지니는 것이 있다면, 이것을 먼저 구축한다.
같은 가치인데 더 작은 크기를 지니는 것이 있다면, 이것을 먼저 구축한다.
출처 : https://youtu.be/502ILHjX9EE이렇게 말하면 쉬워 보이지만, PO는 어떻게 스토리의 가치와 크기를 알 수 있을까? 상대적으로 추측할 수 있지만 정확하게 알 수는 없다. PO는 지속적으로 이해관계자들과 대화하며 그들이 생각하는 가치를 알아낸다. 그리고 팀과 대화하며 구현 노력 측면에서 크기가 큰지 작은지 알아낸다.
예를 들자면, 이 사과와 딸기의 정확한 무게는 알 수 없다. 하지만 사과가 적어도 딸기보다 5배쯤 무겁다고 확신한다. 그리고 적어도 딸기가 내게 더 맛있다고 이야기할 수 있다. 이것이 PO가 백로그를 우선 순위화하기 위해 필요한 모든 것이다.
새 프로젝트의 시작에서는 추측이 부정확할 확률이 높다. 하지만 가장 큰 가치는 실제 숫자보다 대화에 있다. 그리고 팀이 사용자에게 무언가를 전달할 때마다, 팀은 새로운 것을 배운다. 또한 가치와 크기를 더 잘 추측할 수 있다. 이 방식으로 지속적으로 우선순위를 정하고 추정하기를 반복한다. 처음부터 모든 것을 올바르게 맞출 수는 없다. 그래서 우리에겐 피드백 루프가 있다.
백로그를 관리하는 법
출처 : https://youtu.be/502ILHjX9EE그러나 우선순위만으로는 부족하다. 빠르게 자주 전달하기 위해서는 스토리를 작은 조각으로 분해해야 한다. 가능하면 스토리당 단 몇일의 작업이어야 한다. 이상적인 깔때기의 모양을 상상해 보자. 앞에는 작고 명확한 스토리들이 있고, 뒤에는 더 모호한 스토리들이 있다. 이처럼 스토리의 가치와 크기를 추정하고 우선순위를 정하고 분할하는 것을 “백로그 관리”라고 부른다.
Pat은 매주 수요일 11-12시에 백로그 관리 워크숍을 진행한다. 매주 한 시간, 전체 팀이 보통 참석하며 때로는 몇몇 이해관계자도 참석한다. 의제는 조금씩 다르지만 때로는 추정, 때로는 스토리 분할, 때로는 스토리의 수용 기준 작성 등에 초점을 맞추기도 한다.
여기에서 여러분이 주제를 알아차렸길 바란다. 바로 커뮤니케이션이다. 경험 있는 PO에게 성공을 위해 무엇이 필요하냐고 물으면, 그들은 열정과 커뮤니케이션을 강조한다. 애자일 선언의 첫 번째 원칙 또한 "개인과 상호작용이 프로세스와 도구보다 중요하다"라고 말한다.
PO는 팀에게 스토리를 스푼으로 떠먹여 주는 사람이 아니다. PO는 모두가 비전을 이해하고 있는지, 팀이 이해 관계자와 직접 접촉하고 있으며, 실제 유저가 전달할 수 있는 짧은 피드백 루프가 있는지 확인하는 것이다.
트레이드오프 1. 리스크
출처 : https://youtu.be/502ILHjX9EEPO와 팀이 해야 할 몇 가지 트레이드오프가 있다. 먼저 여러 가지 리스크가 있다. 프로젝트 초반에는 불확실성과 위험이 있다. 그리고 비즈니스적, 사회적, 기술적, 비용 관련, 일정 관련 리스크가 있다.
우리가 올바른 것을 만들고 있나?
우리 팀이 이것을 만들 수 있나?
우리가 실행하려는 플랫폼에서 작동하나?
확장 가능성이 있나?
비용과 일정은 충분한가?
지식은 리스크의 반대쪽에 있다. 따라서 불확실성이 높을 때, 지식 습득에 초점을 맞춰야 한다. 예를 들면, 사용자 인터페이스 프로토타입, 기술적 스파이크, 실험 등등. 고객에게 흥미롭지 않을 수 있지만, 이것들은 위험을 줄여준다.
출처 : https://youtu.be/502ILHjX9EE고객 가치 관점에서 보면, 초기에는 곡선이 낮다. 불확실성이 감소함에 따라 점점 더 고객 가치에 초점을 맞추게 된다. 가장 가치가 높은 스토리를 먼저 만듦으로써 가파른 가치 곡선을 얻을 수 있다.
출처 : https://youtu.be/502ILHjX9EE점차 가치 곡선이 평평해질 때는, 가장 중요한 것을 구축했을 때다. 이제는 보너스 기능, 즉 아이스크림 위에 토핑을 추가하면 된다. 이 지점에서 팀은 꼬리를 정리하고 다른 프로젝트로 이동할 수 있다. 또는 제품 내에 새로운 기능을 추가할 수 있다. 이것을 비즈니스 민첩성이라 부른다.
출처 : https://youtu.be/502ILHjX9EE지금까지 가치를 이야기할 때, 그것은 사실 지식 + 고객 가치가 포함된 것이었다. 이 둘 사이의 트레이드오프를 계속 찾아야 한다.
트레이트오프 2. 단기적인 생각 vs 장기적인 생각
출처 : https://youtu.be/502ILHjX9EE두 번째 트레이드오프는 단기적인 생각 대 장기적인 생각이다.
다음에 무엇을 구축하는 것이 좋을까?
긴급한 버그 수정
사용자를 놀라게 할 멋진 새로운 기능 구축
미래에 더 빠른 개발을 가능하게 할 어려운 플랫폼 업그레이드
PO는 대응적인 작업과 사전적인 작업 사이에서 지속적으로 균형을 유지해야 한다.
트레이드오프 3. 무엇에 집중할 것인가?
출처 : https://youtu.be/502ILHjX9EE세 번째 트레이드오프는 구축에 관한 것이다. 어디에 집중하는 것이 좋을까?
올바른 것을 만들기
올바르게 만들기
빠르게 만들기
이상적으로 세 가지 모두를 원하지만, 그것은 어렵다.
출처 : https://youtu.be/502ILHjX9EE올바른 것을 만들기와 올바르게 만들기 사이에 있다고 가정해 보자. 완벽한 제품과 완벽한 아키텍처를 구축하려다 너무 많은 시간을 쓰게 될 수 있다. 시장 타이밍을 놓치거나 자금 흐름 문제가 발생할 수 있다.
출처 : https://youtu.be/502ILHjX9EE또는 올바른 것을 만들기와 빠르게 만들기 사이에 있다고 가정해 보자. 프로토타입을 제품으로 빠르게 전환할 수 있다. 하지만 장기적으로는 기술 부채에 빠져들게 된다. 단기적으로 빠르지만, 장기적으로는 속도가 제로에 가까워질 수 있다.
출처 : https://youtu.be/502ILHjX9EE또는 올바르게 만들기와 빠르게 만들기 사이에 있다고 가정해 보자. 기록적인 시간 내에 아름다운 성당을 건설하려고 한다. 그런데 사용자는 성당이 아닌 캠핑카가 필요하다.
출처 : https://youtu.be/502ILHjX9EE그래서 각자의 역할 사이에 건강한 긴장이 존재하는 것이 좋다.
PO : 올바른 제품 만들기
개발자 : 올바르게 제품 만들기
스크럼 마스터, 애자일 코치 : 피드백 루프 줄이기
속도가 빠르면 학습이 가속화되며, 더 빨리 올바른 것을 구분하고, 올바르게 구축할 수 있게 배움을 준다. 하지만 세 관점의 균형을 찾는 것이 가장 중요하다.
트레이드오프 4. 새 제품 개발 vs 기존 제품 개선
출처 : https://youtu.be/502ILHjX9EE마지막으로 새 제품 개발과 기존 제품 개선 사이의 트레이트오프가 있다. 제품 백로그라는 용어는 가끔 혼란을 줄 수 있다. 하나의 제품만 있다는 것을 의미하기 때문이다. 그리고 프로젝트라는 용어도 개발이 끝나는 것처럼 보이게 해 혼란스러울 수 있다. 제품은 항상 유지보수와 개선이 필요하며, 완성되지 않는다.
그렇다면 팀이 새로운 제품을 개발하기 시작하면 어떻게 될까? 다른 팀으로 제품을 넘기는 것은 비용이 많이 들고 리스크가 크다. 그래서 더 일반적인 시나리오는 팀이 새 제품을 개발하는 동안 기존 제품을 유지 관리하는 것이다. 이렇게 되면 사실상 팀 백로그에 가까워진다. PO는 여러 백로그 사이에서 계속해서 트레이드오프를 해야 한다.
PO가 미래를 예측하는 방법
출처 : https://youtu.be/502ILHjX9EE가끔 이해관계자가 전화가 와서 “작업은 언제 끝나나요?” “크리스마스 전까지 얼마나 끝날 수 있나요?” 하고 물어볼 것이다. PO는 기대관리에 대한 책임이 있다. 더 중요한 것은 그것을 거짓으로 말하지 않는 것이다.
스토리 버닝업 차트를 그려서 정확하지는 않아도 예측할 수 있다. Delivered Stories 차트는 시간에 따른 누적 스토리의 개수를 보여준다. 고객 가치 차트와의 차이점은 고객 가치 차트는 결과 (outcome)를 보여주고 스토리 버닝업 차트는 출력 (output)을 보여준다. PO의 목표는 가능한 많은 아웃풋을 생성하는 것이 아니다. 최소한의 아웃풋을 사용하여, 원하는 결과인 행복한 이해 관계자에게 도달하는 것이다. (Less is more)
출처 : https://youtu.be/502ILHjX9EE버닝업 차트에서 낙관적/비관적 추세 선을 그릴 수 있다. 이 두 선 사이의 갭은 불안정성, 예측 불가능성과 관련된다. 다행히 시간이 지남에 따라 안정화되는 경향이 있어서, 불확실성의 원뿔은 점점 좁아질 것이다.
출처 : https://youtu.be/502ILHjX9EE다시 기대관리로 돌아가서, “모든 작업은 언제 끝나나요?” 하고 물으면, 이것은 고정 범위 / 가변 시간 질문이다. PO는 2개의 추세선을 사용해 답할 수 있다. “아마도 4월에서 5월 중순 사이일 것입니다.”
출처 : https://youtu.be/502ILHjX9EE이해관계자들이 "크리스마스까지 얼마나 끝낼 수 있을까요?"라고 물으면, 그것은 고정 시간 / 가변 범위 질문이다. 추세선은 크리스마스까지 끝낼 수 있는 것을 보여준다. 그중 일부는 완료되고 일부는 완료되지 못할 것이다.
출처 : https://youtu.be/502ILHjX9EE마지막으로, 이해관계자들이 "이 기능들을 크리스마스까지 구현할 수 있을까요?"라고 말한다면, 이것은 고정 시간 / 고정 범위 질문이다. 추세 선을 보고 PO는 "아니요, 미안하지만 그렇게 될 가능성은 없습니다"라고 말하며, "크리스마스까지 얼마나 많이 끝낼 수 있는지" 또는 "모든 것을 끝내려면 얼마나 많은 시간이 더 필요한지"를 말한다.
일반적으로 시간을 확장하는 대신 범위를 축소하는 것이 더 나은 경우가 많다. 왜냐하면 우리가 먼저 범위를 줄이면 나중에 시간을 늘릴 수 있는 옵션이 남아 있기 때문이다. 그리고 나머지 스토리를 추가할 수 있다. 그 반대는 동작하지 않는다. 왜냐하면 시간을 거꾸로 돌릴 수는 없기 때문이다.
그래서 PO는 이렇게 말한다 “우리는 여기서 뭔가를 전달하고 나중에 나머지를 전달할 수 있습니다. 또는 우리는 여기서 아무것도 전달하지 않고 나머지를 나중에 전달할 수 있습니다. 어떤 것이 더 선호하시나요?”
이러한 계산은 꽤 간단해서, 매주 예측을 업데이트할 수 있다. 중요한 점은 실제 데이터를 사용하고, 불확실성에 대해 거짓말을 하지 않는 것이다. 이해관계자와 솔직하게 소통하면, 대부분 그들을 그것을 좋아한다. 당신의 조직이 진실과 정직을 좋아하지 않는다면, 아마 애자일도 마찬가지일 것이다.
큰 프로젝트에 애자일 적용하기
출처 : https://youtu.be/502ILHjX9EE만약 여러 팀으로 이루어진 큰 프로젝트가 있고, 각자의 백로그를 가진 여러 PO가 있다면 어떨까?
전체적으로 동작하는 모델은 동일하다.
여전히 입력-출력 관리가 필요하다
여전히 이해관계자와의 의사소통이 필요하다
여전히 "아니요"라고 할 수 있는 PO가 필요하다
여전히 백로그 정리가 필요하다
여전히 짧은 피드백 루프가 필요하다
출처 : https://youtu.be/502ILHjX9EE속도는 모든 산출물의 합이므로 예측에 사용할 수 있다. 더 합리적인 경우 각 팀별로 별도의 예측을 할 수도 있다. 그러나 여러 팀으로 이루어진 시나리오에서 PO는 한 가지 더 책임을 가지게 된다. PO 간의 대화이다. 보통 의존성을 최소화하기 위해 팀과 백로그를 구성해야 하지만, 없앨 수 없는 의존성도 있다. 그래서 PO 간의 동기화가 필요하다. 그리고 대규모 프로젝트에서는 PO들을 동기화하는 역할을 하는 CPO의 역할이 필요하다.
