팀스파르타 PM과정 (03)

프로젝트 매니지먼트 개론 강의 수강, 아티클 스터디,  SQL 3강 실습, 피그마 실

---

프로젝트 매니지먼트 개론 강의 ( 프로덕트 개발 과정 )

아티클 스터디 :

스크럼, 입고팀이 애자일하게 일하는 법 1부

https://helloworld.kurly.com/blog/inbound-squad-sprint-1/

[주제]

프로젝트에 모두를 집중시키는 방법 - 스크럼

[아티클 요약]

각자 다른 성향의 사람들이 협업을 할때 스크럼을 기반으로 작업함

도입계기 : 각자 배정된 업무만 진행하다 각종 운영이슈에 대해 대처하거나 서로의 코드를 이해하는 것에 무리가 있었다. 단시간에 목표에 집중할 수 있는 스크럼 도입 

서로 주도적으로 업무에 임하기 위해 업무 규칙(working agreement) 설정

애자일 

- MVP위주로 제품의 핵심기능 우선으로 구현하며 프로젝트를 일정단위로 쪼개어 고객의 니즈나 상황에 따라 민첩하게 대응하는 프로세스 

스크럼

-1~4주의 짧은 단위로 프로젝트를 진행하며 일정시간마다 미팅에서 각자의 업무 진행이나 방향을 주기적으로 확인하며 목표를 향해 진행하는 방법론

 

스크럼팀은 작지만 과제를 충분히 처리할수있을 만큼 커야한다

보통 세가지 구성원으로 나뉜다 

PO	제품의 책임자, 백로그 작성, 제품에 대한 비즈니스 요구를 정의함
스크럼마스터	스크럼이 잘 진행되도록 매니징 함. 각 스프린트별로 처리할 포인트를 산정하고 스크림중 이슈발생시 해결하기위한 중개자 역할, 타 팀과의 커뮤니케이션 역할
개발자	직접적인 소프트웨어 개발자뿐만아니라 메이킹에 참여하는 모든 직군( QA, 기획자, 디자이너)을 뜻함

스프린트	목표를 향해 몰입하는 기간으로 통상적으로 2주를 예상 기간으로 잡는다 스프린트 기간에는 다른 이슈는 중요도를 낮추고 스프린트의 목표 달성에 집중한다
백로그	제품의 백로그 : 제품(예. 입고 서비스)에 부여되는 큰 과제들, 운영 이슈등입니다. PO는 주기적으로 backlog의 우선 순위를 조정합니다. 스프린트 백로그 : 해당 스프린트 내에 진행할 작업 목록입니다. 제품 백로그와 마찬가지로 우선 순위가 높은 순 ~ 낮은 순으로 나열됩니다.
에픽(Epic)	팀 내의 큰 목표 - 신규 프로젝트 - 기존 기능 개선 및 버그 수정
스토리(Story)	에픽 내에는 요구사항 단위, Jira기준 하나의 티켓은 한 개의 스토리만 포함
스토리 포인트(Story Point)	작업의 난이도 입니다. 피보나치 수열을 기준으로 1,2,3,5,8,13 중 고를 수 있습니다. 한 티켓의 포인트가 너무 클 경우, 하위 과제 여러개로 나눌 수 있기 때문에 피보나치 수열을 사용합니다. 예를 들어, 5포인트의 과제는 2,3의 업무로 잘게 나눌 수 있습니다.

 

스토리 리뷰

목적 및 주기 : 개발자가 티켓을 맡아 작업을 시작할때 충분히 요구사항을 이해할 수 있도록 리뷰를 진행합니다.

리뷰 대상 : 신규 개발건 혹은 서비스 운영 중 보고된 이슈,

리뷰 후 모든 개발자가 티켓의 요구사항을 이해하면 티켓에 스토리 포인트를 부여함

 

리뷰진행 방법

1. 요구사항 이해 및 작업의 난이도 측정
   1. 회의전 각 팀원들은 리뷰할 티켓에 대해 미리 읽어 온뒤 티켓 작성자에게 질문하며 이해도를 높인다
   2. 모든 개발자가 티켓의 요구사항에 스토리 포인트를 부여한다
   3. 포인트가 클경우 티켓을 분리하며 기존에 해결한 과제에 상대적으로 점수를 계산한다
2. 백로그에 티켓을 우선 순위대로 나열하기
   1. 리뷰를 마친 티켓은 개발요건이 충분히 검토되었기 때문에 ready for dev 상태로 백로그에 추가
3.  Sprint Planning 
   
   • backlog에 추가된 티켓을 우선순위에 맞게 Sprint에 추가
   • 팀원 각자의 휴가 일정과 이전 스프린트의 스토리 포인트 완료 수치를 근거로 본 스프린트의 목표를 설정
   • 이전 스프린트에서 목표한 스토리포인트 수치가 45였는데, 일정이 남아서 50을 해결했을 경우, 이번 스프린트에서는 47 정도로 팀의 목표를 높게 잡을 수 있다
