[PM/PO/기획자] Product Manager 캠프 - ③애자일이란?

INTRO

- 세 번째 시간에는 애자일 프레임워크에 대해 알아보겠습니다.

 

1. 프로덕트 개념의 탄생과 애자일 패러다임

1) 프로젝트에서 프로덕트로 전환

- 1900년대 후반까지 소프트웨어 개발의 일반적인 구조는 프로젝트를 진행하는 것이었고, 프로젝트 방식에 적합하도록 정착된 소프트웨어 개발 방법론이 워터폴 개발 방법론(이하 ‘워터폴’)이다. 폭포처럼 각 단계를 거치면서 진행을 해나간다는 의미이며, 다음 단계로 넘어가면 이전 단계로 되돌아가는 과정이 없다. 또한 한 번에 완성된 결과물을 만들어야 해서 프로젝트 기간에 발생할 수 있는 변수를 포용하기 어려워, 변수가 발생하거나 초기에 규모 산정이 적절하지 않은 경우에는 프로젝트가 완료되지 않을 위험이 있다,
- 따라서 기존의 사업 부서 주도로 개발이 진행되던 프로젝트 방식에서 개발 부서가 주도하고 프로덕트 자체가 사업을 리드하는 프로덕트 방식으로 중심이 이동하게 된다. 그 결과 기업 내에서도 프로덕트 단위 별로 소통, 계획, 개발, 출시까지 전체적인 수명주기를 관리하고 경영하는 역할이 필요하게 되었고, 이 역할을 하는 것이 프로덕트 매니저이다. 

 

2) 애자일 이해하기

(1) 왜 애자일을 하는가?

- 애자일은 우리가 대상에 대해서 아는 상태, 아직 모른다는 것을 아는 상태, 무엇이 더 존재하는지 지금은 알 수 없는 상태로 구분된다고 할 때, 이 대상에 대해서 학습하며 완성하기 위해 필요한 사고방식이다. 기존의 긴 개발주기를 가지고 있는 방식은 변화하는 환경과 프로덕트 개발에 적합하지 않다. 따라서 목표를 달성하기 위해 개발기간과 할 일을 작은 단위로 나누어 아는 만큼 반복점진적으로 개발하는 애자일 기반의 개발 방식이 더 효과적인 프로덕트를 만드는 데에 적합하다.

(2) 일 하는 방식은 어떻게 하는가?

- 가능한 만큼 계획을 수립하고, 실행해서 결과물을 만들고, 결과물을 분석하고 검토하여 학습한 것을 다음 개발주기에 반영하는 순환구조이다. 애자일 팀은 프로덕트 개발에 필요한 모든 역할 구성원이 한 팀이 되어 하나의 목표를 지향한다.

(3) 애자일 한 상태가 되었다는 의미는 무엇인가?

 

3) 애자일 조직의 특징과 일 하는 방식

(1) 소규모 팀: 큰 프로덕트의 한 부분을 담당하는 3~9명의 소규모 팀. 스포티파이에서는 ‘스쿼드’ 라고 한다. 애자일을 실행하는 프레임워크 중 많이 활용하는 스크럼 프레임워크에서는 ‘스크럼 팀’이라고 한다.

(2) 자율경영 Self-management: 관리보다는 일을 잘 할 수 있는 권한과 환경을 제공하여 일하는 방식과 진행 정도를 팀원 모두 스스로 결정하고 관리한다

(3) 교차기능 Cross-functional: 전통적인 조직에서는 역할이 같은 사람을 한 팀으로 묶었지만 애자일 팀은 목표를 달성하는데 필요한 모든 기술을 갖춘 팀원들로 구성한다. 

(4) 린 생산방식 Lean Production: 린은 낭비요소를 최소화 하여 적시에 시장에 제품을 출시하는 도요타 (일본의 최대 자동차 제조기업)의 생산방식에서 탄생했다. 리드타임 Lead time (할 일이 생성되어서부터 - 주문, 할 일을 완료할 때까지 - 출시)를 최소화하려는 방식이며 초과생산, 재고, 운송, 동작, 대기, 결함, 과도한 프로세스 7가지 분야에서 실행한다. 

(5) 린 스타트업 Lean Startup: 스타트업에 적합한 전략으로 이른 시점에 가설을 제품으로 만들고 검증하여 학습한 것을 적용하는 것을 반복하는 것. 이 전략에서 Minimum Viable Product - MVP 기법이 탄생하였다.

