cd ~/gh-pm-lab source pm-lab/env.sh
1흐름 지표 네 가지
| 지표 | 정의 | GitHub 데이터 |
|---|---|---|
| 처리량(throughput) | 일정 기간에 끝낸 업무 수. 이 과정은 주 단위 | 완료(completed)로 닫힌 이슈의 closedAt |
| 리드 타임(lead time) | 업무가 만들어진 때부터 끝날 때까지 걸린 시간 | 이슈의 createdAt과 closedAt |
| PR 사이클 타임 | PR을 연 때부터 병합까지 걸린 시간 | PR의 createdAt과 mergedAt |
| 진행 중 업무(WIP) | 지금 시작했지만 끝나지 않은 업무 수 | Status가 In Progress, In Review인 항목 |
세 값 사이에는 리틀의 법칙(Little's law)이 성립한다. 평균 진행 중 업무 수 = 평균 처리량 × 평균 리드 타임. John Little이 1961년에 증명한 식이다. 팀이 주 평균 2건을 끝내고 평균 리드 타임이 1.5주이면 평균 3건이 진행 중이다. 처리량이 같은 채로 진행 중 업무가 6건으로 늘면 리드 타임은 3주로 늘어난다. 동시에 시작하는 일이 늘면 하나하나가 끝나는 날은 늦어진다.
2흐름 지표 계산
flow-metrics.sh는 이번 주를 뺀 최근 N주를 조회한다. 조회만 하며 jq 없이 동작한다. 실습 저장소는 이슈가 적어 대부분의 주가 0으로 나온다. 실제 데이터로 보려면 활동이 많은 공개 저장소를 같은 명령으로 조회한다.
bash github-pm-starter-kit/flow-metrics.sh "$PM_REPO" --weeks 8 --project "$PM_PROJECT" bash github-pm-starter-kit/flow-metrics.sh cli/cli --weeks 8
위 재현 화면은 지난 프로젝트 8주의 기록을 가정한 예시다. 마지막 줄의 --throughput 2,3,1,4,2,3,2,0이 다음 단계의 입력이다. 처리량이 0인 주(9월 28일 주)도 빼지 않는다. 휴가나 장애로 아무것도 끝내지 못한 주도 실제로 일어나는 주이기 때문이다.
3몬테카를로 시뮬레이션의 원리
남은 업무는 Sprint 1을 마친 10월 26일 기준으로 LP-02부터 LP-06까지 5건이다. 시행 하나는 다음과 같이 진행한다.
- 과거 8주의 처리량 중 하나를 무작위로 뽑아 1주차에 끝낼 업무 수로 쓴다. 예: 3건이 나오면 남은 업무는 2건.
- 남은 업무가 0 이하가 될 때까지 2주차, 3주차를 같은 방법으로 뽑는다.
- 걸린 주 수를 기록한다. 예: 3, 0, 2가 나오면 3주.
이 시행을 1만 번 반복하면 “2주에 끝난 시행 46%, 3주 37%, 4주 13%”처럼 완료 주 수의 분포가 나온다. 누적 비율이 85%에 처음 도달하는 주 수가 “85% 확률로 이 안에 끝난다”는 답이다. 과거 처리량을 그대로 다시 뽑으므로 업무 크기와 일하는 방식이 과거와 비슷하다는 가정이 들어 있다.
bash github-pm-starter-kit/forecast.sh --remaining 5 \ --throughput 2,3,1,4,2,3,2,0 --start 2026-10-26 --deadline 2026-11-06
4계산기
아래 계산기는 forecast.sh와 같은 난수 생성기와 시드(42)를 쓰므로 같은 입력이면 같은 결과가 나온다. “시행 하나 보기”를 누르면 시행 한 번이 어떻게 진행되는지 한 주씩 보여 준다. 남은 업무 수, 처리량, 마감일을 바꿔 결과가 어떻게 움직이는지 확인한다.
계산기로 두 가지를 확인한다. 남은 업무를 5건에서 4건으로 줄이면(LP-04 알림을 M2로 미루는 경우) 11월 6일까지 끝낼 확률이 얼마가 되는가. 처리량 목록에서 0을 지우면 결과가 얼마나 낙관적으로 바뀌는가.
5두 예측 비교
| 구분 | EVM과 획득 일정 (실습 14) | 몬테카를로 (실습 15) |
|---|---|---|
| 입력 | 추정 공수, 기준선 일정, 체크박스, 실제 투입 | 과거 주별 완료 수, 남은 업무 수 |
| 결과 | 예상 완료일 하나: 11월 19일(목) | 50% 11월 13일, 85% 11월 20일, 11월 6일까지 46% |
| 가정 | 지금까지의 일정 효율(SPI(t) 0.62)이 계속된다 | 업무 크기와 처리량의 분포가 과거와 같다 |
| 필요한 기록 | Estimate, Actual을 꾸준히 입력해야 한다 | 이슈를 완료로 닫기만 하면 된다 |
| 약한 경우 | 추정이 틀리거나 범위가 바뀔 때 | 업무 크기가 들쭉날쭉하거나 과거 기록이 짧을 때 |
두 방법 모두 M1 마감(11월 6일)이 위험하다는 결론을 낸다. EVM은 “9작업일 늦다”는 크기를, 몬테카를로는 “지킬 확률이 절반에 못 미친다”는 가능성을 알려 준다. 상태 보고에는 두 결과를 함께 쓰고, 둘이 다르면 그 이유(가정의 차이)를 적는다.
실습 14의 EVM 그래프는 시간 기준 번업 차트다(BAC 선이 범위, EV 선이 끝낸 양). 업무 수 기준으로 보려면 closedAt의 누적 개수와 마일스톤의 전체 이슈 수를 같은 축에 그린다. 실습 2의 마일스톤 조회 명령이 주는 open_issues와 closed_issues를 매주 기록하면 그 데이터가 된다.
- 리틀의 법칙으로 처리량, 리드 타임, 진행 중 업무 수 사이의 관계를 숫자 예로 설명할 수 있다.
flow-metrics.sh를 실습 저장소와 공개 저장소에서 실행했다.forecast.sh결과에서 50%, 85% 완료일과 마감까지 끝낼 확률을 읽었다.- 계산기에서 남은 업무를 4건으로 줄였을 때의 확률을 확인했다.
- EVM 예측과 몬테카를로 예측이 다른 이유를 가정의 차이로 설명할 수 있다.
막히면
| 증상 | 확인과 해결 |
|---|---|
| 처리량이 모두 0 | 최근 N주에 완료로 닫힌 이슈가 없다. --weeks를 늘리거나 공개 저장소로 연습한다. 계획 취소로 닫은 이슈는 세지 않는다. |
오류: 과거 처리량이 모두 0이어서 예측할 수 없다. | 처리량이 0뿐이면 시행이 끝나지 않는다. 기록을 더 쌓은 뒤 예측한다. |
오류: 날짜를 읽지 못했다 | --start, --deadline을 2026-10-26 형식으로 쓴다. |
| 공개 저장소 조회가 느림 | 이슈와 PR이 많으면 최대 1,000건을 조회한다. --weeks 4로 줄인다. |
마치며...
이슈와 PR의 시각 기록으로 처리량, 리드 타임, PR 사이클 타임을 계산했고, 과거 8주의 처리량으로 남은 5건이 11월 6일까지 끝날 확률이 46%라는 결과를 얻었다. EVM의 예상 완료일(11월 19일)과 함께 놓으면 같은 위험을 크기와 확률 두 방향에서 설명할 수 있다. 실습 16에서는 지금까지의 결과를 위험 등록부와 함께 상태 보고서 한 장으로 정리한다.