개인적으로 애자일방법론에 대해 여태 들은 수업 중 가장 잘 이해가 된 강의였다!
강사님이 이론적으로 충분히 이해를 시켜주신 것 같다. 감사합니다! 🙏🏻
애자일방법론을 기반으로 프로젝트 진행하기
애자일에 대해서는 전에도 몇번 다뤘기 때문에 간단하게 정의만 하자면,
최소 기능 제품을 빠르게 개발하여 유저들의 피드백을 받고, 해당 피드백을 바탕으로 지속적으로 개선해 나가는 개발 방법론이다.
요구사항 수집, 기획, 디자인, 개발 및 배포, 유저들의 피드백을 살핀 후 그 피드백을 바탕으로 다시 요구사항을 만들어 나가는 지속적인 개선을 한다.
애자일 방법론의 장점으로는
1. 잘못된 제품을 개발하는데에 사용하는 시간을 최소화 할 수 있다.
2. 더 자주 유저의 피드백을 얻을 수 있기 때문에 실패할 확률을 낮출 수 있다.
3. 계획 혹은 기능에 대한 수정과 변경에 유연하게 대처할 수 있다.
단점으로는,
1. 요구사항이 명확할 경우, 오히려 속도가 늦춰질 수 있다.
2. 최종 제품이 요구사항과 달라질 수 있다.
3. 고객에게 제공하는 가치에 집중하기 때문에 기술적 완성도가 떨어질 수 있다.
애자일에서 일을 쪼개는 단위로는 Theme > Epic > Story > Task 순이다. Story가 기본 단위가 되는데, story는 고객의 행동을 나타냄으로, 네가지 단위 중 가장 중요하다. story보다 더 작은 단위인 Task들이 여러가지로 모여 하나의 스토리가 완성된다. 또, 이러한 story들이 모이면 하나의 큰 Epic이 되며 Epic들을 모은 것이 하나의 Theme이 되는 것이다.
대표적인 애자일 개발 방법론 - 스크럼
애자일 방법론에서는 각 반복 주기가 종료될 때마다 부분적으로 완성된 결과물들이 만들어지고 이를 통해 유저에게 가치가 전달됨.
애자일에서는 이 반복 주기를 Iteration이라 하고 스크럼에서는 반복 주기를 Sprint라고 부른다.
스크럼은 이 스프린트를 반복적으로 진행하면서 제품을 개발해 나가는 방법론이다. 스크럼은 관리도구가 아닌 실행도구 이다.
스크럼의 프로세스는 이러하다.프로덕트 백로그 관리 ➡️ 스프린트 플래닝 미팅➡️ 스프린트 백로그 선정 ➡️ 스프린트 ➡️ 스프린트 도중 매일 진행되는 데일리 스크럼 ➡️ 업무 완료 ➡️ 스프린트 리뷰 및 스프린트 회고 이 일련의 과정이 반복적으로 지속되는 것이 스크럼 개발 방법론의 핵심이다.
- 프로덕트 백로그 관리
제품 개선을 위해 진행되어야 할 다양한 요구사항. 제품에 관련한 매우 다양한 팀에서 백로그들을 수집한다. 백로그에는 요청자 / 생성 이유 / 추정시간 / 요구명세 등 다양한 내용을 포함하여 작성하며, 자세하면 자세할 수록 PM이 우선순위를 설정하는 것이 쉬워진다.
작성법으로는 요구사항을 작성하되, 구체적인 실행방안에 대해서는 작성하지 않아도 되며, 백로그 진행이 중요한 이유에 대해 자세히 작성해야 우선순위 산정과 제품 개발에 용이하다. - 스프린트 플래닝 미팅
스프린트란, 통상 2~4주정도의 Time Box 성격을 가진 개발 주기이다. 각 스프린트 단계 종료 시 새로운 기능이 추가되어 제품에 반영하고 유저에게 새로운 가치를 제공하는 것을 목표로한다.
스프린트 플래닝 미팅에서는 백로그들 중 이번 스프린트에 어떤 백로그를 진행할 지 모든 팀원들이 함께 논의하는 자리이다. 어떤 것을 진행할 지 미팅을 통해 정해야하며, 독단적으로 목표를 설정해선 안된다. 또한 너무 많은 백로그를 선정하게 된다면 목표 달성이 어려워 지고 팀원의 사기가 떨어질 수 있으며, 또 너무 적은 백로그를 선정하면 리소스 낭비로 이어질 수 있기 때문에 적당한 양의 백로그를 선정하여 지정하는 것이 중요하다.
스프린트 중에 백로그를 변경하지 않는 것을 원칙으로 한다. - 스프린트
데일리 스크럼 미팅 : 스프린트가 진행되는 동안 매일 15분정도 씩 진행되는 짧은 미팅을 말한다. 스프린트가 목표에 맞게 진행되고 있는지, 백로그에 있는 작업이 잘 완성되고 있는지 확인하는 시간이다.
매일 진행되는 미팅인 만큼 최대한 짧고 컴팩트하게 진행되어야 한다. 스크럼에서 발생된 문제나 팀원들 간에 깊이 있게 논의해야 하는 문제가 있을 경우에는 관련 인원만 모여 데일리 스크럼 종료 후 추가 미팅을 진행하는 방식으로 해야한다.
스크럼에서의 주요 확인 사항에는
- 어제 하루 동안 개발팀의 "스프린트 목표 달성을 위해" 무엇을 했는지?
- 오늘 하루 동안 개발팀의 "스프린트 목표 달성을 위해" 무엇을 할 것인지?
- "스프린트 목표 달성을 하는데" 방해요소가 있는지?
목표 달성과 관련되지 않는 내용은 굳이 이야기 할 필요가 없다. - 스프린트 리뷰와 회고
스프린트 리뷰 : 스프린트 결과물에 대해 이야기를 나누는 자리. 스프린트를 통해 무엇이 완료되었는지 팀원들과 이해관계자들이 모여 확인하는 자리. 또한 리뷰 결과와 스프린트 수행 중 변경된 백로그를 고려하여 다음에 무엇을 할지 함께 의논하는 자리이다. 개선사항을 발표함으로써 피드백을 최대한 많이 받고 협력을 촉진하기 위한 회의이다.
스프린트 회고 : 스프린트 진행과정에 대해 이야기를 나누는 자리. 팀이 스프린트를 진행하며 잘한 점과 잘못한 점, 개선해야할 점을 나누면서 다음 스프린트에는 어떤 부분을 잘할 수 있을까에 대한 내용을 나누는 자리이다.
회고 세션을 따로 두는 이유는 팀의 유기적 협업과 효율성 극대화에 매우 도움이 되기 때문이다.
가장 많이 활용되는 회고 방법론으로는 KPT회고 방법론이 있다.
Keep : 좋았던 부분 / 유지되었으면 하는 부분
Problem : 문제가 됐던 부분 / 잘 되지 않았던 부분
Try : Problem을 해결할 수 있도록 실천할 수 있는 부분
Try는 회고에 가장 중요한 부분이며, 구체적이고 실행가능한 것들로만 채워야한다.
'PM학습일지' 카테고리의 다른 글
| [제로베이스 PM스쿨 19기] 학습일지 Day 9 (2) | 2023.10.24 |
|---|---|
| [제로베이스 PM스쿨 19기] 학습일지 Day 8 (1) | 2023.10.22 |
| [제로베이스 PM스쿨 19기] 학습일지 Day 6 (0) | 2023.10.18 |
| [제로베이스 PM스쿨 19기] 학습일지 Day 5 (0) | 2023.10.16 |
| [제로베이스 PM스쿨 19기] 학습일지 Day 4 (0) | 2023.10.15 |