(6) 칸반 Kanban: 큰 보드에 업무흐름을 시작부터 완료 단계까지 표시하고, 각 단계를 시각화하여 각 업무의 흐름이 원활하도록 유지하는 방법. 업무흐름을 할 일 To-do / 진행 중 In-Progress 또는 Doing / 완료 Done 의 세 가지 상태로 구분하는데, 프로덕트의 실제 개발 흐름에 맞추어 열을 추가할 수 있다. 이때, 진행 중 열에 WIP Limit이라는 진행 중 열에 둘 수 있는 최대할 일의 개수에 제한을 두어서, 진행하는 업무를 우선적으로 빠르게 완료까지 진행하는 것에 집중하게 한다. 할 일이 다음 열의 단계로 이동하여 작업자가 담당하는 일이 없어지면, 작업자는 이전 단계의 열의 최상단(가장 우선순위가 높은 할 일이 최상단에 위치함)에 있는 할 일을 당겨와서 진행한다.

(7) 스크럼 Scrum: 스크럼에서 짧은 주기의 반복적인 개발 주기를 스프린트 라고 하고, 스프린트를 반복할 때 진행하는 스크럼 이벤트 4가지 (스프린트 계획, 데일리 스크럼, 스프린트 리뷰, 스프린트 회고)가 있다. 스크럼 팀에는 3가지 역할 (프로덕트 오너, 개발자들, 스크럼 마스터)이 있다. 이 팀은 스프린트를 진행하는 과정에서 3가지 산출물 (프로덕트 백로그, 스프린트 백로그, 개발 증가분)을 만들게 된다.

 

2. 스크럼 프레임워크로 이해하는 애자일 실천

1) 실전에서 가장 많이 활용되는 애자일 실천 방안

- 스크럼은 일의 콘텐츠를 구체적으로 다루는 것이 아닌, 일을 하는 기본적인 틀만 제시하고 있으면서, 스크럼의 규칙이라 할 수 있는 이벤트들을 담는 그릇과 같은 역할을 한다. 그래서 일 하는 방식에 대한 프레임워크, 즉 스크럼 프레임워크라고 불린다. 스크럼은 어떠한 조직 형태에도 맞춰서 활용할 수 있다.

 

2) 스크럼의 이론적 기반

- 스크럼은 경험주의에 기반하고 있다. 실제 경험한 것을 기반으로 학습을 하면서 변화하는 상황에 적응해 나가는 것이다. 이 때, 팀은 투명하게 상황을 드러내는 것, 발견한 사항들과 실행 결과를 점검하는 것, 학습한 것에 적응하는 것을 핵심으로 운영된다.

 

3) 스크럼의 3가지 역할

- 프로덕트 오너와 스크럼 마스터는 각 한 사람씩, 개발자들은 여러명으로, 팀은 최소 3명에서 최대 9명 정도의 규모이다.\

(1) 프로덕트 오너

- 프로덕트 오너는 스크럼 팀이 담당하는 프로덕트의 모든 권한을 소유하는 역할이다. 프로덕트 오너는 프로덕트의 가치를 극대화하기 위해 할 일을 생성하고 일의 우선순위를 조정한다. 결정을 올바르게 판단하기 위해 유저, 주요 이해관계자, 개발자들과 끊임없이 소통한다.

(2) 스크럼 마스터

- 스크럼 마스터는 스크럼 팀의 팀원들이 스크럼 프레임워크를 올바르게 이해하고 수행할 수 있도록 가이드하고 환경을 조성한다. 스크럼 팀의 팀원들은 모두가 동등한 수평 레벨에서 의견을 제시할 수 있는데, 스크럼 마스터는 스크럼을 수행하는 측면에서는 리더십을 발휘하여 팀을 이끈다. 특히 팀이 가지고 있는 장애물 Impediment를 식별해결하는 것이 중요하다.

(3) 개발자들

- 디자이너, 아키텍처, 프론트엔드 개발자, 백엔드 개발자, QA 등의 모임으로 교차 기능 Cross functional 팀이 되는데, 이들 간에도 서로 간에 가지고 있지 않은 새로운 역량을 학습하는 T자형 인재로 역할을 할 수 있어야 한다.

 

4) 스크럼의 3가지 산출물

(1) 프로덕트 백로그 Product Backlog

- 프로덕트 백로그는 스크럼 팀이 가지고 있는 모든 할 일 목록이다. 프로덕트 백로그에 있는 할 일의 단위를 프로덕트 백로그 아이템 Product Backlog Item이라고 부르고, 프로덕트 매니저는 이 PBI를 가치를 극대화하기 위해 우선순위를 결정한다.

(2) 스프린트 백로그 Sprint Backlog

