Estimation method
경험치를 바탕으로 추정치를 말하는 것이 일반적이나, 몇가지 방법론에 근거하면 좀 더 정확한 방법으로 Estimation 이 가능합니다. 팀의 리소스가 적합한지 여부를 HeadCount에 보고해야함.
-
Delphi methods
Architect, sw lead, Verification lead, Moderator(manager) 전문가 집단이 모여 비공개 estimation을 각각 제출하고 Host가 이를 취합한 후 설명 - round를 반복. 결국 가우시안 처럼 가운데로 모이게 되어있음로 모이게 되어있음. -
Planning Poker
새로운 일이 주어졌을 때 유용. 한 팀 내부에서 계속 하던 일을 추정할 때 많이 쓰임. 논의할 때는 값을 공유하지 않음. 2010년도 초반(애자일 도입시기) 부터 사용됨. 카드 덱을 사용하거나, 본인의 노트를 가져옴. 결국 팀에서 협의된 방향을 내보내는 것이 목표. 기본적으로 특정 일이 얼마나 시간이 드는지 공감대를 가지는 것이 핵심임. 피보나치 수열에 따름
순서: 먼저 User story를 만듦. (이는 product owner가 진행-team leader 또는 이 일을 가장 잘 설명할 수 있는 사람), -> 자기의 추정치를 냄 (공개, 저는 이렇게 생각합니다) -> 각 boundary가 가장 큰 사람이 각각 측정 이유를 설명함 -> 이 round를 2-3번 반복 -> 합치가 되면 끝남 -> 계속되면 평균값을 해도 괜찮음 -
비교점
주요 차이점: 익명성 (델파이는 누가 어떤값을 가졌는지 공개하지 않음.)
적용 범위: 이제 새롭게 시작되는 feature의 경우 델파이 추정이 더 유효할 수 있음. planning pocker는 팀 내부 위주에서.
Action item: 이번 147 PI에 해야할 일을 모두 list up -
실습
test를 진행할 때:
test case 작성 3일
win 11: 일부기능이 다시 들어가는데에 retest
- test spec도출 2
- 관련 팀 commnunication 2
- unknown test 도출, 3-4
- routine한 작업 4
Capacity를 먼저 조정한 후에, 내가 오롯이 들어가는 시간은 SP로 사용함.
