한 스프린트의 기록이 지표가 되는 과정
아래 화면은 Launchpad Sprint 1의 열흘(10월 12일~23일)을 날짜별로 다시 그린 것이다. 왼쪽 보드는 Project의 Status 열이고, 오른쪽 그래프는 같은 날짜까지의 기록으로 계산한 계획가치(PV), 획득가치(EV), 실제 투입(AC)이다. 재생하거나 날짜 막대를 움직이면 카드의 이동과 지표의 변화가 함께 보인다.
10월 14일에 LP-03이 정책 결정을 기다리며 멈추자 EV는 9h에서 이틀 동안 거의 늘지 않고, 같은 기간 PV는 12h에서 32h로 늘었다. 회의에서 “LP-03이 늦다”는 말을 듣기 전에 SPI가 0.75에서 0.37로 떨어지는 것으로 먼저 확인할 수 있다. 3회차는 이 계산을 실습 저장소의 실제 데이터로 한다.
방법론과 GitHub 데이터의 대응
| 방법론 | PM이 묻는 질문 | GitHub에 남는 데이터 | 도구 | 실습 |
|---|---|---|---|---|
| 작업 분해 구조(WBS) | 출시 목표를 끝내려면 어떤 일이 있어야 하는가 | 상위 이슈와 하위 이슈 | gh issue edit --add-sub-issue | 13 |
| 주경로법(CPM) | 어느 일이 늦어지면 출시가 늦어지는가 | 의존성(Blocked by), 작업일 수, Start date·Target date | cpm.sh | 13 |
| 획득가치관리(EVM) | 계획 대비 얼마나 끝냈고, 앞으로 얼마나 더 드는가 | Estimate, Actual, 완료 조건 체크박스, Status | evm-report.sh | 14 |
| 획득 일정(Earned Schedule) | 지금 며칠 늦었고, 언제 끝나는가 | EVM과 같은 데이터 | evm-report.sh | 14 |
| 번업 차트 | 전체 범위와 끝낸 양이 각각 어떻게 늘었는가 | Estimate 합계, 획득가치의 추이 | EVM 계산기 그래프 | 14 |
| 칸반 흐름 지표 | 일이 들어와서 끝나기까지 얼마나 걸리는가 | 이슈의 생성·종료 시각, PR의 생성·리뷰·병합 시각 | flow-metrics.sh | 15 |
| 리틀의 법칙 | 동시에 진행 중인 일이 너무 많은가 | Status가 In Progress·In Review인 항목 수 | flow-metrics.sh --project | 15 |
| 몬테카를로 예측 | 남은 일이 마감까지 끝날 확률은 얼마인가 | 주별 완료 이슈 수 | forecast.sh | 15 |
| 위험 등록부 | 무엇이 일정을 위협하는가 | risk 라벨 이슈, Probability·Impact 필드 | gh project item-list --jq | 16 |
| RAG 상태 보고 | 이해관계자에게 무엇을 알리고 무엇을 결정받는가 | 위 지표의 결과 | templates/status-report.md | 16 |
| MoSCoW, RICE | 무엇을 먼저 하는가 | Priority 필드, Reach·Impact·Confidence·Effort 숫자 필드 | gh project item-list --jq | 아래 예 |
| RACI | 누가 실행하고 누가 승인하는가 | 담당자(Assignee), 리뷰어, CODEOWNERS 파일 | 저장소 설정 | - |
표의 도구 열에 있는 스크립트는 모두 실습 키트에 있다. GitHub에서 데이터를 읽는 명령은 gh가 하고, 계산은 로컬의 jq와 awk가 한다. 계산 스크립트는 GitHub에 아무것도 쓰지 않는다.
지표가 나오려면 기록이 먼저 있어야 한다
방법론의 지표는 기록의 품질을 넘지 못한다. 예를 들어 Actual을 2주 동안 입력하지 않으면 AC는 0이고, CPI는 계산되지 않는다. 3회차를 팀에 적용할 때는 아래 기록 규칙을 먼저 합의한다.
| 기록 | 누가 | 언제 | 빠지면 생기는 일 |
|---|---|---|---|
| Estimate(추정 공수, 시간) | 실행 담당자와 PM | 스프린트 계획 회의에서, 시작 전에 한 번 | BAC와 PV가 없다. 시작 후에 바꾸면 기준선이 흔들린다 |
| Start date, Target date | PM (cpm.sh 결과) | 계획 회의 직후 | PV 곡선을 그릴 수 없다 |
| Actual(실제 투입, 누적 시간) | 실행 담당자 | 매주 금요일 | AC, CPI, EAC가 없다 |
| 완료 조건 체크박스 | 실행 담당자 | 조건을 충족한 날 | 진행 중 업무의 EV가 0으로 계산된다 |
| Status, 이슈 종료 사유 | 실행 담당자, 검수자 | 바뀐 날 | 처리량과 리드 타임이 틀어진다 |
참고: RICE 점수로 백로그 정렬
RICE는 도달(Reach) × 영향(Impact) × 확신(Confidence) ÷ 노력(Effort)으로 우선순위 점수를 매기는 방식이다. Project에 숫자(NUMBER) 필드 네 개를 만들고 값을 넣으면 아래 명령 하나로 점수 순 목록을 얻는다. 필드 이름이 Reach이면 JSON 키는 첫 글자를 소문자로 바꾼 reach다.
gh project item-list "$PM_PROJECT" --owner "$PM_OWNER" --limit 200 --format json \
--jq '.items | map(select(.reach and .impact and .confidence and .effort)
| . + {rice: (.reach * .impact * .confidence / .effort)})
| sort_by(-.rice) | .[] | "\(.rice | . * 10 | round / 10) \(.content.title)"'
1200 [LP-07] 신청의 유입 경로를 기록한다 350 [LP-09] 신청 완료 메일을 보낸다
- 재생 화면에서 LP-03이 막힌 기간에 SPI가 어떻게 변하는지 확인했다.
- EVM에 필요한 GitHub 데이터 네 가지를 말할 수 있다.
- 몬테카를로 예측에 쓰는 데이터가 무엇인지 말할 수 있다.
마치며...
3회차에서 다룰 방법론마다 필요한 GitHub 데이터를 대응시켰고, 지표가 기록 규칙에 달려 있다는 점을 재생 화면의 숫자로 확인했다. 실습 13에서는 출시 목표를 작업 분해 구조로 나누고, 작업일과 선행 관계로 주경로를 계산한다.