- 스프린트 백로그는 스크럼 팀이 한 스프린트 동안에 완료할 것을 목표로 선정한 할 일의 목록이다. 프로덕트 백로그의 PBI 중에 우선순위와 개발 순서를 고려하여 스프린트 기간 내에 완료할 수 있을 만큼에 완료해야 하는 만큼을 결정한다.

(3) 프로덕트 개발 증가분 Increment

- 개발 증가분은 스크럼 팀이 스프린트 동안에 완료한 할 일로 인해 생긴, 프로덕트에 새로운 기능이나 변경된 부분을 의미한다.

 

5) 스크럼 5가지 이벤트

(1) 스프린트 Sprint

- 스프린트는 스크럼 팀이 반복적으로 수행하는 일정한 길이의 고정된 프로덕트 개발 주기이다. 일반적으로 1주~4주 정도의 길이 내에서 주 단위로 결정한다. 

(2) 스프린트 계획 Sprint Planning

- 스프린트 계획은 스프린트 1일차에 실행한다. 목표와 목표를 위한 PBI를 파악하여, 스프린트 백로그로 가져온다. 프로덕트 오너는 스프린트 백로그를 구성하기 위해 프로덕트 백로그 아이템의 내용을 팀 전체가 이해하고 있는지 확인하고, 목표와 우선순위 결정에 대해서도 설명한다. 스프린트 백로그를 결정한 다음 개발자들은 이번 스프린트 동안 어떻게 스프린트 백로그 아이템들을 모두 완료할 수 있을지 논의한다. 스프린트 계획은 스크럼 팀의 모든 사람이 함께 하며 4시간에서 최대 8시간 내에 완료한다.

(3) 데일리 스크럼 Daily Scrum

- 스프린트의 2일차 부터 스프린트 완료일까지 매일 한 번 팀의 개발자들이 모여서 진행상황과 계획을 확인하는 이벤트이다. 개발자들에게 가이드를 하거나 도움을 주기 위해 스크럼 마스터가 참여할 수 있으며, 프로덕트 오너도 정보를 얻기 위해 참여할 수 있다. 데일리 스크럼은 15분 동안 진행한다.

(4) 스프린트 리뷰 Sprint Review

- 주로 스프린트 마지막 날에 스프린트 리뷰 이벤트를 열고, 개발 증가분을 확인하면서 피드백과 프로덕트 백로그의 우선순위에 영향이 있는 정보를 수집한다. 프로덕트의 실제 유저와 스크림 팀의 주요 이해관계자를 스프린트 리뷰에 초대하여 의견을 듣는다. 프로덕트 오너는 스프린트 리뷰 동안 얻은 의견을 정리하여 백로그 정리 또는 다음 할 일을 구체화할 때 반영한다. 스프린트 리뷰는 최대 4시간 동안 진행한다.

(5) 스프린트 회고 Sprint Retrospective

- 팀이 일 하는 방식과 문화에 대해서 논의를 한다. 스크럼 팀 모두가 참여하고, 최대 3시간 동안 진행한다.

 

3. 애자일 프로덕트 매니저의 역할과 기술

1) 프로덕트 미션, 비전과 목표를 명확하게 제시하기

- 기업이 가지고 있는 비전과 목표를 상위 조직과 하위 조직들이 서로 동일하게 이해하는 것이 필요하다. 하위 조직의 민첩함, 속도, 성장, 학습을 자발적으로 할 수 있도록 장려하고 동시에 방향과 기대치를 함께 맞추기 위해 사용하는 목표와 기대 성과 전략이 OKR이다. OKR 은 일정기간 (3개월 또는 6개월) 조직 상위에서 목표로 하는 방향과 핵심 지표를 설정하면, 이에 맞춰 단계적으로 하부 조직, 그리고 개인까지 각각의 목표를 설정하게 한다. 조직의 전체 목표를 실질적으로 달성하기 위해 개별 단위로 기여할 수 있는 목표를 명시하는 것이다. 프로덕트 매니저는 프로덕트 단위로 업무를 하는 팀 (스크럼 팀, 스쿼드)이 어떤 목표를 가지고 프로덕트를 성장시켜 나갈 것인지 목표를 설정합니다.

 

2) 애자일 사고방식으로 일 하기 기본

- Being Agile은 ‘우리는 정답을 모른다.’ 를 전제로 하고 ‘프로덕트를 만드는 것은 혼자 할 수 없다.’를 받아들이는 것이다. 우리는 정답을 모르기 때문에 아는 만큼 구체화하고 계획하고 실행한다. 이 작은 단위의 개발을 반복하면서, 실험 결과, 경험, 시간의 흐름으로 인해 새로 알게 되는 것을 계속해서 흡수하고 새로 적용하며 사람과 프로덕트가 함께 성장하는 것이다.

 

