[TIL-230729] 프로덕트 설계 5일차

 

 

 

출처

[새싹X러닝스푼즈] 유니콘 기업 현직자에게 배우는 IT 서비스 기획자 취업 캠프

프로덕트 설계 강의 (김승현 강사님)

 

 

공부한 내용

PM의 일 = 매우 많다

 

  프로젝트 관리  

PMP 자격증

- 프로젝트 관리 지식 체계: PMBOK

- 미국 PMI 협회 제공, 한국어로도 제공

- 금융쪽에서도 선호하는 자격증

- 경력 5년이 있어야 함

- Agile 방법론에 대한 자격증: PMI-ACP, PRINCE2

 

 

소프트웨어 프로젝트 관리

- 프로젝트에서 업무 범위, 일정, 비용을 관리하는 것은 매우 중요하지만 초기에 정한 목표를 무조건 준수해야 하는 것은 아니며, 시장 및 고객에게 무엇이 가치가 있는지에 따라 신축성있게 조정하는 것이 필요

- 요구사항 정의 확정 후에도 변동 가능성 큼 -> 상세 디자인 완료 후에야 조금 줄어듦

 

- 열심히 개발했는데 나중에 안쓰는 경우도 많다 -> 최소화해야 한다

- 프로젝트 초기에 구체적인 요구사항 도출이 어렵다

- 중간에 발생하는 요구사항 변경 반영이 어렵다

 

 

소프트웨어 개발 방법론

 

1. 폭포수(Waterfall)

2. 나선형(Spiral)

3. 애자일(Agile)

- 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기(iteration)를 반복하는 개발 방법론

- 애자일 기법: DSDM, Scrum, XP, Kanban

 

 

Agile

- 프로세스와 도구보다는 개인과 개인간의 상호작용에 더 큰 가치를 둔다

- 포괄적 문서화보다는 동작하는 소프트웨어에 더 큰 가치를 둔다

- 계약 협상보다는 고객과의 협력에 더 큰 가치를 둔다

- 계획을 따르기보다는 변화에 대응하는 것에 더 큰 가치를 둔다

 

Agile 원칙

1. 초기부터 지속적으로 고객 만족

- 초기부터 개발물을 제공하는 것이 risk 감소, value 증가

 

2. 요구사항 변경 수용

 

3. 짧은 배포 간격

 

4. 기획자/현업과 개발자는 함께 일하기

 

5. 동기부여된 팀원들로 프로젝트 팀 만들기

- 개발 일정을 개발자가 직접 정한다

 

6. 얼굴 보고 대화하기

- 개발팀에 정보를 전달하는 가장 효율적+효과적 방법

 

7. 동작하는 소프트웨어로 진도 측정

- 80% 인정 안함, 동작하는 소프트웨어만 인정

 

8. 지속가능한 개발 속도 유지

- 시험기간 효과, 마라톤 효과

 

9. 좋은 기술, 설계에 관심

- 우수한 기술과 우수한 디자인에 대한 지속적 관심은 민첩성을 향상시킴

- 바빠서 기술적 개선을 하지 못한다면, 항상 바쁘기 때문에 영원히 뒤처짐

 

10. 단순성

 - 중요하다

 

11. 자기 조직화 팀

- 지시를 받아 일하는 것이 아닌, 수동적인 일하기- 개인의 책임과 자유에 의존

 

12. 정기적으로 효율성 제고

- 매너리즘에 빠지지 않도록 정기적으로 효과적인 방법 적용해보고, 그에 따라 행동을 조율하고 조정

 

 

Agile 방법론에서 PO의 역할

- 제품을 사용할 고객과 사용자의 니즈를 수렴하여 최종 요구사항을 결정

- 업계의 동향, 경쟁사의 움직임, 새로운 아이디어 등을 지속적으로 관찰하여 제품에 반영- 각종 계획과 리뷰 미팅에 참석하여 개발팀에 피드백 제공- 주기적으로 요구사항의 우선순위를 갱신하고 제품 테스트 수행- 제품의 완료 조건을 작성하고 최종 제품인수

 

