PMP 18 스크럼

예측형 방법론 vs 하이브리드 방법론 
- Knowledge work ; 보이지 않는 작업 / 변화할 것을 상정 
  - invisible / change / less structure / question / value-driven / innovation / autonomy / learn-teach / 작업자는 자산
- Industrial work ; up-front plan 필요 
- Defineable vs high-uncertainty work
  - Defineable : 정의된 프로세스 / prescribed process 가능 / 산업 작업
  - high-uncertainty : Empirical / TIP(투명성/검사/적응) / 지식 작업 

Incremental vs Iterative LC
- 짧은 피드백 루프 / 빈번한 프로세스 적응 / 순위 / 정기적으로 계획 업데이트  
- Incremental ; chunk 단위로 하는 것 
- Iterative ; 계속 반복 
- Core 원칙들
  - 변화를 받아들인다
  - 일은 가치를 더하는 것 
  - 피드백 루프 형성 
  - 발견을 통해서 배운다  > 신뢰 
  - 밸류 드리븐 개발 
  - 지속적인 딜리버리 / 지속적인 개선
- 4가지 종류의 LC '  
  - Predictive ; 건설 등 / 고정된 요구사항 / 액티비티 한 번 / 단일 납품 / 비용관리목표
  - Agile ; 다이나믹한 요구사항 / 활동은 계속됨 / 소량납품 지속 / 피드백을 통한 고객 가치목표
  - Iterative ; 의료 / 다이나믹 요구사항 / 활동은 계속됨 / 단일 납품 / 정확한 솔루션이 초점 
  - Incremental ; 다이나믹 요구사항 / 인크리멘트당 단일 액티비티 / 소량납품 지속 / 속도 
- Incremental Model ; 
  - 작은 개발 프로젝트로 쪼개짐
  - 파샬 시스템 하나씩 개발됨 > 우선도에 따라서 
  - DoD 만족 시 끝 
  - 인크리먼트는 개발된 이상 Frozen 
- 인크리멘탈 장점
  - 작업결과 빨리 얻을 수 있음
  - 테스팅 빨리 할 수 있음
  - 초기 납품은 더 빠르다 
- 단점
  - 비용이 Biz value 를 초과할 수도 
  - 추가된 기능들이 문제를 만들 수 있음 


스프린트 
- 프로덕트 백로그 > 유저스토리 선택 > 스프린트 백로그 만듦 
 > 스프린트 타임박스에서 실행 > 스프린트 계획 
 > 데일리 스크럼 > 스프린트 검토 회의와 리트로스펙티브 
 > 배포가능한 증분을 얻음 
- 스프린트 사전 활동
  - 비전 선언문 ; 왜 개발하는지 
  - 프로덕트 로드맵 ; PO에 의해서 타임라인 개발
  - 사용자 스토리 ; PO가 고객기반으로작성 
  - 프로덕트 백로그 ; 사용자스토리와 우선순위
- 스프린트 실행 
  - 스프린트 계획 > 데일리스크럼+액티비티 > 스프린트 리뷰 > Retrospective 
- 스프린트 상세
  - 고객은 스프린트 리뷰 중에서 새로운 요구사항 추가 가능
  - 스프린트 실행하면 바꾸지 않는다
  - 스프린트 목표는 변경하지 않는다 
- 스프린트
  - 각각의 스토리는 싱글 스프린트에서 개발되어야 
  - 우선순위가 가장 높은 스토리가 선택되어야
  - DoD에 사전 동의해야한다
  - 스프린트는 2-4주 / 한달이상 가지 않는다 / 너무 짧은 스토리도 안됨 
- 스프린트 취소
  - PO는 취소 가능하다
  - 스프린트 골이 obsolete 해지면 그럴 수 있다
  - 취소되도 리뷰와 백로그는 지속한다 

애자일 스프린트 계획 
- 스프린트의 계획 시 8시간 정도 함 ; 팀 용량 / 스프린트 목표 / DoD/ 스프린트 백로그
- 개발 팀 : 가장 우선순위 높은 걸 하면 됨 / 팀 용량 고려 분량을 조절 
- PO : 랭킹하고 백로그 순서 조정 / 유저 스토리 작성 / 적절한 분량을 골랐는지 확인 
- 스프린트 백로그 다음 : 스크럼 팀은 스프린트 목표 작성 
  - DoD 설정 / 왜 개발하는지 설정
- 개발 팀 : 백로그 설정 시, 더 자세한 게획 / 제품 백로그 > 예산기간/의존관계 등 파악 
- 스프린트 목표 ( To do / Doing / Done) 
- 포스트잇은 각각의 유저 스토리를 브레이킹 다운하는 데 사용됨
  - Task ; 개발팀이 할 일
  - 팀원 전원이 태스크를 설정하는 데 Responsible 
  - 몇가지 태스크는 스프린트 계획에서 만들어지거나 / 스프린트 중에 만들어질 수도 
- 스프린트 백로그 ; 스프린트 목표 / 프로덕트백로그에서 골라진 아이템들 / DoD


일일 스크럼 회의 
- 15분 수준 회의 / 작업현황 검토 
- 다음 24시간동안 작업과 계획을 일치시키는 작업이다
  - 어디까지 성취되었는지
  - 다음 회의에서 어디까지 할 지
  - 어떤 장애물이 있는지
- 데일리 스크럼 
  - 스프린트 목표에 대한 진행사항을 평가한다  
  - 스프린트 종료시 상태 예측 
  - 같은 시간같은 장소 
  - 개발팀 끼리만 함 / 모든 이해관계자가 참여하는 게 아님 
  - 스프린트 보드 / 번다운차트 등 사용
- 대규모 스크럼 팀 
  - 스크럼 오브 스크럼이 발생할 수 있음
  - 스크럼 대표자들끼리 또 스크럼 

스프린트 검토 회의 (리뷰) 
- 데모 / 4시간 정도 / 스크럼 팀과 다른 이해관계자들 
- Done 아이템들을 시연하고 검사
- PO는  Done 상태임을 확인해야 > 100% 전에는 시연하징 않음
- 개발팀은 아이템을 설명한다 
- PO는 프로덕트 백로그 상태를 설명하고 예상 완료일자를 업데이트 토의 
- 모든 스크럼팀은 프로덕트 백로그 업데이트에 참여  

스프린트 회고 
- 3시간 회의 / 스프린트 종료 후 
- 교훈 정리 
- 피료하지만/ PO 스크럼 마스터 개발팀이 동의하면 스킵한다
- 개선에 대한 방법을 찾는 것이 목표이자 공식적인 기회
  - 사람 / 관계 / 프로세스와 툴 / 개선방법에 대해 토의 

스프린트 활동 고려사항
- 스프린트 계획 회의는 > 뭘할지를 계획
- PO는 요구사항 우선순위 설정 / 백로그 컨텐츠에 대해 결정 
- 유저 스토리로 스프린트 백로그를 만든다
- 유저 스토리를 가져다가 > 팀이 브레이크 다운> 태스크를 만든다 
- 30일동안 작업할 양 결정 
- 데일리 스크럼 : 15분 
- 스프린트 리뷰 ; 데모와 함께 완료 사항 시연
- 스프린트 회고 ; 리뷰하고 개선점 발굴
- 스크럼 마스터 > 스크럼 프로세스를 준수 + 코칭 제공 
- 스프린트 듀레이션이 길어지면 안될까? 
  - 이해관계자로부터 멀어질 수 있음
  - 프로덕트 출시가 멀어지면 시장거래능력에 영향을 줌
  - 팀이 변화할 주기를 유지 필요