스크럼(Scrum)

[사진 출처] [TIL # 58] Agile과 Scrum이란? (velog.io)

 

스크럼이 실패하는 이유

 

1. 비효율적 PO(Product Owner, 프로덕트 오너)

- PO가 없음

- PO가 맡은 일이 많음

- PO가 비지니스를 제대로 이해하지 못함

- PO가 소프트웨어 요구사항을 어떻게 구체화하는지 이해하지 못함

- PO가 개발팀의 기술적 과제를 해결하지 못함

- PO가 스크럼팀의 다른 멤버들과 같은 장소에서 일하지 않음

- PO에게 제품 관련 의사결정 권한이 없음

- PO의 안건이 사업 부서 안건과 다름

- PO가 일반 사용자를 대표하지 않음

- PO가 스크럼 규칙을 따르길 거부함

 

2. 제품 백로그 정제 부족

제품 백로그는 스크럼 개발팀에 작업을 공급하는데 사용됨.

PO는 이를 책임지며 백로그 정제는 팀에 일감이 떨어지지 않도록 지속적으로 진행되는 활동이어야 함.

백로그 정제(백로그 그루밍)는 스토리 살 붙이기, 스토리 쪼개기, 새로운 스토리 추가, 상대적 우선순위 업데이트, 스토리 추정/재추정 하는 일을 포함함.

 

3. 스토리가 너무 큼

스프린트가 끝나고 작업을 배포할 수 있는 상태가 되려면 스토리를 단일 스프린트 내에 완료해야함.

하나의 스토리에 팀원 절반 이상이 스프린트 절반을 지나는 동안 매달리지 않도록 해야함.

 

4. 매일 하지 않는 일일 스크럼

일일 스크럼은 반복적 => 스크럼을 일주일에 세번 or 한 번 하는 형태로 변함

(회의가 너무 길기 때문 => 하루 15분 정도로 매일 진행!)

 

5. 지나치게 긴 스프린트

1~3주가 최선, 대부분의 팀이 2주를 지향함

 

6. 수직 슬라이스보다 수평 슬라이스 강조

수직 슬라이스(Vertical Slice)는 전체 기술 스택에 걸친 엔드투엔드 기능을 가리킴.

수직 슬라이스 => 엄격한 피드백 루프를 지원하고, 비지니스 가치를 빠르게 전달 가능.

 

7. 따로 떨어져 있는 개발팀과 테스트팀

이는 순차 개발의 잔재

 

8. 명확하지 않은 완료 기준

'완료 정의(Definition of Done)', 즉 DoD는 고품질을 유지하는데 중요한 버팀목 가운데 하나임.

개인이나 팀이 '완료' 했다고 선언하면 팀과 조직은 해당 항목에 더 이상 남아 있는 일이 없다고 확신할 수 있다.

 

9. 릴리스 할 수 있는 수준에 이르지 못한 스프린트 품질

과도하게 일정을 압박 => 팀과 구성원은 실제 진행상황보다 진척 그래프의 모양을 우선하게 됨.

품질은 기본 기능보다 눈에 잘 안 보이기 때문에 팀이 질보다 양을 강조하게 된다.

=> 이는 '완료' 되지 않은 상태에서 완료로 선언되게 함.

 

10. 회고 시간이 잡혀 있지 않음

스스로 계획하고 약속한 실수에서 배울 기회를 주지 않는 한, 처음부터 그런 사이클을 초래한 과도한 헌신과 소진의 악순환은 계속 될 것임.

 

11. 회고에서 배운 점을 다음 스프린트에 반영하지 않음

가장 흔히 볼 수 있는 유형.

회고를 진행하지만 교훈을 다음 스프린트에 실제로 녹여 내지 않는 것이다.