Câu trả lời được chấp nhận
Tách theo tầng (DB / API / UI) tạo ra các mảnh không có giá trị riêng với người dùng, không kiểm thử đầu-cuối được, và phụ thuộc chặt vào nhau — vi phạm chữ I, V và T trong INVEST. Cách tách tốt là tách dọc (vertical slice): mỗi mảnh đi xuyên qua mọi tầng nhưng chỉ cho một phần hành vi nhỏ.
Các kiểu tách thường dùng (ví dụ với story thanh toán ví điện tử — giả định)
| Kiểu tách | Ví dụ |
|---|---|
| Theo bước quy trình | Chọn ví → xác nhận thanh toán → nhận biên lai |
| Theo luồng chính / luồng ngoại lệ | Trước tiên luồng thành công; sau đó xử lý số dư không đủ, hết phiên |
| Theo biến thể dữ liệu / đối tượng | Một ví trước, các ví khác sau |
| Theo quy tắc nghiệp vụ | Đơn thường trước; đơn có mã giảm giá sau |
| Đơn giản trước, hoàn chỉnh sau | Bản đầu không lưu ví mặc định; bản sau có |
| Theo yêu cầu phi chức năng | Chạy đúng trước; tối ưu thời gian phản hồi sau |
| Tách phần nghiên cứu | Một spike có thời hạn để tìm hiểu API của nhà cung cấp ví |
Mẹo
- Tự hỏi: "Phiên bản nhỏ nhất mà người dùng vẫn dùng được là gì?"
- Mỗi mảnh sau khi tách vẫn phải có giá trị và tiêu chí chấp nhận riêng.
- Mảnh đầu tiên thường là "đường ống mỏng" đi hết luồng chính — nó loại bỏ nhiều rủi ro tích hợp nhất.
- Đừng tách quá vụn: nếu mảnh không còn giá trị nào với người dùng, đó là task, không còn là story.
Nguồn: