[Chapter 08-02] 서비스 기획업무 A~Z(애자일 방법론)

1️⃣ 애자일 방법론이란?

최소 기능 제품으로 빠르게 개발하여 유저들의 피드백을 받고, 해당 피드백을 바탕으로 지속적으로 개발하는 방법론

 

🔷 특징

• 지속적으로 사이클이 돔
• 한 팀에 여러 직무가 들어가 있음
• 지속적으로 진회
• 고객의 피드백을 최우선

 

🔷 장점

• 잘못된 제품을 개발하는 시간을 최소화
• 유저의 피드백을 얻어 개선하기때문에, 실패 확률을 낮출 수 있다.
• 계획 혹은 기능에 대한 수정과 변경을 유연하게 대처 할 수 있다
  • 타다 - 타다와 비슷한 서비스 개발 중 관련 법안에 생겼을 때

 

🔷 단점

• 요구사항이 명확할 경우, 워터폴에 비해 오히려 속도가 느리다.
• 최종 제품이 요구사항과 달라질 수 있다.
• 고객에게 제공하는 가치에 집중하기때문에, 기술적 완성도가 떨어 질 수있다.

 

---

2️⃣ 애자일에서 일을 쪼개는 단위

유저에게 제공할 수 있는 가치 단위로 쪼갬

Theme > Epic > Story > Task

• Theme :
  • 모바일 배달음식 플레폼
• Epic
  • 고객은 배달음식점의 리뷰를 본인에 맞춰 개인화함 확인 할 수 있다.
• Story (기본단위) : 고객의 행동을 나타냄
  • 고객은 배달 음식점의 사진리뷰를 모아 볼 수있다.
• Task : Story를 가능하게 하기위해 직접 해야하는 업무
  • 사진리뷰 필터 구현

🔷 서비스 기획자의 업무

1. 특정기간동안 어떠한 Story를 개발할 것인지 작성하고, 그를 위해서 어떤 작업을 해야하는 지 파악해 Task를 생성하여 담당 개발자에게 할당.
2. 정기 미팅에서 Task 진행상화을 파악.
3. 완료 후 배포한 다음 제품에 어떤 변화를 줬는지 수치화하여 개발팀에게 공유

당근 마켓 아르바이트 중개 기능

Theme:지역기반중고 거래 플랫폼에서 지역기반 종합 플랫폼으로 확장

Epic : 유저 지역기방의 아르바이트 중개 기능을 사용할 수있다

Story

1.  사장님들응 아르바이트 공고를 작성할 수 있다.(핵심)

2. 일반 유저는 아르바이트 공고를 확인할 수 있다.(핵심)

3. 일반 유저는 아르바이트 공고를 선택하여 열람할 수 있다.(핵심)

4. 일반 유저는 아르바이트 공고를 시급별, 업무별 필터링 할 수 있다.

5. 일반 유저는 원하는 아르바이트 공고를 저장할 수 있다.

6. 일반 유저는 원하는 아르바이트 공고에 지원할 수 있다.

Task

1. 아르바이트 공고 페이지 개발

2. 아르바이트 공고 리스트 개발

3. 아르바이트 공고 디페일 개발

 

---

3️⃣ 대표적 애자일 방법론 - 스크럼

관리 도구가 아닌 진행 도구임!

모든 팀원이 한 덩어리로 뭉쳐서 업무진행의 형태

 

🔷 스크럼의 활용 시점

다소 불확실하고 복잡한 일

 

🅰 스크럼 전 프로세스

🔷 Backlog 관리

• 제품개선을 위해 진행되어야하는 다양한 요구사항
• 제품 관련 다양한 인원으로부터 수집
• 요청자, 백로그 생성이유, 추정시간, 요구명세 등 다양한 내용 포함
• 우선순위는 반드시 포함

📌 작성 법

• 요구사항을 작성하되, 구체적인 실행방안에 대해서 작성하지 않아도 됨(개발팀이 하는게 더 효율적)
• 백로그 진행이 중요한 이유에 대해 자세히 작성할수록 우선순위 산정 및 제품 개발에 용이

 

