DAILY

[코드스테이츠 PMB 9기] 스크럼과 이해관계자

Ellaso 2022. 1. 12. 22:44
W8D3 학습목표
- 스크럼에서 PM의 역할과 책임을 구체적으로 설정할 수 있다.
- 스크럼 절차에서 각 이해관계자들의 입장을 조율할 수 있다.

개념 정리
- QA
- 스프린트
- 이해관계자

이후 답변 가능한 질문
- QA를 PM의 주도로 진행해야 하는 이유는 무엇인가?
- 스크럼에 영향을 주는 이해 관계자들은 누구이며 이들을 어떻게 설득해야 하는가?

Product Manager와 스크럼

언제 스크럼 프레임워크를 사용하는가?

‘함께 만들 것’을 기획하고, ‘사업가치’와 ‘고객가치’를 창출할 책임을 가진 PM으로서 어떠한 개발 방법론을 사용해 제품을 만들어 낼 것인지를 결정하는 것 역시 제품 관리에서 매우 핵심적인 사항입니다. 이를 위해 다시한번 워터폴 방식과 애자일 방식의 장단점을 비교해 보겠습니다.

워터폴 방식의 특징

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

애자일 방식

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

QA(Quality Assurance)란

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

QA 과정에서 진행되는 업무

  1. 기획 문서 리뷰 : 먼저, 기획서를 리뷰하면서, 기획 명세서에서 빠진 내용은 없는지, 이해하기 어려운 부분은 없는지, 오해로 인한 버그 발생의 요소는 없는지 등을 질의 응답을 통해 충분히 논의합니다. 이를 통해 최대한 버그 발생을 요인들을 점검하고 예방합니다.
  2. 플로우 차트 및 테스트 케이스 작성 : 기획서를 기반으로 하여 플로우 차트를 그리고, 기획 단계에서 생각하지 못한 시나리오를 점검합니다. 또한 해당 차트를 기반으로 테스트 케이스를 작성하게 됩니다.
  3. 내부 리뷰 : PM, 개발자, QA 등 프로덕트 팀이 테스트 케이스를 점검하며, 잘못된 요구 사항은 없는지, 이해로 인한 오류는 없는지 등을 확인합니다. 또한, 프로덕트 관점에서의 기술 정의를 문서화해, 커뮤니케이션의 도구로 사용합니다.
  4. 테스트 케이스 수행 : 테스트 케이스를 수행하며 Pass/Fail 여부를 확인합니다. 테스트 케이스 과정을 살펴보면 이해 가능하듯이, 정말 여러 부분의 오류를 사전에 파악할 수 있겠죠? 이처럼 QA는 테스트 케이스를 통해 프로덕트의 전반적인 오류를 점검하고, 서비스 릴리스 혹은 프로덕트가 고객을 만나기 전 최대한 퀄리티를 높일 수 있는 매우 중요한 과정입니다. 여기서 하나 아셔야 할 것은, 기업의 규모에 따라 QA 담당자가 없는 경우도 있다는 것인데요. 이 경우 기획자, 혹은 개발자가 QA를 담당하게 됩니다. 하지만 이 경우 QA 담당자의 수행에 비해, 오류를 완벽하게 잡아내지 못할 가능성이 존재하겠죠.

스프린트 업무 이해하기

스프린트. 전력질주라는 의미를 가진 이 제품 개발 방식은 아이디어를 가치로 만들어내는 과정으로, 스크럼의 심장 박동과 같습니다.

스프린트는 꾸준함 보다는 한달 혹은 더 짧은 몇 주의 기간에 고정된 이벤트 프로세스입니다. 새로운 스프린트는 직전의 스프린트가 끝나는 즉시 시작되며 계속해서 이어집니다.

스프린트 기간을 너무 길게 잡으면, 스프린트 목표가 효력이 없어지거나 복잡도가 늘어나고 리스크가 높아질 수 있습니다. 반대로 더 짧은 스프린트 기간일수록 더 많은 학습 기회를 가질 수 있고, 짧은 기간 동안 수행하는 비용과 노력으로 리스크를 한정시킬 수 있습니다. 이처럼 각 스프린트는 짧은 단위의 프로젝트와 같은 역할을 합니다.

스프린트 플래닝

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

