Spec finding rate cần đọc cẩn thận vì nó không có hướng "tốt" đơn giản:
Cao và giảm dần qua các sprint — lành mạnh. Giai đoạn G3 đang làm đúng việc, PRD đang tốt lên.
Cao và không giảm — PRD viết chưa đủ kỹ, cần quay lại chỉnh cách làm ở G1–G2.
Bằng không — đáng ngờ nhất. Hoặc PRD hoàn hảo (hiếm), hoặc DEV đang sinh spec bằng cách chép lại PRD mà không thực sự đọc. Kiểm bằng cách xem spec có trường hợp biên không.
6.3 Nhóm chất lượng và tài liệu
Chỉ số
Công thức
AC coverage
AC có test / tổng AC — mục tiêu 100%, kiểm bằng /trace
Defect density
Defect / feature
Defect escape rate
Defect ở UAT / tổng defect
UAT pass rate lần 1
Feature pass ngay lần đầu / tổng
Doc coverage
Issue có link PRD hợp lệ / tổng issue
Spec coverage
Issue có spec approved / tổng issue
6.4 Cảnh báo rủi ro sớm
Dấu hiệu
Ngưỡng
Issue quá hạn milestone
bất kỳ
Issue in-dev quá lâu
> 2× cycle time trung vị
Issue `spec` quá lâu
> 3 ngày — PRD có vấn đề
Estimate lệch lớn
spend/estimate > 1.5 hoặc < 0.5
AC không có test
bất kỳ — chặn DoD
Spec bám PRD baseline cũ
bất kỳ — kiểm trường `prd_baseline`
PRD đổi sau baseline không có CR
bất kỳ — rủi ro pháp lý khi quyết toán
Open question P1 tồn đọng
> 5 ngày
Defect Sev1/Sev2 mở
> 3 ngày
6.5 Lấy dữ liệu từ GitLab
# .env: GITLAB_TOKEN, GITLAB_URL, PROJECT_ID
# Issue trong sprint, kèm time_stats
curl -s --header "PRIVATE-TOKEN: $GITLAB_TOKEN" \
"$GITLAB_URL/api/v4/projects/$PROJECT_ID/issues?milestone=Sprint%2005&per_page=100" \
> 06-reports/raw/sprint05-issues.json
# Lịch sử label → tính cycle time và spec time
curl -s --header "PRIVATE-TOKEN: $GITLAB_TOKEN" \
"$GITLAB_URL/api/v4/projects/$PROJECT_ID/issues/42/resource_label_events" \
> 06-reports/raw/issue-42-labels.json
⚠️ Đừng đo BA bằng số dòng tài liệu, đừng đo DEV bằng số dòng code. Cả hai đều bị "chơi" được trong một tuần. Dùng các chỉ số trên để quan sát xu hướng của quy trình, không để chấm điểm cá nhân. Nếu team biết số liệu dùng để đánh giá lương thưởng, số liệu sẽ ngừng phản ánh sự thật.