🔷 스프린터 전 프로세스

❓ Sprint 란?

• 통상 1~4주 정도의 Time box를 가진 개발 주기(주로 2주, 팀의 생산속도가 높거나 제품개선을 빠르게 반영할 수 있을수록 짧게 가져 감)
• 각 Sprint 단계 종료 시 새로운 기능이 추가되어 제품에 반영되는 것을 목표로 함
• Scrum은 Sprint를 반복하며 제품을 개발 및 개선해나가는 과정

❓ Sprint Planning Meeting 란?

• Backlog들 중 이번 스프린트에 어떤 백로그를 진행할지 모든 침원들이 함께 논의하는 회의
• Product Owner는 독단적으로 목표를 설정해서는 안됨(모든 팀원들의 의견을 충분히 반영)
• Sprint Planning Meeting을 통해서 적당할만큼 Sprint Backlog를 선정(너무 많으면 스프린트 내 목표달성이 어려움 적으면 생산성이 낮아 짐)
• 보통 Sprint Backlog는 일단 Sprint가 시작된 이후에는 변경하지 않을 것을 원칙

 

🔷 스프린트 진행

📌 Scrum Master

• Sprint의 진행상황을 검토하고, 목표 달성에 위협이 되는 사항들을 확인하여 해결하는 역할
  • 서번트 리더십이 필요 (경청, 공감, 치유, 스톰어드심, 직원의 성장, 공통체 형성)
• 커뮤니케이션 이슈, 우선순위 선정에 대한 이견 등 모든 문제들을 조정하는 역할
• 보통 Scrum Master를 따로두는 기업보단 PM, PO가 이역할을 병행

 

📌 Daliy Scrum Meeting

• 매일 15분씩 진행되는 짧은 미팅(길어진다면 점점 팀원들에게 부담이됨)
• 스프린트가 목표에 맞게 진행되고 있는지, 백로그에 있는 작업이 잘 완성되고 있는지 검토
• 개발팀이 스프린트 목표를 달성할 수 있는 확률을 최적화
• 전체 개발이나, 팀원들은 종종 일일 스크럼 미팅이 끝나자마자 더 상세한 의논을 하거나 스프린트 작업에 대한 조정 및 재계획을 하기 위하여 추가적 미팅을 할 수 있음
• 스크럼에서 주요확인 사항
  • 나는 어제 하루동안 개발팀의 스프린트 목토 달성을 위해 무엇을 했는지?
  • 나는 오늘 하루동안 개발팀의 스프린트 목토 달성을 위해 무엇을 할 것있지?
  • 나 혹은 개발팀이 스프린트 목표 달성을 하는데 방해요소가 있는지?(팀원에게 문제가 있다면 그것을 해결)

 

🔷 스프린트 후 프로세스

📌 스프린트 리뷰

• Sprint를 통해 무엇이 완료되었는지 팀원과 이해관계가들이 모여 확인(개발 제품 대모를 보여주는 등으로 유저에게 전달된 가치, 기능을 왜 개발했는지와 얻고자 하는 효과를 잘 설명)
• 리퓨 결과와 스프린트 수행 중 변경된 백로그를 고려하여 다음에 무엇을 할지 함께 의논
• 경과보고를 위해 미팅이 아닌, 스프린트를 통해 완료된 개선사항을 발표함으로써 피드백을 받고 협력을 촉진하기위한 회의

서비스기획자는 스프린트 리뷰를 하면서 팀원들이 해낸 사항들을의 중요도, 성과, 기대 성과들을 쉽고 명확하게 전달하는 것이 중요, 받은 피드백을 논리적으로 정리하고 이를 바탕으로 액션아이템을 뽑아낼 수 있어야함

 

📌 스프린트 회고

• 스프린트 회고 미팅은 팀이 다음 스프린트 동안 무엇을 개선할 수 있을지 계획할 기회를 제공
• 스프린트 리뷰 미팅 후 / 스프린트 플래닝 미팅 전에 수향함
• 회고의 목적 (이후 효율성 극대화)
  • 지난 스프린트가 사람, 상호관계, 프로세스, 도구 측면에서 어떻게 진행되었는지 검토
  • 잘된것들과 개선의 여지가 있는 항목을 알아내고 우선순위 설정
  • 개선을 실천할 수 있도록 계획 수립

 