스프린트 플래닝에서 다뤄야 하는 주제는 다음과 같습니다.

  • 이 스프린트가 어떤 가치가 있는가? 스크럼에 참여하는 모든 팀원들이 모여 스프린트의 목표를 정의합니다. 여기에는 이 스프린트가 중요한 이유를 담아야하고, 스프린트 목표는 스프린트 플래닝을 마치기 전에 결정되어야 합니다.
  • 이 스프린트의 완료(done)은 무엇인가? PO는 개발자들과 함께 해당 스프린트에 포함될 프로덕트 백로그 아이템을 설정하게 됩니다. 하지만 한 스프린트 내에 완료하는 것이 쉬운 일은 아닌데요. 하지만 개발자들이 그들의 지난 성과와 수용 가능한 업무량, 완료의 정의에 대해 명확히 알아야 스프린트에 확신을 가질 수 있습니다.
  • 선정한 업무를 어떻게 완료할 것인가? 개발자들은 일반적으로 프로덕트 백로그를 하루 단위로 더 잘게 세분화해 필요한 업무들을 계획하게 됩니다. 중요한 것은 이 과정은 절대적으로 개발자들이 정해야 하며, 다른 누구도 개발자들에게 백로그를 정해주어서는 안됩니다.

데일리 스크럼

데일리 스크럼의 목적은 스프린트의 진척을 점검하고, 필요에 따라 다음 업무 진행 계획을 변경하여 스프린트 백로그를 조정하는 것입니다.

데일리 스크럼은 스크럼 팀의 개발자들만 참여하는 15분 내외 길이의 이벤트입니다. 이 미팅은 같은 시각에 같은 장소에서 스프린트 기간 동안 매일 진행하게 됩니다. 개발자들은 어떤 방식이나 기법으로도 데일리 스크럼을 진행할 수 있습니다. 만약 프로덕트 오너나 스크럼 마스터도 스프린트 백로그 아이템을 맡아 활동적으로 업무를 하고 있다면 개발자들의 일원으로 데일리 스크럼에 참여하기도 합니다.

스크럼에서는 어제 진행한 일과 이슈/오늘 진행할 업무/이 외 추가적으로 논의하고 싶은 일을 자유롭게 나눕니다.

그렇다면 데일리 스크럼의 장점은 무엇일까요? 데일리 스크럼은 일에 집중하고 자율관리 팀으로서의 능력을 향상시킵니다. 또 데일리 스크럼은 팀의 소통을 향상시키고 팀이 가지고 있는 장애물을 파악해 신속한 의사 결정을 촉진하여 별도로 다른 미팅을 할 필요성을 줄여줍니다.

프로덕트에 대한 계획과 업무를 잘 나누는 것도 중요하지만, 계속해서 서로 체크하고 조율할 수 있는 데일리 스크럼 과정을 거치면서 오류와 불확실성을 잡아나갈 수 있습니다.

스프린트 리뷰

스프린트 리뷰에서는 스프린트의 결과물을 점검하고 향후에 적응할 것들을 결정하게 됩니다. 스크럼 팀은 주요 이해관계자들에게 일의 결과물과 논의된 프로덕트의 진척 상황을 보여줘야 합니다.

스프린트 리뷰 동안 스크럼 팀과 이해관계자는 이번 스프린트에 성취한 것과 그동안 비즈니스 환경에서 변한 것이 있는지, 그것이 무엇인지를 검토합니다. 이 정보에 기초하여 참여자들은 다음으로 무엇을 할 것인지 협력하여 논의하게 됩니다. 새로운 기회를 창출하기 위해 프로덕트 백로그를 수정할 수도 있습니다.

스프린트 리뷰는 이와 같이 구체적인 활동을 하는 시간이기에, 일방적인 발표만 하고 끝나지 않도록 해야 한다. 서로 질문과 답변, 의견을 나누는 것이 중요합니다.

스프린트 회고

마지막으로 우리는 ‘스프린트 회고’ 과정을 거치게 됩니다. 스프린트 회고의 목적은 품질과 효율을 높이기 위한 방법들을 계획하는 것입니다. 회고의 주제는 ＂다음 스프린트를 더 잘하기 위해 우리가 무엇을 할 수 있는가?”입니다.

