"추정은 항상 틀린다"는 말이 있습니다.
맞습니다. 하지만 덜 틀리게 할 수는 있습니다.
수백 개 프로젝트를 분석해서 찾은, 추정 정확도를 높이는 실전 팁을 공유합니다.
Tip 1: 작업 유형별 자동 버퍼
모든 작업이 같은 불확실성을 갖지 않습니다.
buffer_rates = {
"신규 개발": 1.3, # 30% 버퍼
"버그 수정": 1.5, # 50% 버퍼
"리팩토링": 1.4, # 40% 버퍼
"외부 API 연동": 2.0, # 100% 버퍼 (2배)
"성능 최적화": 1.8, # 80% 버퍼
"문서 작성": 1.2 # 20% 버퍼
}
def smart_estimate(hours, task_type):
return hours * buffer_rates.get(task_type, 1.3)
# 예시
print(smart_estimate(10, "외부 API 연동")) # 20시간
print(smart_estimate(10, "문서 작성")) # 12시간
핵심: 외부 의존성이 클수록 버퍼를 늘리세요.
Tip 2: 추정 단위 표준화
시간 단위를 표준화하면 착각이 줄어듭니다.
class StandardEstimate:
"""표준 추정 단위"""
UNITS = {
"XS": 2, # 2시간 (커피 한 잔)
"S": 4, # 4시간 (반나절)
"M": 8, # 8시간 (하루)
"L": 16, # 16시간 (이틀)
"XL": 40, # 40시간 (일주일)
"XXL": 80 # 80시간 (2주)
}
@staticmethod
def estimate(size):
if size not in StandardEstimate.UNITS:
return "크기를 다시 생각해보세요"
return StandardEstimate.UNITS[size]
# "3.5일" 같은 애매한 추정 대신
task_size = "L" # 명확하게 "이틀 작업"
Tip 3: 체크리스트 기반 추정
빠뜨리기 쉬운 작업들을 체크리스트로 관리합니다.
## API 개발 체크리스트
- [ ] 설계 검토 (2h)
- [ ] 스키마 정의 (1h)
- [ ] 구현 (4h)
- [ ] 단위 테스트 (2h)
- [ ] 통합 테스트 (2h)
- [ ] 문서 작성 (1h)
- [ ] 코드 리뷰 (1h)
- [ ] 배포 준비 (1h)
총: 14시간 (처음 추정: 6시간)
효과: 평균 40% 누락 작업 발견
Tip 4: 팀 벨로시티 추적
import numpy as np
class TeamVelocity:
def __init__(self):
self.history = []
def add_sprint(self, estimated, actual):
accuracy = actual / estimated
self.history.append(accuracy)
def get_adjustment_factor(self):
if len(self.history) < 3:
return 1.5 # 데이터 부족시 기본 50% 버퍼
# 최근 10개 스프린트 평균
recent = self.history[-10:]
return np.mean(recent)
def predict(self, estimate):
factor = self.get_adjustment_factor()
return {
"raw": estimate,
"adjusted": estimate * factor,
"confidence": self.get_confidence()
}
def get_confidence(self):
if len(self.history) < 5:
return "낮음"
std = np.std(self.history[-10:])
if std < 0.2:
return "높음"
elif std < 0.4:
return "중간"
return "낮음"
Tip 5: 추정 포스트모템
매 스프린트 후 추정 정확도를 분석합니다.
## 스프린트 12 추정 분석
### 정확했던 추정
- UI 컴포넌트 (8h 추정 → 7h 실제) ✅
- 이유: 비슷한 작업 경험 많음
### 부정확했던 추정
- 결제 연동 (8h 추정 → 20h 실제) ❌
- 원인: PG사 문서 부실
- 교훈: 외부 API는 2배 버퍼 필수
### 개선 액션
1. 외부 연동 작업은 무조건 2배 추정
2. 신규 기술 사용시 학습 시간 별도 계상
3. 테스트 작업은 개발 시간의 40% 이상 할당
Tip 6: 불확실성 시각화
def visualize_uncertainty(tasks):
"""불확실성을 시각적으로 표현"""
for task in tasks:
certainty = task['certainty']
bars = '█' * certainty + '░' * (10 - certainty)
print(f"{task['name']:20} {bars} {task['hours']}h")
# 예시
tasks = [
{"name": "로그인 UI", "hours": 4, "certainty": 9},
{"name": "OAuth 연동", "hours": 8, "certainty": 5},
{"name": "보안 감사", "hours": 12, "certainty": 3}
]
visualize_uncertainty(tasks)
# 로그인 UI █████████░ 4h
# OAuth 연동 █████░░░░░ 8h
# 보안 감사 ███░░░░░░░ 12h
불확실성이 높은 작업부터 먼저 착수하세요.
Tip 7: 페어 추정
혼자 추정하지 마세요.
def pair_estimation(dev1_estimate, dev2_estimate):
"""두 명이 함께 추정"""
diff_ratio = abs(dev1_estimate - dev2_estimate) / min(dev1_estimate, dev2_estimate)
if diff_ratio > 0.5: # 50% 이상 차이
print("🚨 큰 차이! 토론 필요")
print(f"개발자1: {dev1_estimate}h")
print(f"개발자2: {dev2_estimate}h")
return "재추정 필요"
# 가중 평균 (경험 많은 개발자에 가중치)
weighted_avg = (dev1_estimate * 0.6 + dev2_estimate * 0.4)
return weighted_avg
Tip 8: 시간대별 생산성 반영
productivity_by_time = {
"월요일 오전": 0.7, # 70% 효율
"월요일 오후": 0.9,
"화-목 오전": 1.0, # 100% 효율
"화-목 오후": 0.9,
"금요일 오전": 0.8,
"금요일 오후": 0.6 # 60% 효율
}
def realistic_schedule(task_hours):
"""실제 생산성을 반영한 일정"""
available_slots = [
("월요일 오전", 4, 0.7),
("월요일 오후", 4, 0.9),
# ...
]
actual_hours_needed = 0
for slot_name, slot_hours, efficiency in available_slots:
effective_hours = slot_hours * efficiency
actual_hours_needed += slot_hours
task_hours -= effective_hours
if task_hours <= 0:
break
return actual_hours_needed
실전 체크리스트
추정 전 확인사항:
- 비슷한 과거 작업 데이터 확인했는가?
- 작업을 8시간 이하로 쪼갰는가?
- 외부 의존성을 파악했는가?
- 테스트/문서/배포 시간을 포함했는가?
- 팀원과 교차 검증했는가?
- 불확실성 레벨을 표시했는가?
- 요일/시간대별 생산성을 고려했는가?
마무리: 완벽한 추정은 없다
추정은 예측이지 약속이 아닙니다.
중요한 건 지속적으로 개선하는 것입니다.
매번 추정하고, 기록하고, 분석하고, 개선하세요.
그러면 "항상 2배 걸린다"에서 "대체로 맞는다"로 발전할 수 있습니다.
기억하세요:
- 추정은 범위다 (단일 값 X)
- 불확실성을 인정하라
- 데이터를 축적하라
- 팀과 함께 추정하라
정확한 일정 추정과 프로젝트 관리가 필요하신가요? Plexo를 확인해보세요.
