Bài 5 — Phát hiện phụ thuộc và rủi ro giữa các story bằng AI

Vấn đề: phụ thuộc ẩn làm vỡ sprint

Story B cần API mà story A mới xây; story C dùng bảng dữ liệu story D chưa tạo. Những phụ thuộc này thường lộ ra giữa sprint — quá muộn. PO khó nhớ hết mối liên hệ khi backlog lớn. Đây là loại lỗi đắt nhất: cả đội chờ nhau, sprint trượt.

AI đọc toàn bộ mô tả cùng lúc và chỉ ra các cặp "cái này cần cái kia trước", đồng thời cảnh báo rủi ro kỹ thuật/nghiệp vụ tiềm ẩn.

Ví dụ cụ thể

Đầu vào 4 story: (A) "Tạo API danh mục sản phẩm", (B) "Hiển thị bộ lọc danh mục ở trang tìm kiếm", (C) "Gửi email xác nhận đơn", (D) "Thiết lập dịch vụ gửi email".

AI nên chỉ: B phụ thuộc A (cần API danh mục trước), C phụ thuộc D (cần dịch vụ email trước). Gợi ý thứ tự: A→B, D→C. Nhờ đó bạn không kéo B vào sprint mà quên A.

Prompt mẫu

Vai trò: trợ lý phát hiện phụ thuộc & rủi ro trong backlog cho PO.

Dưới đây là danh sách story (ID + mô tả + AC). Hãy:
1) Liệt kê các cặp PHỤ THUỘC: "X cần Y hoàn thành trước" | lý do.
2) Đề xuất THỨ TỰ triển khai hợp lý (chuỗi/nhóm).
3) Nêu RỦI RO tiềm ẩn (kỹ thuật, dữ liệu, bên thứ ba, pháp lý) nếu thấy.
4) Với mỗi phụ thuộc, ghi mức độ TIN CẬY (Chắc/Có thể/Phỏng đoán).

QUY TẮC: chỉ suy luận từ nội dung đã cho. Nếu là phỏng đoán, nói rõ
là phỏng đoán cần PO kiểm chứng, KHÔNG khẳng định như sự thật.

Story:
[dán vào]

Các bước làm

• Gom cụm story dự kiến vào 1–2 sprint tới (phụ thuộc chỉ quan trọng khi sắp làm).
• Chạy prompt, thu về danh sách phụ thuộc + thứ tự + rủi ro.
• Xác minh từng phụ thuộc "Phỏng đoán" với tech lead — đừng tin ngay.
• Ghi phụ thuộc đã xác nhận vào từng story (trường "Phụ thuộc: cần US-xxx").
• Sắp thứ tự sprint theo chuỗi phụ thuộc; tách story bị chặn nếu chưa gỡ được.
• Đưa danh sách rủi ro vào phần "cần thảo luận" của buổi refinement.

Template: bản đồ phụ thuộc

| Story | Cần trước | Tin cậy | Đã xác minh? | Rủi ro liên quan |
|-------|-----------|---------|--------------|------------------|
| US-B  | US-A      | Chắc    | ✅ tech lead | API chưa có version |
| US-C  | US-D      | Có thể  | ⬜           | phụ thuộc bên thứ ba |

Sai lầm thường gặp

• Tin phụ thuộc AI "phát hiện" mà không kiểm chứng. AI có thể ảo giác một phụ thuộc không tồn tại (dựa trên phỏng đoán ngữ nghĩa), khiến bạn hoãn story oan. Luôn xác minh với người làm kỹ thuật.
• Bỏ sót phụ thuộc AI không thấy. AI chỉ biết những gì trong mô tả. Phụ thuộc nằm trong đầu dev hoặc hệ thống cũ thì nó không thấy — đừng coi danh sách là đầy đủ.
• Quá phụ thuộc AI để sắp thứ tự sprint. Thứ tự còn phụ thuộc giá trị kinh doanh, năng lực đội — những thứ AI không biết. Dùng gợi ý làm điểm khởi đầu.
• Rò rỉ kiến trúc nội bộ. Mô tả phụ thuộc hay lộ sơ đồ hệ thống. Cẩn trọng với công cụ ngoài.

Chốt bài

AI phơi bày phụ thuộc và rủi ro sớm — nhưng mỗi phụ thuộc phải được người kỹ thuật xác minh trước khi tin. Bài 6: dựng agent tự động hóa cả quy trình grooming.

<!--les-append-->

Hai loại phụ thuộc, và AI chỉ thấy một loại

Hệ quả thực dụng: AI là bước đầu tiên, không phải bước duy nhất. Nó lọc ra phụ thuộc hiển hiện trong văn bản trong hai phút — việc trước đây mất nửa buổi. Ba loại còn lại vẫn cần con người, và cách lấy ra chúng là hỏi đúng câu trong buổi refinement.

Ba câu hỏi lấy ra loại 2 và 3:

• "Hai story này có sửa cùng một bảng hoặc cùng một module không?"
• "Có story nào chỉ một người làm được không?"
• "Có story nào cần thứ gì từ bên ngoài đội không?"

Câu 2 là câu quan trọng nhất về mặt rủi ro sprint: một story phụ thuộc vào một người là một story sẽ trượt nếu người đó nghỉ, và đó là rủi ro không có trong bất kỳ mô tả nào.

Cột "đã xác minh" là cột quan trọng nhất trong bảng

Trong mẫu bản đồ phụ thuộc, cột xác minh quyết định bảng này dùng được hay không. Quy tắc:

• Phụ thuộc chưa xác minh không được dùng để sắp thứ tự sprint. Nó chỉ là một câu hỏi cần hỏi.
• Xác minh nghĩa là có tên người xác nhận, không phải "nghe hợp lý".
• Phụ thuộc AI nêu mà tech lead nói không có thì xoá, và ghi lại — vì nó cho biết mô tả story đang gây nhầm lẫn, và đó là thứ nên sửa.

Ý cuối là một lợi ích phụ ít ai để ý: chỗ AI hiểu sai thường là chỗ mô tả story viết chưa rõ. Người thật cũng sẽ hiểu sai ở đúng chỗ đó.

Phụ thuộc là một tín hiệu về cách chia story

Nếu bản đồ phụ thuộc của bạn dày đặc — mỗi story cần hai, ba story khác — thì vấn đề không nằm ở việc quản lý phụ thuộc. Nó nằm ở cách chia story: bạn đang chia theo tầng kỹ thuật, nên không mảnh nào đứng một mình được.

Phép thử: đếm số story trong sprint không phụ thuộc gì. Nếu con số đó dưới một nửa, quay lại chia lại theo hướng giá trị — mỗi mảnh giao được một phần giá trị dùng được.

Đây là cách chữa gốc. Quản lý một bản đồ phụ thuộc phức tạp là chữa triệu chứng, và nó tốn công mỗi sprint thay vì một lần.

Bảo mật: nhắc lại cụ thể

Mô tả phụ thuộc thường lộ sơ đồ hệ thống nội bộ — tên bảng dữ liệu, tên dịch vụ, cấu trúc tích hợp. Trước khi dán vào công cụ ngoài, đổi tên thực thể (bang_khach_hang thành bang_A) hoặc dùng công cụ được công ty duyệt. Mất hai phút và nó loại bỏ một rủi ro không cần thiết. <!--/les-append-->