Vì sao phải tách và tách theo mẫu
Story to là kẻ thù số một của flow. Nhưng tách bừa (cắt theo tầng kỹ thuật: "làm backend" / "làm frontend") tạo ra story không có giá trị độc lập. Cộng đồng Agile đã đúc kết các mẫu tách story (story splitting patterns) giúp mỗi mảnh vẫn valuable và testable. AI cực giỏi áp các mẫu này khi bạn gọi tên chúng.
6 mẫu tách phổ biến (SPIDR mở rộng)
- Theo bước trong quy trình (workflow steps): tách theo các bước người dùng đi qua. VD: đặt lịch → chọn dịch vụ / chọn giờ / xác nhận thanh toán.
- Theo quy tắc nghiệp vụ (business rules): mỗi rule là một lát. VD: đặt lịch thường / đặt lịch có mã giảm giá / đặt lịch nhóm.
- Theo biến thể dữ liệu (data variations): VD: hỗ trợ thẻ nội địa trước, thẻ quốc tế sau.
- Theo giao diện/kênh (interface/platform): web trước, mobile sau; hoặc form đơn giản trước, form nâng cao sau.
- Theo happy path vs. ngoại lệ: làm luồng thành công trước, xử lý lỗi/edge case sau.
- Theo thao tác CRUD: tách Create / Read / Update / Delete thành story riêng khi mỗi cái đủ giá trị.
Prompt tách story theo mẫu
Bạn là Product Owner thành thạo story splitting. Story dưới đây quá lớn.
Hãy tách thành 3-6 story nhỏ, MỖI story vẫn đạt INVEST (đặc biệt Valuable & Small).Với mỗi story con nêu rõ: (a) tên mẫu splitting đã dùng
(workflow steps / business rules / data variations / interface / happy-path-vs-exception / CRUD),
(b) story theo mẫu "Là...tôi muốn...để...", (c) vì sao mảnh này vẫn có giá trị độc lập.
Ưu tiên sắp xếp các story con theo giá trị giảm dần (cái nào ship sớm cho học được nhiều nhất).
Story to: "Là khách hàng, tôi muốn đặt lịch spa với nhiều dịch vụ, chọn nhân viên,
áp mã giảm giá và thanh toán online."
Bối cảnh: MVP, cần ra mắt nhanh để kiểm chứng nhu cầu.
AI sẽ đề xuất: ship trước "đặt 1 dịch vụ + thanh toán đơn giản" (happy path), để lại "mã giảm giá", "chọn nhân viên", "nhiều dịch vụ" thành các lát sau.
Các bước làm
- Xác nhận story thật sự to (dùng chẩn đoán INVEST ở Bài 1).
- Chạy prompt tách, yêu cầu AI gọi tên mẫu cho từng mảnh.
- Kiểm tra mỗi mảnh: có giá trị độc lập không? Có thể ship riêng không?
- Loại bỏ mảnh chia theo tầng kỹ thuật (nếu AI lỡ đề xuất).
- Xếp thứ tự theo giá trị + rủi ro cần học sớm.
Template checklist khi tách
- [ ] Mỗi mảnh dùng đúng 1 mẫu splitting có tên?
- [ ] Mỗi mảnh vẫn Valuable (ship riêng vẫn có ích cho người dùng)?
- [ ] Không có mảnh nào chỉ là "làm backend/frontend"?
- [ ] Mảnh đầu tiên là mảnh học được nhiều nhất / rủi ro cao nhất?
- [ ] Tổng các mảnh vẫn phủ hết nhu cầu gốc, không hụt cũng không phình?
Sai lầm thường gặp
- Để AI tách theo tầng kỹ thuật. "Story API" và "story UI" không có giá trị độc lập — vi phạm Valuable. Luôn ép AI dùng mẫu hướng giá trị.
- Tách quá vụn thành hàng chục story ti hi. Overhead quản lý lớn hơn lợi ích. Mục tiêu là "đủ nhỏ để xong trong sprint", không phải nhỏ nhất có thể.
- AI ảo giác thêm phạm vi mới khi tách (đẻ thêm tính năng không có trong story gốc). Đối chiếu "tổng các mảnh = nhu cầu gốc".
- Phụ thuộc AI để quyết thứ tự ưu tiên. AI không biết rủi ro kinh doanh thật của bạn; nó gợi ý, bạn quyết.