[코드스테이츠 PMB 9기] 스크럼(Scrum), 스프린트(Sprint), QA

PM과 스크럼

 

워터폴 방식의 특징

• 초기에 미리 정의된 요구사항
  • 미리 요구사항을 파악하고 프로젝트 전체에 대한 분석이 가능
• 큰 릴리즈
  • 정형화된 프로세스에 따라 주기 별 릴리스, 전체적으로 큰 부분만 릴리즈(배포)하게 됨. 그래서 업데이트가 비교적 느림
• 계획중심
  • 프로젝트에 대하여 완벽한 계획을 수립하고 진행
• 적은 의사소통
  • 문서 중심의 방법론으로 문서에 근거하여 프로젝트를 수행: 문서 중심
• 단계별 산출물 전달(디스커버 – 디자인 – 디벨롭)
  • 계획 중심적 방법론으로 정해진 단계가 완성됨에 따른 산출물 전달
• 마지막 통합
  • 초기 계획이 완전하다는 가정하에, 중간 통합 없이 최종 프로세스 수행 후 통합 후. 문제점 도출 및 해결

 

애자일 방식

• 프로젝트 과정에 걸쳐 생기는 요구사항
  • 미리 모든 요구사항을 알 수 없다는 가정하에 시간적 변화를 인지하고 지속적으로 요구사항을 수렴
• 작고 빠른 릴리즈
  • 고객이 원하는 것을 파악하여 가능한 빨리 니즈를 충족 시키는 것을 중요시
• 학습 중심
  • 최소한의 지식으로 시작하여 단계를 거듭, 학습. 워터폴은 모든 것을 알고 있고 그를 바탕으로 계획을 하는 편인데, 애자일은 작고 빠른 런칭을 통해 개선 사항을 도출하고 발전해 나간다. 최소한의 지식으로 학습하며 발전한다.
• 많은 의사소통
  • 프로젝트 팀 간, 고객 간의 많은 의사소통으로 진행되는 프로젝트: 사람 중심
• 지속적인 산출물 전달
  • 프로젝트 진행 중 잦은 산출물 공유로 수정사항에 빠르게 대처
• 잦은 통합
  • 기능별 완료 시기에 맞춰 잦은 통합과 문제점 도출 및 해결

---

 

QA

 

QA(Quality Assurance)

• 제품의 품질을 안정화시키고, 유지보수, 개선과 관련된 모든 업무를 아우르는 상위 개념
• 프로덕의 변경 포인트와 요구사항을 분석 및 검토, 리스크 및 테스트 컨디션을 파악해 시험 계획 수립
• 잠재적인 문제를 발견하기 위한 테스트 케이스 수립, 버그를 찾아내 그 이력을 관리하는 역할을 함
• 이를 기반으로 유관 부서들과 커뮤니케이션하는 것까지 진행하는 업무가 포함

 

QA 과정에서 진행되는 업무

1. 기획 문서 리뷰
   1. 기획서 리뷰하며 질의 응답을 통해 충분히 논의해 최대한 버그 발생을 요인들을 점검하고 예방
      1. 기획 명세서에서 빠진 내용은 없는지
      2. 이해하기 어려운 부분은 없는지
      3. 오해로 인한 버그 발생의 요소는 없는지 등
2. 플로우 차트 및 테스트 케이스 작성
   1. 기획서를 기반으로 하여 플로우 차트를 그리기
   2. 기획 단계에서 생각하지 못한 시나리오를 점검
   3. 해당 차트를 기반으로 테스트 케이스를 작성
3. 내부 리뷰
   1. PM, 개발자, QA 등 프로덕트 팀이 테스트 케이스를 점검
      1. 잘못된 요구 사항은 없는지
      2. 이해로 인한 오류는 없는지 등 확인
   2. 프로덕트 관점에서의 기술 정의를 문서화해, 커뮤니케이션의 도구로 사용
4. 테스트 케이스 수행
   1. 테스트 케이스를 수행하며 Pass/Fail 여부를 확인

 

스프린트

 

스프린트(Sprint)란?

• 스프린트는 꾸준함 보다는 한달 혹은 더 짧은 몇 주의 기간에 고정된 이벤트 프로세스
• 새로운 스프린트는 직전의 스프린트가 끝나는 즉시 시작되며 계속해서 이어짐
• 스프린트 기간을 너무 길게 잡으면, 스프린트 목표가 효력이 없어지거나 복잡도가 늘어나고 리스크가 높아질 수 있음
• 반면 더 짧은 스프린트 기간일수록 더 많은 학습 기회를 가질 수 있고, 짧은 기간 동안 수행하는 비용과 노력으로 리스크를 한정시킬 수 있음

 

스프린트 플래닝