4. 티켓 할당 - 이전 티켓 종료시
   • 개발자는 backlog의 최상단부터 차례로 티켓을 가져갑니다. 만약 새로 온 신규 입사자나 주니어가 처리하기에 어려운 티켓일 경우 , 개발팀 내 논의 하에 다른 티켓을 할당하는 것도 가능
5. daily stand up
   1. 각자의 이슈를 리포트합니다. 회의 시간은 가능하다면 15분을 넘기지 않아야 합니다. 어제 한 일 / 오늘 할 일 / 이슈 사항을 간단히 공유
   2. 추후 당사자들만 모여 스크럼이후 추가논의 
   3. 일부러 짧게 잡은 회의로 중요한 이야기만 논의하며 이슈를 빠르게 파악한다
6. 배포
   1. 정기 배포로 진행하며 커뮤니케이션 비용을 절감한다
   2. 추가로 발생하는 이슈에 대해 별도의 배포일정을 잡기도 한다 
7. Retro(회고) 
   1. 지난 스프린트에 대해 회고하며 다음 스프린트에 도입해야하는 과정을 논의한다
      • start: 다음 스프린트 시작시 도입되면 좋을 프로세스
      • stop: 이번 스프린트 이후로 하지 않았으면 좋을 내용
      • continue: 이번 스프린트 때 좋았던 내용. 이후에도 지속하면 좋을 것들
8. Social Hour
   
   • 스프린트로 경직되어있던 분위기를 풀고 휴식시간을 가진다 

1.  

[인사이트]

실무에서 실제로 스크럼을 어떻게 활용하고 스프린트를 어떻게 진행하고 있는지 알려주는 글이어서 좋았다