-> 모두 하는 슈퍼맨이 되어야 한다

 

 

  Scrum  

- 소규모의 교차기능팀(10인 이하)이 제품개발을 위해 스프린트라고 불리는 업무 주기를 반복

- 애자일의 하위 개념, 구체적 기법

 

- CSM(Certified Scrum Master): 공인 스크럼 강사가 가르치는 2일간의 CSM 과정 참여 후 시험

 

출처: [새싹X러닝스푼즈] 유니콘 기업 현직자에게 배우는 IT 서비스 기획자 취업 캠프 프로덕트 설계 강의 (김승현 강사님)

3 Roles

- Product Owner

- Scrum Master

- Developers

 

5 Events

- Sprint: 약 3주의 반복 주기(15일)

- Sprint planning: 스크럼 첫날

- Daily Scrum

- Sprint Review: 마지막 날, 결과물 리뷰

- Retrospective: 회고

*Backlog Refinement: PO가 상시적으로 챙겨야 하는 이벤트(언오피셜)

 

3 Artifacts(산출물)

- Product Backlog: 제품 전체의 기능 목록, PO가 관리

- Sprint Backlog: 이번 스프린트에서 할 기능의 목록, 개발자가 관리

- Product Increment: 개발자들이 스프린트를 통해 만들어낸 제품, 개발자가 생산

 

 

Scrum 구성원

 

1. PO: 제품의 가치 관리

- 프로덕트 백로그를 효과적으로 관리

- PBI(Product Backlog Item) 관리

 

2. Scrum Mater

- 팀원들이 자율관리를 하고 교차기능적이 되도록 코칭

- 스크럼 팀의 진척에 방해가 되는 장애물 제거

 

3.  Developers

- 사용 가능한 증가분의 모든 부분을 만드는 것에 전념

- 스프린트 동안의 계획을 세움

- 완료의 정의(Definition of Done DOD)를 준수하여 품질을 높임

 

 

Scrum 산출물

 

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

- 프로덕트를 향상시키기 위한 업무를 우선순위에 따라 정렬한 목록

- 개발자들은 PBI의 크기를 결정하는 데 책임을 짐

- PO는 개발자들이 절충안을 이해하고 선택하도록 도움을 줌

 

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

- 스프린트 목표, 스프린트를 위해 선택된 프로덕트 백로그 아이템들의 모음, 증가분을 전달하기 위한 실행할 수 있는 계획으로 구성

- 개발자들에 의한 개발자들을 위한 계획

- 데일리 스크럼 때 진척을 확인할 수 있을만큼 세부 내용이 충분해야 함

 

3. 프로덕트 증가분(Product Increment)

- 하나의 프로덕트 백로그 아이템이 완료의 정의(DOD)를 충족하는 상태를 나타냄

 

*DOD: 완료의 기준이 무엇인인가? -> ~를 했으면 구현이 완료된 거야! 라는 기준의 정의

- AC: Acceptance Criteria

출처: [새싹X러닝스푼즈] 유니콘 기업 현직자에게 배우는 IT 서비스 기획자 취업 캠프 프로덕트 설계 강의 (김승현 강사님)

- 어떤 유저 스토리든 이 조건을 충족해야 '완료'했다고 할 수 있다고 합의

 

*backlog(백로그): 개발해야 할 기능 또는 제품에서 요구하는 기능과 우선순위

 

 

  Kanban  

- 진행 중인 업무의 개수를 제한해서 업무의 처리 속도를 유지하는데 초점을 맞춤

- 스프린트와 같이 정해진 기간이 없음

 

- 스크럼: 신규 서비스 개발과 같이 프로젝트의 시작과 종료가 뚜렷한 경우

- 칸반: 지속적이고 반복적인 운영 이슈 대응 및 기능 개선

 

