왜 당신의 마감일은 잘못되었을까요? 소프트웨어 개발에 기반한 추정 방법

카테고리

프로그래밍/소프트웨어 개발

서브카테고리

개발 툴

대상자

소프트웨어 개발자, 프로젝트 매니저, 팀 리더

핵심 요약

• 전통적인 마감일 설정은 25-50%의 과소평가로 인해 실패율이 높음
• "Estimation Sprints" 방식은 불확실성을 줄이고 반복적 추정을 통해 마감일을 예측 가능하게 만듦
• 예측 범위(예: 3-5일)를 사용해 기술적 불확실성을 반영하고, 역사적 데이터를 기반으로 추정을 조정

섹션별 세부 요약

1. 전통적인 추정의 문제점

• 개발자들은 복잡한 기능을 평균 2-3배 더 오래 소요됨
• 불확실성(예: 4배의 오차 범위)을 무시하고 단일 추정을 요구
• 중단(예: 회의, 코드 리뷰)으로 인한 집중력 저하(23분 재집중 소요)

2. Estimation Sprints 방법론

• 1-2일의 "Discovery Sprint"로 기술적 위험 요소를 탐색
• 주요 활동:
• 위험한 기술 접근법 테스트
• 제3자 통합 조사
• 예외 상황 식별
• 개념 검증 구현
• 결과물: 신뢰도 구간과 위험 요소 포함된 개선된 추정**

3. 사례 연구

• 전자상거래 회사의 결제 시스템 이관:

- 기존 추정: 2주 → 실제 소요: 6주(생산 문제 발생)

- Estimation Sprints: 4.5주 완료, 0개의 생산 문제 발생

• 개인화 추천 기능 추가:

- 기존 추정: 1개월 → 수정 추정: 6주(단계적 출시)

- 결과: 5.5주 완료, 94%의 기초 지표 정확도 달성

4. 추정 개선 전략

• 단일 추정 대신 범위 제공:

- "모든 것이 잘 된다면 3-5일, 일반적인 장애물 시 5-8일, 주요 불확실 시 8-12일"

• 역사적 데이터 추적:

- 작업 설명, 초기 추정, 실제 소요 시간, 주요 장애물, 학습 요약

• "Premortem" 연습:

- 프로젝트 실패 시 상황 상상 → 흔한 위험 요소 식별(예: API 제한, 데이터베이스 성능 문제)

결론

• "Estimation Sprints"를 도입해 불확실성을 탐색하고, 범위 추정과 역사적 데이터를 기반으로 예측을 조정
• 단일 추정 대신 "90% 신뢰 수준"의 범위 제공
• 예: "2-3일 소요(90% 확률), 10% 확률로 데이터베이스 성능 문제로 인해 1주일 소요 가능"