📂 회고 방법론

.🔸 KPT

Try는 구체적이고 실행가능해야한다.

- 개발자가 개발 전에 기획서를 디자이너와 개발자에게 충분히 리뷰받는 프로세스를 만들어 보자

서비스 기획자는 Try를 그룹화하여 다같이 다음에 적용이 시급한부분에 우선순위를 정해야 함

 

---

4️⃣ 칸반

🔷 칸반의 유래

도요타 생산 시스템에서 영함을 얻음

적시 생산방식 : 전 단계의 부품 재고를 쌓는 것을 막기위해 필요한 만큼 부품을 적시에 만들기위한 노력

필요한 개수의 차 개수를 보내고 필요한 수량의 재고를 자동차를 생산하여 판매

 

📌 소프트 웨어 적용

• 오른쪽(시작) -> 왼쪽(끝)
• 개발, 코드리뷰, 테스팅, 배포마다 가지고 올 수 있는 업무 개수가 정해져 있음
• 특정 단계에서 작업이 완료되면 Pull하는 방식으로 진행

 

🔷 칸반 실천 방법

🔸 시각화

• 보드와 카드로 구성
• 끝 지점에선 작업내용이 유저에게 전달되고 의미있게 제공되어야 함
• 카드는 작업 단위로 보통 Story, Task, Subtask등으로 구성
• 열을 프로세스 단위
• 스윔레인
  • 열 안에 행 
  • 만약 Story라면 Epic이 될 수 있음
  • 업무 담당자를 넣을 수도 있음
• 각 단계사이에 진행 중 업무 WIP(Work In Progress) 제한이 표기되어 있어야함
• 열을 옮기기 전 완료되어야 하는일이 무엇인지 명확해야함
  • 코드가 완료된 시점인지, github에 올린 시점인지 등

 

🔸 WIP를 제한

• Push가 아닌 Pull형으로 업부가 진행되어야함
• 부분적으로 완료된 업무들을 최소화 업무가 많아져서 생기는 낭비를 줄이고 완성된 상태의 상품만을 빠르게 만들어 고객에게 배포되는 주기를 줄임

 

🔸 흐름을 관리

• 업무 흐름이 완성된 가치 생산을 최대화하도록 지속적으로 관리
• 완성 제품이 생산될때까지의 리드타임을 줄이고, 가능하면 걸리는 시간이 예측 가능해야함
• 특정 업무가 전체의 흐름을 막을 경우, 해당 업무 흐름 개선을 위해 다같이 논의하여 효율을 높혀야함

 

🔸 정책을 명시화

• 정책을 명시화하여 모든 구성원들이 동일한 방식으로 일하는것이 중요
• 다만, 정책이 맞지 않다면 토론을 통해 유연하게 정책을 변경/개선하여 최적화를 해야함
  • WIP의 제한도 정잭 중 하나
  • 각 열의 완료의 정의도 정책 중 하나

 

🔸 피드백 루프 실행

• 지속적으로 리뷰를 진행하여 칸반 시스템을 팀에서 잘 활용할 수 있도록 개선해야 함
  1. 전략 리뷰 
     • 프로젝트 전략 리뷰
     • 외,내부 상황과 경쟁자를 보며 옳은 프로덕트를 만들고 있는지 확인하고 그에따른 전략을 세움
  2. 운영 리뷰
  3. 위험 리뷰
     • 어떠한 프로세스가 지속적으로 흐름을 막는다면 원인 파악 및 개선하기 위한 회의
     • 보통 먼슬리로 진행
  4. 서비스 제공 리뷰
  5. 재보충 리뷰
     • 어떤 신규 업무를 todo에 넣어 칸반보드에서 작업을 진행할지 회의
     • 스크럼의 Sprint Planning Meeting과정이라고 생각하면 됨
     • 보통 위클리에 한번 진행
  6. 칸반 미팅/리뷰
     • 스크럼의 데일리 스크럼과 유사한 과정
     • 어떠 열에서 병목 현상이 발생했는지 확인하고 해당 팀들이 서로 도움을 줄 수있겠금 기회를 제공하는 화의
     • 15~30분 사이로 진행
  7. 제공계획 리뷰

 