Hotfix 대응: 긴급한 이슈(예: 앱 배포 후 앱 크래쉬가 리포트 됨) 

- 스크럼: Hotfix를 해당 스프린트에 넣지 않고(중간에 반영하지 않음), 다음 스프린트의 백로그로 쌓음

- 칸반에서는 Hotfix를 바로 백로그에 넣어서 대응

 

 

  실전 Scrum  

 

실습: 택시 합승 UI/UX 개선

0. 팀 구성 및 역할 정하기

 

 

1. 프로덕트 백로그 작성

- 제품 개발팀이 모여 사용자/기술 스토리를 기반으로 우선순위 정리하여 전체 범위 협의

- 사용자 스토리: (누가) (비지니스 가치)를 위해 (어떤 기능)을 원한다.

- 기술 스토리: 사용자 스토리를 지원하는 기술/관리적 업무 / 비기능적 요구사항, 인프라 시스템 개선 활동, 코드 리뷰, 리팩토링, 버그 수정 등

 

우선순위 분류: MosCow

- 필수(Must have): 시스템 필수 사항. 법적/비지니스 가치 전달. 시스템 안정에 필수적인 기능

- 중요(Should have): 유용하고 중요하지만 필수 사항은 아님. 경영자 기대사항, 효율성 향상, 차선책이 있는 기능

- 선택(Could have): 다음 릴리즈로 넘겨도 크게 문제가 없는 사항

- 보류(Won't have this time): 이번 릴리즈에 포함하지 않기로 결정한 사항

 

 

2. 개발 규모 측정

(1) 스토리 포인트

- 요구사항의 규모를 측정하는 단위, 복잡도를 감안한 업무량

- 공수가 가장 적게 드는 스토리를 1점으로 하고, 상대적 개념으로 점수 부여

 

(2) 유사 추정

- 과거에 수행했던 유사 프로젝트의 규모, 일정, 비용, 투입공수, 복잡도 등의 정도 기반으로 추정

 

(3) 플래닝 포커

- 프로덕트 백로그에서 유저 스토리를 나열

- 각 스토리 별로 PO가 설명

- 진행자의 진행에 맞추어 개발자가 포커로 투표

- 가장 높게 투표한 사람과 가장 낮게 투표한 사람의 설명을 들음

- 대략적으로 비슷한 일정으로 수렴할 때까지 재투표

 

 

3. 전체 일정(Release Plan) 수립

- 스프린트 기간 설정

- 평균 개발 속도 추정

- 전체 일정 추정

 

 

4. 스프린트 실행

다음 게시글에 작성 예정

 

 

5. 스프린트 회고

스프린트 기간 동안 각자가 겪은 다음의 내용들에 대해 회고 및 작성 시간 부여

- 이번 스프린트 동안 효율적이거나 좋게 느껴졌던 활동은?

- 이번 스프린트 동안 비효율적이거나 좋지 않게 느낀 활동은?

- 제품 개발 과정에서 우리가 놓치고 있는 것은?

- 이번 스프린트 동안 내가 새롭게 알게 된 사실은?

 

개선점 찾기

- 스프린트 기간 동안 발생한 문제의 원인을 분석하여 개선점 찾기

  - 이번 스프린트 목표를 달성하지 못한 원인은?

  - 업무 수행 중에 발생한 이슈나 문제점의 원인은?

  - 업무를 좀 더 효과적으로 수행하려면 개선할 점은?

  - 좀 더 즐겁게 일할 수 있는 방법은?

 

팁

- 회고는 팀원 자신이 느낀 점 위주로 이야기하도록 진행하며, 업무의 논의나 논쟁이 이어지지 않도록 주의

 

 

 

프로젝트 관리 Tool

- Jira: 개발+기획 분야에서 많이 사용

- asana: 직관적 UI, 비개발직군에서도 사용

- Trello: 소규모/개인용으로 적합