<div id="readability-page-1" class="page"><div id="post-body-8001710575120334730" itemprop="articleBody">
<a href="https://blogger.googleusercontent.com/img/a/AVvXsEjHksXebtmWT-bnRlt9tJle88-vff5pOGCIAPynlentLOQ6D4Qm-czo4bUKtUBtmIS5qMvT7m97nFDveTWVpwJnXZBnn9rDonBZJjZeSwU_-L4l4H7Ld4EUQqmvFmYCWHXUiXPSz96ufLykEFWkWMRHzE74kcKt671eiPAK5IcSOxjtfBeNT4k3ot5-ktM"><img alt="" data-original-height="1024" data-original-width="1024" height="280" src="https://blogger.googleusercontent.com/img/a/AVvXsEjHksXebtmWT-bnRlt9tJle88-vff5pOGCIAPynlentLOQ6D4Qm-czo4bUKtUBtmIS5qMvT7m97nFDveTWVpwJnXZBnn9rDonBZJjZeSwU_-L4l4H7Ld4EUQqmvFmYCWHXUiXPSz96ufLykEFWkWMRHzE74kcKt671eiPAK5IcSOxjtfBeNT4k3ot5-ktM=w640-h640" width="280"></a>&nbsp;"이번 스프린트 속도가 얼마죠?""음... 대충 30 포인트?"팀의 실제 생산성을 측정하는 것, 생각보다 어렵습니다. 번다운 차트만 보고 있다면, 절반의 진실만 보고 있는 겁니다.진짜 팀 속도를 아는 것이 왜 중요할까요?예측 가능한 일정, 지속 가능한 페이스, 그리고 팀의 성장. 이 모든 것이 정확한 속도 측정에서 시작됩니다.오늘은 번다운 차트를 넘어서, 팀의 진짜 생산성을 측정하는 5가지 과학적 방법을 소개합니다.<h2 data-source-line="18" id="번다운-차트의-맹점">번다운 차트의 맹점</h2>번다운 차트가 보여주지 못하는 것들이 있습니다.<pre data-info="python {data-source-line=&quot;22&quot;}" data-role="codeBlock" data-source-line="22"><code># 번다운이 놓치는 것들
hidden_metrics = {
 "재작업": "버그 수정으로 돌아간 시간",
 "컨텍스트 스위칭": "작업 전환 비용",
 "기술 부채": "나중을 위해 미룬 작업",
 "학습 곡선": "새로운 기술 습득 시간",
 "커뮤니케이션": "회의와 리뷰 시간"
}
</code></pre>이런 숨겨진 작업들이 팀의 실제 속도를 왜곡시킵니다.<h2 data-source-line="35" id="지표-1-처리량throughput">지표 1: 처리량(Throughput)</h2>"완료된 작업의 개수"가장 단순하지만 강력한 지표입니다.<pre data-info="javascript {data-source-line=&quot;41&quot;}" data-role="codeBlock" data-source-line="41"><code>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 (변동성 체크)
</code></pre>시작한 작업보다 완료한 작업이 적다면? WIP(Work In Progress)가 쌓이고 있다는 위험 신호입니다.<h2 data-source-line="56" id="지표-2-사이클-타임cycle-time">지표 2: 사이클 타임(Cycle Time)</h2>"작업 시작부터 완료까지의 시간"<pre data-info="python {data-source-line=&quot;60&quot;}" data-role="codeBlock" data-source-line="60"><code>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 # 일
}
</code></pre>사이클 타임이 길어진다면 병목이 어디 있는지 찾아야 합니다.<h2 data-source-line="85" id="지표-3-리드-타임lead-time">지표 3: 리드 타임(Lead Time)</h2>"요청부터 배포까지의 전체 시간"사이클 타임과 다른 점은 대기 시간도 포함한다는 것입니다.<pre data-info="{data-source-line=&quot;91&quot;}" data-role="codeBlock" data-source-line="91"><code>리드 타임 = 대기 시간 + 사이클 타임

요청 → [대기] → 시작 → [작업] → 완료 → [대기] → 배포
└─────────────── 리드 타임 ──────────────┘
 └── 사이클 타임 ──┘