🔸 함께 개선하고 실험을 통해 발전

• 규범에 얽메이지 않고, 조직의 상황에 적응하며 발전, 경험을 통해 조직에 맞는 최선을 찾는 것이 중요
• 조직의 형태에서 시작해서 지속적, 점진적으로 개선을 추구

 

🔷 칸반이 장단점

🔸 장점

• 규범이 많지 않아, 도입하기 용이(업무 시각화로 시작해서 스크럼 등 늘여가는 방식)
• 데드라인이 존재하지 않아, 스크럼에 비해 조직원들이 속도에 대한 압박감이 덜 함
  • 대신, 서비스 기획자는 생산성이 낮아지지 않도록 흐름을 잘 관리해야함
  • 각 카드가 끝날 때까지 걸리는 시간, 병목되는 장소등을 파악하여 지속적인 개선이 필요함
• 스크럼의 Sprint Planning Meeting등 반드시 수행하여하야는 미팅이 없어 시간 리소스 낭비가 적어짐
• 병목 지점을 명확하게 파악할 수 있어 개선에 용이
• 스크럼의 스프린트처럼 기한내에 일을 마무리하지 않아도 되어, 저품질 상태의 배포가 최소화

 

🔸 단점

• 규범이 적어, 성숙하지 못한 팀원들이 있다면 생산성이 떨어짐
  • 서비스 기획자는 규범을 적절하게 정하여 아노미 상태를 막아야 함.
• 스프린트 안에서 일을 완료해야한다는 압박감이 없어, 프리라이더가 많거나 실천문화가 약하다면 생상성이 떨어짐
  • 서비스 기획자는 팀원을 관찰하여 생산성을 방해하는 팀원이 있는지, 있다면 미팅을 통해 흐름을 개선

 

🔷 반칸과 스크럼의 차이점

	스크럼	반칸
역할 지정	정해짐. 스크럼 마스터, 개발팀, 제품 책임자 등..	지정하지 않음. 팀원 개개인이 자신의 기능에 맞춰서 역할을 정함.
이터레이션(스프린트)	기간이 정해진  스프린트를 반복.	기간을 따로 정하지 않음. 배보 가능한 기능이 완성 될 때마다 배포, 다음 개발 사항을 새로 갖져옴
WIP	제한하지 않음. 스프린트 백로그의 양을 조절하며 팀의 제품 개발 속도를 측정.	제한함. 이터레션을 사용하지 않아 WIP제한하여 속도 조절 및 파악.
스프린트 변경	스프린트가 시작되면 백로그는 원칙적 변경 불가	언제든지 작업 추가, 수정가능
보드 초기화	매 스프린트마다 보드가 생성 진행 사항들을 보드에 넣어두고, 그 전에 끝내지 못한 사항은 다시 백로그로 보냄	지속적으로 유지

 

🔷 칸반을 운영하는 조직

1번, 2번

3번, 4번

빨강 - 서비스 기획자
파란색 - 개발자
초록색 - QA

• 서비스 기획자는 백로그들을 파악하여 우선순위 지정
• 백로그에는 WIP제한은 없음
• 우선 과제 (2)
  • 서비스 기획자는 충분히 유저 스토리(기획서, 디자인)를 구체화하여 바로 개발을 할 수 있도록 만든다.
  • 즉, 내외적 시장상황 등이 계속 변화하니 모든 스토리를 한번에 구제화할 필요 없다.
• 개발 (2->3)
  • 진행중 -> 완료
  • 팀을 유기 적으로 변경
• 배포 (1)
  • 전체 흐름을 위해 어느 팀이든 잘 해결되지 않는 문제가 있으면 도움을 주고 받을 수 있음.
• 라이브