[제로베이스 PM 파트타임스쿨] 28일차 - 애자일 방법론 기반으로 프로젝트 진행하기_스크럼, 스프린트 전 프로세스, 스프린트 진해으 스프린트 후 프로세스, 스크럼 최종 정리

 

스크럼(Scrum)은 애자일(Agile) 소프트웨어 개발 방법론 중 하나이다. 복잡한 프로젝트를 관리하기 위한 프레임워크로, 특히 소프트웨어 개발에서 널리 사용되고 있다.. 스크럼의 주요 특징은 다음과 같다.

1. 반복적 개발: 2-4주 정도의 짧은 '스프린트(Sprint)'라는 기간 동안 개발을 진행
2. 역할:
   • 제품 책임자(Product Owner): 제품의 방향성을 결정
   • 스크럼 마스터(Scrum Master): 팀이 스크럼 원칙을 잘 따르도록 지원
   • 개발 팀(Development Team): 실제 작업을 수행하는 구성원들
3. 이벤트:
   • 스프린트 계획(Sprint Planning): 다음 스프린트에서 할 일을 계획
   • 일일 스크럼(Daily Scrum): 매일 짧게 진행되는 회의
   • 스프린트 리뷰(Sprint Review): 스프린트 결과물 검토
   • 스프린트 회고(Sprint Retrospective): 프로세스 개선을 위한 회의
4. 산출물:
   • 제품 백로그(Product Backlog): 제품에 필요한 모든 기능과 요구사항 목록
   • 스프린트 백로그(Sprint Backlog): 현재 스프린트에서 처리할 작업 목록
   • 증분(Increment): 스프린트 동안 완성된 제품의 일부

스크럼은 유연성, 투명성, 적응성을 강조하며, 팀이 빠르게 변화하는 요구사항에 대응할 수 있도록 도와준다.

이 그래프는 Cynefin 프레임워크를 기반으로 한 소프트웨어 개발 방법론 선택 가이드를 보여주고 있다. 프로젝트의 특성에 따라 적합한 개발 방법론을 선택하는 데 도움을 주는 도구이다.

그래프는 두 가지 축으로 구성되어 있다:

• 세로축: 요구사항(Requirements)의 명확성 (위쪽 unclear에서 아래쪽 clear까지)
• 가로축: 기술(Technology)의 알려진 정도 (왼쪽 known에서 오른쪽 unknown까지)

이 두 축에 따라 4가지 주요 영역으로 나뉘어 있습니다:

1. Simple(단순) - 노란색 영역:
   • 요구사항이 명확하고 기술도 잘 알려진 상태
   • 적합한 방법론: Waterfall(폭포수 모델)
   • 예측 가능하고 안정적인 프로젝트에 적합
2. Complicated(기술적으로 복잡) - 파란색 영역:
   • 요구사항은 명확하지만 기술적 측면이 불확실한 상태
   • 적합한 방법론: 기술적 Agile(애자일)
   • 기술적 도전이 있는 프로젝트에 적합
3. Complicated(사회적/정치적으로 복잡) - 녹색 영역:
   • 기술은 알려져 있지만 요구사항이 불명확한 상태
   • 적합한 방법론: 사회적/정치적 Waterfall/Agile
   • 이해관계자와의 조율이 필요한 프로젝트에 적합
4. Complex(복잡) - 중앙 영역:
   • 요구사항과 기술 모두 중간 정도의 불확실성을 가진 상태
   • 적합한 방법론: SCRUM(스크럼)
   • 변화에 적응해야 하는 복잡한 프로젝트에 적합
5. Chaotic(혼돈) - 빨간색 영역:
   • 요구사항과 기술 모두 매우 불확실한 상태
   • 적합한 방법론: Kanban(칸반)
   • 매우 불확실하고 예측하기 어려운 환경의 프로젝트에 적합

이 그래프는 스크럼이 특히 "Complex(복잡)" 영역의 프로젝트, 즉 요구사항과 기술 구현 방법 모두 어느 정도 불확실성이 있는 프로젝트에 가장 적합하다는 것을 보여준다. 이런 환경에서는 반복적이고 적응형인 스크럼 방법론이 효과적으로 작동한다.

스크럼의 활용 시점은 이미지에서 언급된 것처럼 "Not fully knowable but reasonably predictable, the unknown unknowns"(완전히 알 수 없지만 합리적으로 예측 가능한, 알려지지 않은 미지의 영역)일 때이다.

 

---

우선 순위가 높을 수록 더 잘게 구체적으로 쪼개서 백로그를 작성한다. 또한 우선순위를 선정한 이유에 대해 논리적으로 설명할 수 있어야한다.

---

데일리 스크럼은 보고자리가 아니다. 팀원들에게 도움을 요청하고 빠르게 해결할 수 있는 시간을 마련하는 것이라고 생각해야한다.

---

유저스토리를 공유하는 것도 좋은 방법이지만 프로토타입(데모)를 통해 보여주는 것이 가장 쉽고 빠르게 설명할 수 있는 방법이다.

비판적인 피드백이 있더라도 다음 스프린트를 위한 발판이라고 생각해야한다. 스프린트 리뷰는 성과보고가 아니다!

스프린트 리뷰로 팀원들의 사기도 증진할 수 있어야한다.

 

 

스프린트 회고시 사용하는 방법론

잘한 부분(keep), 문제였던 부분(problem), 문제를 해결하기 위해 해야할 부분(try) 을 적어준다. try부분에는 구체적이고 실현가능한 내용으로 적는다. 그리고 나서 try 우선순위를 정하고 몇개만 선정후 다음 스프린트에 적용하고 담당자도 선정하는 것이 좋다.