- 불완전한 추측에 시간을 쓰기보다 확실한 구현에 시간을 쓰자
- 개발하기 전의 작업량 추정은 어림짐작에 불과하다.
- 다양한 변수가 존재하기 때문
- 애매한 걸 명확하게 만드려고 하지 말자
- 차라리 견적은 신속하게 끝내고 직접 경험을 하자
- 견적은 실제 작업할 개발자가 낸다.
- 개발 이전의 요구 사항과 관련된 작업도 개발자가 참여해야 한다.
- 프로덕트 오너와 함께
- 직접 코드를 짜는 것 말고도 아키텍처를 설계하거나 검토하는 작업부터 요구 사항을 수집하고 정리하는 일까지 모두 개발자가 진행
- 내용도 잘 알고 구현할 능력도 갖춘 사람은 개발자밖에 없기 때문
- 스크럼 팀에서 견적을 낼 때 가장 잘 알려진 방법으로 플래닝 포커가 있다.
- 모두 같은 숫자가 나오면 합의 완료.
- 서로 다른 숫자가 나오면 왜 그렇게 생각했는지를 돌아가며 설명한 다음에 다시 한번 동시에 카드 제시
- 만장일치가 될 때까지 과정 반복
- 하지만 더 중요한 건 견적은 신속하게 내는 것
- 만약 시간이 너무 오래 걸리면 가장 높은 수와 낮은 수를 낸 사람만 설명
- 그래도 만장일치가 나오지 않는다면 적절히 평균
- 견적은 가능한 신속하게 끝내고 구현할 시간 더 확보하는 게 더 좋을 것
- 플래닝 포커는 작업량을 쉽게 추정하려고 쓰는 게 아니다.
- 개발자 간의 합의를 쉽게 끌어내기 위해 사용하는 것
- 견적을 낼 때는 다양한 의견을 듣는 것이 중요
- 신속하게 의견 교환, 합의를 끌어내기 위한 방법으로 플래닝 포커 사용
- 애매한 것을 빨리 찾게 도와주는 도구
- 각자의 생각이 다르다는 걸 숫자로 알게 해 주기 때문
- 왜 다른 숫자를 제시했는지 설명을 하다 보면 애매한 부분을 어떻게 해석하면 되는지 깨닫는다.
- 만장일치가 나오더라도 적어도 한 사람은 왜 그 숫자를 냈는지 설명
- 궁금한 게 해결되지 않아서 견적 내기 어렵다면 무리하게 작업량을 추정하지 않아도 된다.
- 숫자로 나오는 견적 결과가 아니라 팀원이 함께 모여서 이야기하는 과정이 중요
- 인셉션 덱
- 제품에 대해 모든 팀원이 같은 생각을 할 수 있게 도와줌
- 제품을 개발할 때 못지않게 시간을 사용해야 함
- 엘리베이터 피치
- 투자자가 엘리베이터에 내리기 전 아주 짧은 시간(15~30) 초 동안에 제품을 설명하는 기법
- 우선 팀원 각자가 엘리베이터 피치를 하나씩 만든 다음 함께 공유
- 논의를 거듭하면서 생각의 차이를 좁히고 팀 전원이 납득할 수 있는 엘리베이터 피치 생성
- 인셉션 덱을 만들면서 주고받은 말이 팀의 공통 언어가 됨
- 개발이 시작될 때 다시 한번 엘리베이터 피치를 확인해 보자라거나
- 나중에 할 일에서 본 것 같은데?
- 이런 건 하지 말자고 했던 것 아냐?
- Not List
- 할 일
- 하지 말아야 할 일
- 나중에 확인할 일
Reference
출근했더니 스크럼 마스터가 된 건에 관하여