추정은 어렵습니다. 소프트웨어는 미지의 것으로 가득하기 때문입니다. 목표는 거짓된 정밀함이 아니라, 비즈니스가 계획하는 데 도움이 되는 현실적이고 정직하게 전달된 범위입니다. 좋은 TL은 범위를 추정하고, 위험을 드러내며, 배우면서 다시 예측합니다.
더 잘 추정하는 방법
text
✓ 작업을 분해하라 — 작은 작업이 큰 작업보다 훨씬 잘 추정된다
✓ 범위나 신뢰도로 추정하라("2-4주, 70% 확신")
✓ 보이지 않는 작업을 포함하라 — 테스트, 리뷰, 배포, 미지수
✓ 이력을 활용하라 — 비슷한 작업이 실제로 얼마나 걸렸나?
✓ 작업하는 사람을 참여시켜라 — 당신만이 아니라
✓ ESTIMATE와 COMMITMENT를 구분하라(deadline은 추측이 아니라 협상이다)
구체적인 예시
"새 대시보드 얼마나 걸려요?"라는 질문에 "2주"라고 말하지 마십시오. 이렇게 말하십시오. "알려진 작업은 약 2주입니다. reporting API에 미지수가 있는데, 깔끔하면 2주, 아니면 4주에 가깝습니다. 하루짜리 spike 후에 더 알 수 있습니다."
패딩을 정직하게 관리하라
몰래 추정을 부풀리지 말고, 낙관주의가 추정을 짓밟게 두지도 마십시오. 불확실성을 명시적으로 만들어 stakeholder가 놀라는 대신 정보에 입각한 트레이드오프를 할 수 있게 하십시오.
왜 중요한가
나쁜 추정은 신뢰를 침식합니다. "항상 늦는" 팀과 "sandbagging하는" 팀 모두 신뢰성을 잃습니다.
정직한 범위에 가시적인 위험을 더하면 비즈니스가 진짜 트레이드오프 결정을 내리게 하고, 그들을 대신해 내려진 불가능한 약속으로부터 팀을 보호합니다.
