리뷰 & 숙지 사이클

문제

5인이 14일 동안 병렬로 달리면 서로 뭘 했는지 모르는 상태가 됩니다. 그 상태에서 통합하면 계약이 안 맞고, 같은 걸 두 번 만들고, 남이 이미 해결한 문제를 또 붙잡습니다.

이걸 막는 유일한 방법은 매일 정해진 시각에 확인하고, 확인 결과를 한 곳에 남기는 것입니다.

상태 흐름 — done 은 PM 만 붙인다

담당자                              PM
  │                                 │
  todo ──▶ doing ──▶ review ────────▶ done
                        │            │
                        └── 반려 ◀───┘
                            (doing 으로 되돌림 + 사유)

아침 정렬 (09:30 · 10분)

한 사람당 90초. 길어지면 PM 이 끊고 따로 이어갑니다.

1. PM 이 오늘 할 일 페이지를 띄우고 당일 관문을 읽는다.
2. 각자 한 문장씩: “어제 무엇을 끝냈고, 오늘 어느 카드를 doing 으로 잡는다.”
3. 막힌 것이 있으면 지금 말한다. 누가 풀어줄지 그 자리에서 지정한다.
4. PM 이 오늘의 선행 의존을 확인한다 — 예: “웹이 로그인 화면 하려면 인증 API 가 오늘 아침에 있어야 한다.”

저녁 리뷰 (18:00 · 30분)

PM 이 실제로 확인하는 시간입니다. 보고를 듣는 시간이 아닙니다.

1단계 — review 카드 판정 (15분)

각 review 카드에 대해 PM 이 다음을 직접 합니다.

판정은 둘 중 하나입니다.

• 통과 → status: done 으로 변경
• 반려 → status: doing 으로 되돌리고, 왜 반려인지 한 줄을 남긴다 (note: 필드)

2단계 — 사이트 갱신 (5분)

PM 이 _data/kanban/*.yml 을 수정하고 커밋합니다.

git add _data/kanban/
git commit -m "review: 9/07 상태 갱신 — done 6, 반려 1"
git push        # → GitHub Actions 가 자동 배포

3단계 — 숙지 (10분)

이게 이 사이클의 핵심입니다. 오늘 done 이 된 카드 중 다른 사람에게 영향을 주는 것을 PM 이 골라 팀 전체에 알립니다.

전달 방식:

1. PM 이 데브로그 1편을 쓴다 — 그날 무엇이 확정됐고, 누가 무엇을 해야 하는지.
2. 팀 채널에 링크와 한 줄 요약을 올린다.
3. 다음 날 아침 정렬에서 영향받는 사람이 “확인했다”고 말한다.

반려 기록

반려는 비난이 아니라 완료 기준을 다시 맞추는 절차입니다. YAML 에 사유를 남깁니다.

- id: BE-07
  status: doing
  note: "반려 9/05 — 로그인은 되지만 중복 이메일이 409 가 아니라 500. 완료 기준 미충족"

주간 리포트 (D-9 · D-2)

PM 이 진행률을 숫자로 정리합니다 (PM-17, PM-37).

• MUST 완료율 · 지연 카드 수 · P0/P1 버그 수
• 트리거에 도달한 리스크
• 다음 구간에서 잘라낼 후보

이 사이클이 지키는 것