3) 프로덕트 목표를 달성하기 위한 개발 계획 수립

- 프로덕트 매니저가 개발자들에게 일정 기간의 전체 할 일을 보여주는 방법 중 User Story Mapping이 있다. 실제 유저, 주요 이해관계자, 개발자들이 함께 참여해 프로덕트 전체 개발 과정을 동일하게 이해하고 정보를 공유하는 것이다. 유저의 입장에서 공감한 것, 정보, Pain Point를 바탕으로 프로덕트의 할 일들을 큰 단위로 나누어 작성한다. 작은 단위의 할 일들도 작성되면, 우선순위 레벨에 따라 위에서 아래로 구분한다. 팀이 가지고 있는 개발주기만큼 어느 정도의 할 일들을 완료할 수 있을지 가정한다. 이 결과가 팀이 함께 공유한 Release Planning 이 된다.

 

4) 스토리 Story - 인수기준 Acceptance Criteria

- 유저의견과 의견을 바탕으로 어떻게 일을 완료할 것인지에 대해 필요한 내용과 기준을 적는 카드를 스토리라 한다. 스토리에는 해당 할 일에 대한 유저의 입장을 이해할 수 있는 유저 스토리가 있습니다. 유저 스토리는 일반적으로 다음과 같은 문법으로 작성합니다.

As …

I want to …

So that …

- 이것을 한글로 작성하면, 유저 ‘누구’ 가 / 무엇을 하고 싶다 / 그럼으로써 얻게 되는 실질적인 영향, 효과를 3 줄로 구분하여 적는 것이다. 누구에는 기존에 세분화 한 유저 페르소나의 특정 대상을 적는다. 무엇에는 유저가 사용할 수 있는 기능 또는 추상적으로 유저가 무엇을 하고 싶다고 한 것인지를 적는다. 마지막은 유저가 이 기능을 사용하게 되면 어떤 것이 가능해지는 것인지, 어떤 목표를 달성하게 되는 것인지를 적는다.

- 스토리 본문에는 유저 스토리 작성 이후에 진행되는 구체화된 내용, 디자인 파일, 팀 또는 유저와의 대화 내용 등을 작성한다. 스토리의 중요한 또 한가지 부분은 인수기준이다. 스토리의 개발을 완료했을 때, 요청한 측이 어떤 기준으로 이것을 인수할 것인지를 체크 리스트 또는 테스트 시나리오 방식으로 작성한다. 인수기준이 없으면, 개발자들은 스토리가 의도하는 목표 수준에 도달하지 않거나 그 이상으로 초과하는 개발을 할 수도 있고, 전혀 다른 방향으로 해결하여 개발을 완료하여, 처음에 팀이 함께 이해했던 스토리와는 다른 결과물로 개발이 완료될 수 있다. 

 

5) 할 일을 작은 단위로 나누기 Story Splitting

- 스토리는 모든 할 일이 하나의 스토리 안에서 이루어 지도록 구성한다. 스토리를 개발하는 과정에서 이 단위의 할 일 내에 기획, 프런트엔드 개발, 백엔드 개발, 테스트와 같은 모든 활동을 하는 것입니다. 이것을 스토리를 수직으로 자른다고 표현한다

 

6) 업무 시각화 Work Visualization

- 시각화는 전체 할 일을 어떤 단위로 나누고, 어떤 상태에 두고, 어떤 순서로 하고 있는지 전체적인 흐름을 쉽게 파악할 수 있게 해 준다. (미로 Miro, 피그잼 FigJam 등) 유저 스토리 매핑, 릴리스 플래닝, 디자인 스프린트, 유저 페르소나 등의 여러 가지 협업 이벤트는 시각화로 업무 효율을 높일 수 있는 활동이다.

 

7) 할 일 우선순위 조정 Work Prioritization

- 우선순위 결정은 시장 상황, 이해 관계자의 의견, 유저의 요청사항, 개발 기술 환경, 가설과 목표 지표 등의 다양한 정보를 종합하여 내리는 판단이며, 프로덕트 매니저 (프로덕트 오너)가 최종적으로 의사결정을 해야하는 중요한 일이다.

 

8) 반복 / 점진적인 개발 수행 Iterative / Incremental Development

- 애자일을 개발 방법론 측면으로 보면 ‘반복적이고 점진적으로 개발을 한다’ 라고한다. 반복적인 개발은 A라는 기능을 개발하는데, 최대한 이른 시기에 개발을 완료하여 내부에서 유저 또는 이해관계자의 피드백을 받는 것이 필요하다. 점진적인 개발은 어떤 경험에 해당하는 기능 수준을 점차 높이고 확장하는 방식이다.