Bài 7 — Duy trì RTM sống & Quản lý phiên bản khi yêu cầu thay đổi liên tục
Vấn đề thật: RTM chết sau 2 sprint
Đa số RTM đẹp lúc mới lập rồi "chết" — vì yêu cầu đổi mỗi tuần mà không ai cập nhật. Một RTM lỗi thời còn nguy hiểm hơn không có, vì nó tạo cảm giác an toàn giả. Bài này giúp bạn dùng AI để giữ RTM sống với chi phí thấp, và quản lý phiên bản để luôn truy được "tại thời điểm đó, yêu cầu là gì".
Nguyên tắc RTM sống
- Mỗi thay đổi đều để lại dấu vết: ai đổi, đổi gì, vì sao, khi nào.
- Baseline theo mốc (mỗi release có một bản đóng băng để đối chiếu).
- AI làm việc so sánh (diff), con người duyệt và ghi quyết định.
Ví dụ cụ thể + prompt so sánh phiên bản
Khi có RTM cũ và loạt yêu cầu mới, dùng AI để tạo "changelog":
Bạn là trợ lý BA quản lý phiên bản RTM.
So sánh RTM_CŨ với DANH_SÁCH_YÊU_CẦU_MỚI và xuất CHANGELOG gồm:
- THÊM MỚI: REQ mới chưa có trong RTM (cần map test).
- ĐÃ SỬA: REQ có mô tả thay đổi (chỉ ra khác biệt cụ thể + test có thể phải cập nhật).
- GỠ BỎ: REQ trong RTM nhưng không còn trong danh sách mới (cảnh báo test/US mồ côi).
- KHÔNG ĐỔI: chỉ đếm số lượng.
Sau đó liệt kê HÀNH ĐỘNG CẦN LÀM cho BA, ưu tiên theo rủi ro.Quy tắc: chỉ dựa trên dữ liệu cung cấp; không bịa REQ;
nếu không chắc một REQ là 'sửa' hay 'mới', ghi [CẦN BA XÁC NHẬN].
[RTM_CŨ]
REQ-051: Giỏ hàng giữ 30 phút | TC-40, TC-41
REQ-052: Nhắc khách trước khi hết hạn | TC-42
[DANH_SÁCH_YÊU_CẦU_MỚI]
REQ-051: Giỏ hàng giữ 15 phút
REQ-052: Nhắc khách trước khi hết hạn
REQ-055: Cho phép gia hạn giỏ hàng 1 lần
AI sẽ báo: REQ-051 đã sửa (30→15 phút, TC-40/41 cần cập nhật), REQ-055 mới (chưa có test), REQ-052 không đổi. Đó là changelog để bạn hành động, không phải dò tay.
Các bước duy trì RTM sống
- Quy ước: mọi CR được duyệt phải kèm cập nhật RTM trong cùng ticket (định nghĩa "Done").
- Cuối mỗi sprint, chạy prompt diff giữa RTM baseline và yêu cầu hiện tại.
- BA duyệt changelog: cập nhật mapping, đánh dấu test cần sửa, gỡ mồ côi.
- Tăng version RTM (v1.1, v1.2...) và ghi ngày + lý do.
- Trước mỗi release, đóng băng một baseline mới để đối chiếu về sau.
- Lưu lịch sử version (Google Sheet có history, hoặc Git nếu RTM ở dạng CSV/markdown).
Template Version Control cho RTM (tái dùng)
[RTM CHANGELOG]
Phiên bản: v____ Ngày: ____ Người cập nhật: ____ CR liên quan: ____THÊM MỚI: (REQ + đã map test? Y/N)
ĐÃ SỬA: (REQ | khác biệt | test cần cập nhật)
GỠ BỎ: (REQ | xử lý test/US mồ côi)
Quyết định & lý do: ____
Baseline kế tiếp đóng băng ngày: ____
[DEFINITION OF DONE cho một CR]
[ ] RTM đã cập nhật [ ] Test đã đồng bộ [ ] Không còn mồ côi
[ ] Changelog đã ghi [ ] Version đã tăng
Sai lầm thường gặp
- Không đưa cập nhật RTM vào "Definition of Done". Thiếu ràng buộc quy trình, RTM chắc chắn lụi tàn. Gắn nó vào ticket, không để "làm sau".
- Ảo giác trong diff. AI có thể xếp nhầm một REQ sửa nhỏ thành "mới", tạo trùng lặp. Ép nó gắn [CẦN BA XÁC NHẬN] khi không chắc và tự kiểm mẫu.
- Không quản version → khi audit hỏi "lúc release 2.0 yêu cầu là gì", bạn không trả lời được. Baseline theo mốc là bắt buộc.
- Gỡ REQ mà quên test/US mồ côi → nợ kỹ thuật ẩn. Changelog phải bắt buộc xử lý phần mồ côi.
- Phụ thuộc quá mức vào diff của AI thay vì hiểu vì sao yêu cầu đổi. AI thấy "cái gì đổi", nhưng "vì sao đổi" (và có nên đổi không) là phán đoán của BA.
- Rò rỉ dữ liệu: lịch sử RTM tích lũy nhiều thông tin nhạy cảm; kiểm soát quyền truy cập file lịch sử.