• ‘스프린트 플래닝’. 스프린트 계획을 통해서 스프린트 동안 수행할 업무를 선정
• 작성된 백로그 중, 우선순위/중요도/시급도에 따라, 이번 스프린트에 진행할 일감 선정
• 프로덕트 오너는 프로덕트 목표를 달성하기에 중요한 요소를 파악하고 그것이 프로덕트 목표와 어떻게 연결되는지 충분히 이해해야 함

 

스프린트 플래닝 주제

• 이 스프린트가 어떤 가치가 있는가?
  • 모든 팀원들이 스프린트의 목표를 정의
  • 해당 스프린트가 중요한 이유를 담아야하고, 스프린트 목표는 스프린트 플래닝을 마치기 전에 결정되어야 함
• 이 스프린트의 완료(done)은 무엇인가?
  • PO는 개발자들과 함께 해당 스프린트에 포함될 프로덕트 백로그 아이템을 설정하게 됨
• 선정한 업무를 어떻게 완료할 것인가?
  • 개발자들은 일반적으로 프로덕트 백로그를 하루 단위로 더 잘게 세분화해 필요한 업무들을 계획
  • 중요한 것은 이 과정은 절대적으로 개발자들이 정해야

 

데일리 스크럼

• 목적 : 스프린트의 진척을 점검하고, 필요에 따라 다음 업무 진행 계획을 변경하여 스프린트 백로그 조정
• 데일리 스크럼은 스크럼 팀의 개발자들만 참여하는 15분 내외 길이의 이벤트
• 이 미팅은 같은 시각에 같은 장소에서 스프린트 기간 동안 매일 진행
• 개발자들은 어떤 방식이나 기법으로도 데일리 스크럼을 진행할 수 있음
• 만약 프로덕트 오너나 스크럼 마스터도 스프린트 백로그 아이템을 맡아 활동적으로 업무를 하고 있다면 개발자들의 일원으로 데일리 스크럼에 참여하기도 함
• 스크럼에서는 어제 진행한 일과 이슈/오늘 진행할 업무/이 외 추가적으로 논의하고 싶은 일 자유롭게 나눔

 

데일리 스크럼의 장점

• 일에 집중하고 자율관리 팀으로서의 능력을 향상시킴
• 팀의 소통을 향상시키고 팀이 가지고 있는 장애물을 파악해 신속한 의사 결정을 촉진하여 별도로 다른 미팅을 할 필요성을 줄여줌
• 계속해서 서로 체크하고 조율할 수 있는 데일리 스크럼 과정을 거치면서 오류와 불확실성을 교정

 

스프린트 리뷰

• 스프린트의 결과물을 점검하고 향후에 적응할 것들을 결정
• 스크럼 팀은 주요 이해관계자들에게 일의 결과물과 논의된 프로덕트의 진척 상황을 공유
• 이번 스프린트에 성취한 것과 그동안 비즈니스 환경에서 변한 것이 있는지, 그것이 무엇인지를 검토
• 이 정보에 기초하여 참여자들은 다음으로 무엇을 할 것인지 협력하여 논의
  • 새로운 기회를 창출하기 위해 프로덕트 백로그를 수정할 수도 있음

 

스프린트 회고

• 주제 ＂다음 스프린트를 더 잘하기 위해 우리가 무엇을 할 수 있는가?”
• 스크럼 팀은 팀원 개개인, 팀원 간의 대화와 상호작용, 프로세스, 툴, 완료의 정의에 대해 지난 스프린트가 어떻게 진행 되었는지를 점검하고 공유
  • 업무 영역 별로 점검하는 사항들은 당연히 차이 존재함
  • 팀이 잘못된 방향으로 가게 된 과정이 있다면 확인하고, 그것들의 근본 원인을 찾고
  • 스크럼 팀은 무엇이 잘 진행되었는지, 잘 진행되지 않았는지에 대해서도 논의하고
  • 어떤 문제를 당면했고 그 문제를 어떻게 풀었는지(또는 풀지 못했는지)에 대해 의견 나눔

 

스크럼과 이해관계자

 

PO와 스크럼 팀과의 관계

• 팀원들은 다음에는 무엇을 개발할지, 이미 개발했던 것이 목적을 스프린트의 이루었는지 알아야 함
• PO는 팀에게 무엇이 필요하고, 어떻게 하면 팀을 적절히 도울 수 있는지 파악하고 있어야 함

 

PO와 고객과의 관계

• 고객은 자신이 필요로 하거나 관심 있어 하는 프로덕트을 언제 얻게 될지를 알아야 함
  • 더불어 우선순위가 정해진 배경과 그 이면에 대해서 궁금해 함
    • 고객 니즈 파악 팁
      • 가능한 투명하게 공개
      • 고객을 프로덕트 개발/개선에 참여시킴

 

스크럼 팀과 고객과의 관계

• 팀은 기능의 맥락을 알고 세부적인 도메인 지식도 알아야 함
• PO와 같이 팀원들 또한 고객의 피상적인 목표가 아니라 필수 목표와 핵심 문제를 파악하여 직접 고객과 함께 해결책을 만드는 것이 이상적임
• 팀은 그들이 공동으로 명확히 정의한 요구사항과 고객의 문제를, 자신들이 완전히 이해하고 있어야 함

 

