"이번 스프린트 속도가 얼마죠?"
"음... 대충 30 포인트?"
팀의 실제 생산성을 측정하는 것, 생각보다 어렵습니다.
번다운 차트만 보고 있다면, 절반의 진실만 보고 있는 겁니다.
진짜 팀 속도를 아는 것이 왜 중요할까요?
예측 가능한 일정, 지속 가능한 페이스, 그리고 팀의 성장.
이 모든 것이 정확한 속도 측정에서 시작됩니다.
오늘은 번다운 차트를 넘어서,
팀의 진짜 생산성을 측정하는 5가지 과학적 방법을 소개합니다.
번다운 차트의 맹점
번다운 차트가 보여주지 못하는 것들이 있습니다.
# 번다운이 놓치는 것들
hidden_metrics = {
"재작업": "버그 수정으로 돌아간 시간",
"컨텍스트 스위칭": "작업 전환 비용",
"기술 부채": "나중을 위해 미룬 작업",
"학습 곡선": "새로운 기술 습득 시간",
"커뮤니케이션": "회의와 리뷰 시간"
}
이런 숨겨진 작업들이 팀의 실제 속도를 왜곡시킵니다.
지표 1: 처리량(Throughput)
"완료된 작업의 개수"
가장 단순하지만 강력한 지표입니다.
const weeklyThroughput = {
week1: { completed: 12, started: 15 },
week2: { completed: 8, started: 20 }, // 문제 신호!
week3: { completed: 15, started: 15 },
week4: { completed: 14, started: 14 },
};
// 평균 처리량: 12.25 작업/주
// 표준편차: 3.09 (변동성 체크)
시작한 작업보다 완료한 작업이 적다면?
WIP(Work In Progress)가 쌓이고 있다는 위험 신호입니다.
지표 2: 사이클 타임(Cycle Time)
"작업 시작부터 완료까지의 시간"
def calculate_cycle_time(task):
"""실제 작업 시간 계산"""
start = task.started_at
end = task.completed_at
# 주말과 공휴일 제외
working_days = exclude_weekends_holidays(start, end)
# 블로킹 시간 제외
blocked_time = task.blocked_duration
return working_days - blocked_time
# 작업 유형별 평균 사이클 타임
cycle_times = {
"버그 수정": 0.5, # 일
"기능 개발": 3.2, # 일
"리팩토링": 2.1, # 일
"문서 작성": 1.0 # 일
}
사이클 타임이 길어진다면 병목이 어디 있는지 찾아야 합니다.
지표 3: 리드 타임(Lead Time)
"요청부터 배포까지의 전체 시간"
사이클 타임과 다른 점은 대기 시간도 포함한다는 것입니다.
리드 타임 = 대기 시간 + 사이클 타임
요청 → [대기] → 시작 → [작업] → 완료 → [대기] → 배포
└─────────────── 리드 타임 ──────────────┘
└── 사이클 타임 ──┘
리드 타임이 길다면 프로세스 개선이 필요합니다.
지표 4: 플로우 효율성(Flow Efficiency)
"실제 작업 시간 / 전체 시간"
flow_efficiency = {
"작업 시간": 8, # 실제 코딩, 테스트
"대기 시간": 32, # 리뷰 대기, 배포 대기
"회의 시간": 5, # 논의, 계획
"블로킹": 3 # 의존성 대기
}
efficiency = 8 / (8 + 32 + 5 + 3) # 16.7%
대부분의 팀이 15-20% 수준입니다.
40%를 넘으면 매우 효율적인 팀입니다.
지표 5: 예측 정확도(Forecast Accuracy)
"계획 대비 실제 완료율"
const sprintAccuracy = {
planned: 30, // 계획한 스토리 포인트
completed: 24, // 실제 완료한 포인트
added: 5, // 중간에 추가된 포인트
removed: 3, // 제외된 포인트
};
// 예측 정확도 = 완료 / 계획 * 100
const accuracy = (24 / 30) * 100; // 80%
// 스코프 변동률
const scopeChange = ((5 - 3) / 30) * 100; // 6.7%
정확도가 70% 미만이면 계획 방식을 개선해야 합니다.
실전: 대시보드 구성하기
이 5가지 지표를 한눈에 볼 수 있는 대시보드를 만들어보세요.
class VelocityDashboard:
def __init__(self, team_data):
self.data = team_data
def weekly_report(self):
return {
"throughput": self.calculate_throughput(),
"avg_cycle_time": self.calculate_cycle_time(),
"avg_lead_time": self.calculate_lead_time(),
"flow_efficiency": self.calculate_efficiency(),
"forecast_accuracy": self.calculate_accuracy(),
"trend": self.analyze_trend()
}
def analyze_trend(self):
"""속도 변화 추세 분석"""
if self.is_improving():
return "📈 개선 중"
elif self.is_stable():
return "➡️ 안정적"
else:
return "📉 주의 필요"
속도 개선 전략
측정했으면 개선해야죠.
1. WIP 제한으로 처리량 증가
WIP 제한 전: 10개 동시 진행 → 주 5개 완료
WIP 제한 후: 3개 동시 진행 → 주 8개 완료
2. 자동화로 사이클 타임 단축
automation_impact = {
"수동 테스트": 4, # 시간
"자동 테스트": 0.5, # 시간
"시간 절약": 3.5 # 시간/작업
}
3. 병목 제거로 플로우 효율성 개선
가장 큰 대기 시간부터 제거하세요.
보통 코드 리뷰나 QA 단계가 병목입니다.
팀별 벤치마크
스타트업 (5명):
throughput: 15-20 작업/주
cycle_time: 1-2일
efficiency: 25-35%
중견기업 (20명):
throughput: 40-60 작업/주
cycle_time: 2-4일
efficiency: 20-30%
대기업 (100명+):
throughput: 150-200 작업/주
cycle_time: 3-7일
efficiency: 10-20%
작은 팀일수록 효율성이 높은 이유가 보이시나요?
마무리: 측정할 수 없으면 개선할 수 없다
번다운 차트는 시작일 뿐입니다.
진짜 팀 속도를 알려면:
- 처리량으로 생산성을
- 사이클 타임으로 속도를
- 플로우 효율성으로 낭비를
- 예측 정확도로 계획 능력을
측정하고, 추적하고, 개선하세요.
"측정하지 않는 것은 관리할 수 없고,
관리하지 않는 것은 개선할 수 없습니다."
정확한 팀 속도 측정과 개선이 필요하신가요? Plexo를 확인해보세요.
댓글 없음:
댓글 쓰기