이어진 스크럼에 대한 소감아티클(https://helloworld.kurly.com/blog/inbound-squad-sprint-2/) 까지 이어서 읽었는데 '스프린트 보드'라는 프로그램을 통해 커뮤니케이션 비용을 줄여 팀원들간에 심력소모를 줄일수있는 것이 스크럼의 가장 큰 장점으로 다가왔다 

회고에 대해서도 정해진 피드백시간을 통해 목표달성에 집중하고 구체적으로 피드백에 대해 고민할 수있고 개발자의 주도적인 일정관리가 가능하다는 것에 큰 장점이라고 다가왔다. 친구가 다른 부트캠프 수강시 계속 길을 잃거나 방향을 잃는 프로젝트때 아예 회의시간을 정해두어서 일정관리가 훨씬 수월해졌다는 이야기를 해준것도 생각이 났다. 

추가 궁금증 

스크럼이나 스프린트에 대한 내용을 볼때 하나의 스크럼에 몰입하는 것을 중심으로 진행 되는 것 같은데 업무를 하다보면 여러 종류의 스크럼에 복합적으로 들어가는 경우도 있는지. 이때 PM은 어떤 태도로 임해야하는지

복잡하거나 몰아치는 업무들을 어떻게 현명하게 대처할수있는지 

---

애자일 실전편 

 

“일단 백로그에 넣어두고 여유 있을 때 보는 걸로 할까요?” : 백로그를 백로그로 두지 않는 법

https://techblog.woowahan.com/14484/

문제 정의 지표 설정법

여러 지표를 설정해두었습니다. 첫 번째로 꼭 달성해야 하는 지표(=목표 지표), 두 번째로 이 과제로 인해 떨어지면 안 되는 지표(=가드레일 지표), 마지막으로 반드시 달성해야 하는 것은 아니지만 살펴보면 좋은 지표(=모니터링 지표)로 나누어서 살펴보았습니다.

1. 목표 지표: 거절을 원하는 사람이라면 등록 후 거절보다 등록 전 거절을 선호할 것이다.
2. 가드레일 지표: 거절의 전체 수치는 늘지 않을 것이다.
3. 모니터링 지표: 고객센터로 거절 방법을 문의하는 사람이 감소할 것이다.

 

추가 애자일 프레임 워크 

칸반(Kanban)

스프린트같이 정해진 주기없이 작업 단계별로 관리

지속적인 흐름 관리가 중요하거나, 자주 우선순위가 변경되거나, 유지/운영 보수 관련 업무에서 사용

지라(JIRA)

협업툴 사용 경험을 쌓을 수록 좋음

주로 애자일 개발 프로세스(스크럼, 칸반 등)를 지원하는 프로젝트 관리 툴

과제 

Jira에 가입해서 스프린트를 만들고, 해당 스프린트에 직접 백로그를 등록해보세요.

---

1. 기획

	기획 단계에서 PM 업무
목표수립	✔️ 프로덕트와 상위조직의 목표를 바탕으로, 과제의 목표를 명확히 수립합니다.
문제정의	✔️ 가장 중요한 핵심 문제를 명확히 정의합니다. ✔️ 필요한 경우 UX리서치, 시장 조사 등 각종 방식을 동원해 문제를 발견합니다.
해결안도출	✔️ 문제를 해결할수 있는 최적의 방안을 도출합니다.
문서화	✔️ 디자인, 개발 등 동료들이 요구사항을 명확히 파악할 수 있도록 문서화하니다. (ex.기능정의서, 정책서, 요구사항 명세서, 와이어프레임 등)
이해관계자 파악	✔️ 해당 과제를 진행하기 위해 함께 해야하는 이해관계자가 누가 있는지 파악하고 협업이 원활할수 있는 환경을 조성합니다.

 

2. 디자인

기획내용 공유	✔️ 디자이너들에게 기획 내용을 공유하고 서로 동일한 이해수준을 가질수 있도록 크로스체크합니다.
디자인 이슈 해결	✔️ 디자인 과정에서 이슈가 발견되면, 빠르게 해결하고 우선순위를 재조정합니다.
디자인 일정 관리	✔️ 디자인 진행 상황을 지속적으로 점검하고, 일정에 따라 작업이 원활히 진행되는지 확인합니다.
UX리서치	✔️필요하다면, 디자인을 바탕으로 사용자 테스트 등 UX리서치를 통해 사용자의 니즈를 파악합니다.

 

3. 개발

기획공유	✔️ 개발자들에게 기획, 디자인 내용을 공유하고 서로 동일한 이해수준을 가질수 있도록 크로스체크합니다.
개발이슈해결	✔️ 개발과정에서 이슈가 발견되면, 빠르게 해결하고 우선순위를 재조정합니다. 또는, 기획과 디자인을 논의 후 업데이트합니다.
개발일정관리	✔️ 개발 진행 상황을 지속적으로 점검하고, 일정에 따라 작업이 원활히 진행되는지 확인합니다.

 

4. QA

QA 계획 수립	✔️ QA 엔지니어가 없는 경우, 직접 테스트 케이스를 작성합니다. ✔️ QA 엔지니어가 있는 경우, 기획/디자인 내용을 공유합니다. QA엔지니어가 테스트 케이스를 작성합니다.
QA 진행	✔️ 테스트 케이스를 바탕으로 QA를 진행합니다.
QA 일정관리	✔️ 출시 일자까지 프로덕트의 품질이 유지될수 있도록, QA일정을 관리합니다
버그 리포트 관리	✔️ 발생한 버그 및 이슈를 정리하고, 우선순위를 정하고 이해관계자들에게 공유합니다.

 

5. 출시(릴리즈)

출시 모니터링	✔️ 출시 직후, 데이터 수집은 잘 되는지 장애나 버그가 발생하진 않았는지 모니터링합니다. ✔️ 만약 장애 등 문제가 생기면, 이전으로 롤백을 하기도 합니다.
사용자 반응 분석	✔️ 오픈 후 데이터를 분석해 출시 이후 사용자 반응을 분석합니다 ✔️ 분석한 인사이트를 기반으로 개선점 등은 다음 과제로 진행합니다.

---

실무에서 PM이 겪는 문제와 해결 방법

 

왜 PM을 하고싶나

1위. 내가 만든 제품이 세상에 나오는 게 좋아요

2위. 새로운 걸 기획하는 걸 좋아해요

3위. 리딩하는 역할을 하고 싶어요

4위. 다양한 사람들과 소통해서 결과물을 내는 게 즐거워요

↓

나는 ? 

새로운걸 기획하는걸 좋아하고 기존에 있던 컨텐츠를 활용해서 또다른 창작을 하는 것이 즐거웠다 

누군가 내가 기획한 것을 체험하고 원하는 반응이 나오는 것이 좋았음

기획서를 작성하고 기획에 맞게 사람들을 배치하는 것도 재밌었음

현장에서 매뉴얼을 기반으로 현장에 맞게 조정하고 문제를 해결하는 것도 즐거웠음

처음 하는 업무도 하나하나 체계를 만들어가면서 진행하곤 했음

스토리텔링적 흐름을 좋아함 

 

경험

보통 하나의 테마에 맞게 처음부터 끝까지 구성하며 체험형 콘텐츠를 제공함

(게임 단간론파 기반 동인 행사 https://x.com/VrMonobox?s=20)

게임시스템 구축을 위해 노코드 툴을 활용하여 간이 게임을 기획하고 제작하고 어울리는 이미지를 찾아 적용하고 테스트하는 것까지 (https://vrmonobox.waveon.io/  모바일 최적화)

처음부터 끝까지 핸들링해봤던것

중간에 현장 스탭으로 현장을 관리 해봤던것

 

하나의 행사가 잘끝나고 참가자들이 콘텐츠를 잘 즐기고 좋은 기억으로 남는 것이 좋았음

규모가 클수록 내가 핸들링한 영역에서 민원이나 큰 오류가 발생하지않는 것이 좋았음