스크럼 팀은 팀원 개개인, 팀원 간의 대화와 상호작용, 프로세스, 툴, 완료의 정의에 대해 지난 스프린트가 어떻게 진행 되었는지를 점검하고 공유합니다. 업무 영역 별로 점검하는 사항들은 당연히 차이가 날 수 있습니다. 팀이 잘못된 방향으로 가게 된 과정이 있다면 확인하고, 그것들의 근본 원인을 찾아내는 시간입니다. 또 스크럼 팀은 무엇이 잘 진행되었는지, 잘 진행되지 않았는지에 대해서도 논의합니다. 어떤 문제를 당면했고 그 문제를 어떻게 풀었는지(또는 풀지 못했는지)에 대해 의견을 나누게 됩니다.

스크럼 팀은 그들의 효율을 향상시키기 위해 가장 도움이 될만한 변화를 찾아야 합니다. 때문에 가장 영향이 큰 개선책을 최우선으로 고려해야 하고, 이를 다음 스프린트에 수행하기 위해 스프린트 백로그에 추가하기도 합니다.

스프린트 회고를 마지막으로 하나의 스프린트는 종료됩니다. 스프린트 회고는 가장 긴 시간을 소요하는 이벤트로, 수 시간이 넘지 않도록 하며, 스프린트 기간이 더 짧은 경우, 보통 스프린트 회고 시간도 더 짧아집니다. 그리고 스프린트 회고에 이어 다음 진행할 스프린트 플래닝을 다시 시작하게 됩니다.

PO와 스크럼 팀과의 관계

팀은 PO가 고객에게 가장 적합한 제품을 만드는 데 도움을 주려고 존재하기 마련입니다. 그리고 팀원들은 다음에는 무엇을 개발할지, 이미 개발했던 것이 목적을 스프린트의 이루었는지 알아야 하죠. 그리고 PO는 팀에게 무엇이 필요하고, 어떻게 하면 팀을 적절히 도울 수 있는지 파악하고 있어야 합니다.

PO와 고객과의 관계

PO와 팀은 고객에게 가장 적합하고, 필요로 하는 제품을 만들려 노력합니다. 때문에 고객은 자신이 필요로 하거나 관심 있어 하는 프로덕트을 언제 얻게 될지를 알아야 하죠. 그리고 우선순위가 정해진 배경과 그 이면에 대해서 궁금해합니다. 여기서 고객의 니즈를 알아내는 한 가지 팁이 있다면, 가능한 투명하게 공개하며 고객을 프로덕트 개발/개선에 참여시키는 것입니다. PO는 고객의 진짜 목표 및 문제(또는 그 비전을 넘어서 상상하는 무언가)를 알고 우선순위를 잘 정하는 데 도움이 될 정보를 모아야 하기 때문이죠.

스크럼 팀과 고객과의 관계

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

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

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

PO와 스크럼 마스터의 관계

앞서 언급한 관계들은 ‘제품 책임(product ownership)’과 직접적인 관련이 있었지만, 이번 관계는 다릅니다. PO의 지식 및 행동과 관련이 있기 때문인데요. 스크럼 마스터는 PO를 적극적으로 도우며 그들의 관심, 질문, 업무에 방해가 되는 요소들을 알아야 한다. 좋은 스크럼 마스터는 이야기를 잘 들어주는 귀가 될 수도 있고, 기대어 울 어깨가 되어줄 수도 있습니다. 또한 스크럼 마스터는 PO가 프로젝트에 적응할 수 있도록 도움과 피드백을 줍니다.

 

 

 

 

스크럼과 이해관계자W8D1 과제에서 작성했던 유저스토리와, 백로그 내용에 이어서 작성해보세요.User Story는 고객 중심으로 작성하셨을텐데요. 고객이 아닌 다른 이해관계자(Stakeholders)가 누가 있을까요? 잠재 고객, 이탈 고객 등으로 고객을 더 구분할 수도 있고 팀원, 투자자, CEO 등등 다양한 이해관계자를 생각해봅니다. 그들은 어떤 니즈를 가지고 있을까요?
1. 작성한 User Story의 이해 관계자는 누구인가요? 최대한 다양한 이해관계자의 요구를 수집해 봅니다.
2. 각 이해관계자의 요구를 해소하기 위해 유의해야 할 점은 무엇인지 생각해 봅니다.