PHẦN 7 — VẬN HÀNH HẰNG NGÀY
7.1 Nhịp vận hành
| Nhịp | Thời điểm | Ai | Nội dung | Thời lượng |
|---|---|---|---|---|
| Daily sync | 9:00 hằng ngày | 3 người | Hôm qua / hôm nay / vướng gì | 15 phút |
| Spec review | Khi có MR spec | BA + DEV | Duyệt từng AC, đóng câu hỏi phát sinh | 30–45 phút |
| Grooming | Thứ Ba | BA + DEV | Đọc trước PRD sắp tới, chốt hướng | 60 phút |
| Sprint planning | Thứ Hai đầu sprint | 3 người | Chốt scope, chạy /dor-check | 60 phút |
| Demo nội bộ | Thứ Năm | 3 người | DEV demo, PM test thử | 30 phút |
| Weekly report | Thứ Sáu chiều | PM | /weekly, gửi khách hàng | 45 phút |
| Sprint review + retro | Cuối sprint | 3 người | Nhìn số liệu, chỉnh quy trình | 90 phút |
Spec review không xếp lịch cố định — chạy ngay khi DEV mở MR spec. Để dồn tới buổi họp tuần sẽ chặn DEV mất nhiều ngày. Sprint 2 tuần: team 3 người mà sprint 1 tuần thì không đủ để một feature đi hết bảy giai đoạn.
7.2 Luật cứng cho AI
Đưa nguyên khối này vào CLAUDE.md gốc:
- Không tự chốt yêu cầu. Giả định ghi vào
open-questions.md, không viết thẳng vào PRD hay spec như thể đã xác nhận. - Không ghi ngoài vùng của mình (Phần 2.3). Ngoại lệ duy nhất: DEV được ghi trong
02-requirements/spec/, qua MR. - Không sửa file `status: baselined` hoặc `status: approved` nếu chưa có CR.
- Không sửa nội dung `00-inbox/` — bằng chứng gốc.
- Không code khi spec chưa `approved`.
- Mọi AC phải có mã. Spec thiếu mã là spec không dùng được.
- Luôn trích dẫn nguồn. Mỗi Business Rule và mỗi mục spec ghi rõ nguồn.
- Không đưa dữ liệu thật của khách hàng vào ví dụ, test data hay commit message.
- Không commit secret.
- Không chạy lệnh phá hủy dữ liệu trên bất kỳ môi trường nào.
- Phát hiện mâu thuẫn giữa tài liệu và code → dừng, báo cáo, không tự chọn bên nào đúng.
- Khi không chắc, hỏi. Một câu hỏi tốn 5 phút; một giả định sai tốn 5 ngày.
7.3 Lộ trình triển khai
| Tuần | Việc làm | Tiêu chí thành công |
|---|---|---|
| 1 | Dựng repo, CLAUDE.md, 3 file role, scoped label | 3 người clone được, AI đọc được luật |
| 2 | Chạy G0→G2 với 1 feature nhỏ. Chưa có spec, chưa đo lường | 1 PRD baseline, mọi AC đã có mã |
| 3 | Thêm G3. DEV sinh spec đầu tiên, BA duyệt | 1 spec approved, thấy được câu hỏi phát sinh |
| 4 | Thêm G4–G5. Test đặt tên theo AC, chạy /trace thủ công | 1 feature đi hết vòng, AC coverage 100% |
| 5 | Đưa /trace vào CI. Bật G6, báo cáo tuần đầu tiên | Pipeline fail khi thiếu test, báo cáo < 45 phút |
| 6–7 | Retro, cắt bỏ thứ không dùng | Quy trình còn lại là thứ team thật sự dùng |
Đừng bật spec ngay tuần đầu. Team cần cảm nhận được nỗi đau "DEV hiểu sai yêu cầu" ít nhất một lần thì mới thấy giai đoạn G3 đáng công.
Dấu hiệu quy trình đang sai: nếu ai đó phải làm việc gì đó "chỉ để cho đúng quy trình" mà không tạo ra giá trị, bỏ bước đó trong retro.
7.4 Điểm dễ hỏng
| Triệu chứng | Nguyên nhân gốc | Cách xử lý |
|---|---|---|
| Spec chỉ là bản chép lại PRD | DEV làm cho có, AI sinh xong không rà | Kiểm mục "trường hợp biên" — chép lại thì mục này rỗng |
| BA duyệt spec qua loa | Coi là thủ tục, không phải điểm chốt | Đưa spec review thành buổi họp có mặt hai người, không duyệt qua comment |
| Spec trôi khỏi PRD sau CR | Quên cập nhật spec khi PRD lên version | Kiểm trường prd_baseline trong CI |
| AC coverage 100% nhưng vẫn lỗi | Test có tên đúng nhưng assert sai | Script không thay được review |
| DEV liên tục hỏi lại BA giữa chừng | Spec chưa đủ, hoặc bỏ qua G3 | Siết DoR |
| PRD và code lệch nhau | Sửa PRD không tag baseline | Bắt buộc link issue → PRD ở tag cụ thể |
| Số liệu PM không khớp thực tế | DEV không /spend hằng ngày | Đưa vào DoD, kiểm ở daily |
| 3 AI cho kết quả mâu thuẫn | glossary.md thiếu | Đầu tư vào glossary — rẻ nhất, hiệu quả nhất |
| Scope phình mà không ai biết | CR bị bỏ qua khi khách hàng "nhờ tí" | Mọi thay đổi sau baseline đều phải có CR |