PO와 C-Level(경영진)의 관계

• 제품 그룹의 고위 경영진(C-레벨 임원 등)은 PO를 제품 성공에 대한 최종적인 책임과 의무가 있는 사람으로 인정하고 바라 봄
• PO에게는 개발 상태를 가시화하고 바람직한 방향(예를 들어, ROI 및 시장 점유율)으로 최적화하기 위한 고위 경영진의 (아마도 암묵적인) 지시 사항을 실현시킬 책임이 있음
• PO는 스크럼 마스터의 힘을 합쳐 조직 설계를 개선하고, 프로덕트를 개발할 수 있도록 고위 경영진을 이끌어야

 

PO와 스크럼 마스터의 관계

• 앞선 관계들은 ‘제품 책임(product ownership)’과 직접적인 관련이 있음
  • 스크럼 마스터와의 관계는 PO의 지식 및 행동과 관련 있기에 조금 다름
• 스크럼 마스터는 PO를 적극적으로 도우며 그들의 관심, 질문, 업무에 방해가 되는 요소들을 알아야 함
• 좋은 스크럼 마스터는 뛰어난 공감 능력과 PO가 프로젝트에 적응할 수 있도록 도움과 피드백을 줌

---

[코드스테이츠 PMB 9기] 제품 개발 프로세스 w. 카카오톡 멀티프로필

#Case
- `22.1H 카카오톡 '멀티 프로필'이라는 신규 프로덕트를 출시 목표
- 카카오톡 멀티 프로필 프로덕트는 이미 충분한 논의를 통해 요구사항이 정의됨
- 멀티프로필 기능은 `22년 가장 큰 프로덕트 릴리즈임
- Waterfall 개발방식 채택

*서비스 참고 : Kakao 고객 센터>멀티 프로필

문제 : 신규 친구 추가 과정에서 멀티 프로필 기능 적용 불가

→ 멀티 프로필 기능의 최초 목적은 유저가 특정 사용자별로 자신의 개인정보를 차등 노출하기 위한 것임
→ (유저가 타유저를)신규 친구 추가, (타유저의 유저를)신규 친구 추가하는 과정에서 기본 프로필이 바로 노출 됨

 

User Story

AS-IS

1. 카카오톡 사용자는
2. 타 유저별 개인 정보 공개 조절을 위해서
3. 멀티 프로필 기능을 원한다.

TO-BE

1. 개인/비즈니스 커뮤니케이션을 위해 카카오톡을 사용하는 모든 유저는
2. 카카오톡 사용 모든 과정에서 목적과 상대에 따라 개인 정보를 차등 노출하기 위해서
3. 멀티 프로필 기능을 희망한다.

 

Backlog

---

 

이해관계자

• 프로덕트에 영향을 주거나, 영향을 받을 수 있는 개인, 집단, 조직 등의 모든 관계자
• 사용자 외, 투자사, 협력사, 경영진, 타 팀원 등 제품 산출물에 영향을 주는 모든 사람이 될 수 있음

 

카카오톡 멀티프로필 기존 사용자 외, 새로운 이해관계자

• 카카오톡 CX팀
  • 새로운 기능이 배포되어 앱 내 변경 사항이 생겼을 때, 유저로부터 관련 CS가 급증할 수 있음
  • 해당 CS 인입 시 빠르고 명확한 처리가 고객 경험에 직결되기에 이해관계자에 해당함
• 마케팅 팀
  • 멀티 프로필의 경우, 일부 기능 개선이 아닌 새로운 기능이 추가된 것이기에 릴리즈와 동시에 이를 적극 홍보할 의사 있을 것이기에 이해관계자에 해당함
• 타 사업팀(카카오 워크)
  • (가정) 카카오 워크 유저들의 경우, 카카오톡 내에서 별도 그룹핑하여 멀티 프로필 적용할 수 있도록 적용 희망
  • 카카오 워크와 카카오톡 일부 기능 연동 위하여 개발, 기획 요구 사항이 발생할 수 있어 이해관계자에 해당함
• 멀티프로필 미사용 카카오 유저
  • 기존 멀티프로필 기능이 만족스럽지 않아 사용을 하지 않던 유저가 기능 개편 시 사용하게 될 수 있으므로 이해관계자에 해당

 

유의사항

• 멀티프로필 기능이 각 팀의 어떤 KP에 기여하는지 파악
• 이해관계자별 요구사항 확인 및 반영 가능 범위에 대한 논의
• 내부 고객(이해관계자) 배포 문서 공유하기
  • 변경된 기능 명칭과 소개
  • 변경 및 개발 사유
  • 릴리즈 예정 일시
  • 사용 가이드
  • 문제 발생 시 대처 방법