</code></pre>리드 타임이 길다면 프로세스 개선이 필요합니다.<h2 data-source-line="101" id="지표-4-플로우-효율성flow-efficiency">지표 4: 플로우 효율성(Flow Efficiency)</h2>"실제 작업 시간 / 전체 시간"<pre data-info="python {data-source-line=&quot;105&quot;}" data-role="codeBlock" data-source-line="105"><code>flow_efficiency = {
 "작업 시간": 8, # 실제 코딩, 테스트
 "대기 시간": 32, # 리뷰 대기, 배포 대기
 "회의 시간": 5, # 논의, 계획
 "블로킹": 3 # 의존성 대기
}

efficiency = 8 / (8 + 32 + 5 + 3) # 16.7%
</code></pre>대부분의 팀이 15-20% 수준입니다. 40%를 넘으면 매우 효율적인 팀입니다.<h2 data-source-line="119" id="지표-5-예측-정확도forecast-accuracy">지표 5: 예측 정확도(Forecast Accuracy)</h2>"계획 대비 실제 완료율"<pre data-info="javascript {data-source-line=&quot;123&quot;}" data-role="codeBlock" data-source-line="123"><code>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%
</code></pre>정확도가 70% 미만이면 계획 방식을 개선해야 합니다.<h2 data-source-line="140" id="실전-대시보드-구성하기">실전: 대시보드 구성하기</h2>이 5가지 지표를 한눈에 볼 수 있는 대시보드를 만들어보세요.<pre data-info="python {data-source-line=&quot;144&quot;}" data-role="codeBlock" data-source-line="144"><code>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 "📉 주의 필요"
</code></pre><h2 data-source-line="169" id="속도-개선-전략">속도 개선 전략</h2>측정했으면 개선해야죠.<h3 data-source-line="173" id="1-wip-제한으로-처리량-증가">1. WIP 제한으로 처리량 증가</h3><pre data-info="{data-source-line=&quot;175&quot;}" data-role="codeBlock" data-source-line="175"><code>WIP 제한 전: 10개 동시 진행 → 주 5개 완료
WIP 제한 후: 3개 동시 진행 → 주 8개 완료
</code></pre><h3 data-source-line="180" id="2-자동화로-사이클-타임-단축">2. 자동화로 사이클 타임 단축</h3><pre data-info="python {data-source-line=&quot;182&quot;}" data-role="codeBlock" data-source-line="182"><code>automation_impact = {
 "수동 테스트": 4, # 시간
 "자동 테스트": 0.5, # 시간
 "시간 절약": 3.5 # 시간/작업
}
</code></pre><h3 data-source-line="190" id="3-병목-제거로-플로우-효율성-개선">3. 병목 제거로 플로우 효율성 개선</h3>가장 큰 대기 시간부터 제거하세요. 보통 코드 리뷰나 QA 단계가 병목입니다.<h2 data-source-line="195" id="팀별-벤치마크">팀별 벤치마크</h2><pre data-info="yaml {data-source-line=&quot;197&quot;}" data-role="codeBlock" data-source-line="197"><code>스타트업 (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%
</code></pre>작은 팀일수록 효율성이 높은 이유가 보이시나요?<h2 data-source-line="216" id="마무리-측정할-수-없으면-개선할-수-없다">마무리: 측정할 수 없으면 개선할 수 없다</h2>번다운 차트는 시작일 뿐입니다.진짜 팀 속도를 알려면:<ul data-source-line="222"><li data-source-line="222">처리량으로 생산성을</li><li data-source-line="223">사이클 타임으로 속도를</li><li data-source-line="224">플로우 효율성으로 낭비를</li><li data-source-line="225">예측 정확도로 계획 능력을</li></ul>측정하고, 추적하고, 개선하세요."측정하지 않는 것은 관리할 수 없고, 관리하지 않는 것은 개선할 수 없습니다."<hr>정확한 팀 속도 측정과 개선이 필요하신가요?&nbsp;<a href="https://plexo.work/">Plexo</a>를 확인해보세요.

</div></div>

All of Software

"이번 스프린트 속도가 얼마죠?"
"음... 대충 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를 확인해보세요.

팀 속도(Velocity) 측정의 과학: 번다운보다 정확한 5가지 지표

댓글