Giả sử bạn mở một file spec ra, toàn những câu kiểu “Hệ thống cho phép người dùng thêm sản phẩm vào giỏ hàng”, đọc lướt thì tưởng đúng, nhưng hỏi lại một câu thêm vào giỏ để làm gì thì chưa chắc người viết trả lời được. Theo mình user story hay bị viết bừa ở đúng phần “để làm gì”, viết đủ là ai, muốn chức năng gì, còn mục đích thì chỉ là giả định với đoán mò.
user story không phải requirement viết thành câu#
Một user story chuẩn chỉ cần trả lời ba thứ, ai, muốn gì, và để làm gì. Công thức “As a… I want… So that…” nghe sách vở thật, nhưng nó ép bạn nghĩ tới người dùng thật chứ không phải tới “hệ thống”.
User story: viết sai vs viết đúng
| Viết sai | Viết đúng |
|---|---|
| Hệ thống cho phép thêm sản phẩm vào giỏ hàng | As a khách hàng, I want thêm sản phẩm vào giỏ để so sánh giá trước khi mua |
Thấy khác chưa, câu đúng trả lời luôn để làm gì, là so sánh giá, và cái “So that” đó chính là lý do để dev khỏi phải đoán.
acceptance criteria theo Given-When-Then#
User story nói muốn gì, còn acceptance criteria nói thế nào thì gọi là xong, không có nó thì dev làm xong rồi tester cũng chẳng biết test theo cái gì.
Ví dụ cho cái giỏ hàng phía trên:
- Given giỏ hàng đang có 2 sản phẩm
- When khách thêm sản phẩm thứ 3
- Then giỏ hàng hiển thị 3 sản phẩm, tổng tiền cập nhật ngay
Ba dòng thôi mà dev code đúng, tester test đủ, không ai phải chạy sang hỏi lại.
soi story bằng INVEST trước khi quăng cho dev#
Viết xong đừng vội giao, lấy sáu chữ INVEST ra soi một lượt:
- I (Independent): story đứng một mình được không
- N (Negotiable): còn chỗ để bàn, không phải hợp đồng
- V (Valuable): có mang giá trị cho user không
- E (Estimable): dev ước lượng nổi không
- S (Small): đủ nhỏ để làm gọn trong một sprint
- T (Testable): có acceptance criteria để test không
Trượt chữ nào thì quay lại sửa, đừng đợi dev ngồi soi ra rồi mới chạy.
đừng máy móc quá#
Không phải story nào cũng phải viết Given-When-Then dài dòng, bug fix một dòng hay đổi màu cái nút thì viết ngắn gọn là xong, máy móc quá lại thành BA chỉ ngồi viết tài liệu mà quên mất việc chính là hiểu người dùng. Cái khó của user story không nằm ở chỗ viết, mà ở chỗ hỏi đúng người, không hiểu user thì viết bao nhiêu “So that” cũng vẫn là đoán. Nếu bạn mới vào nghề, đọc bài BA mới vào nghề: 5 cú sốc không ai nói trước để biết mình sắp gặp gì, rồi đọc bài khai phá “nhu cầu thật” trước khi cầm bút viết story.
User story là công cụ chứ không phải biểu mẫu hành chính, viết đúng để cả team khỏi đoán, còn mình thì khỏi bị dev réo giữa đêm hỏi cái này là gì vậy BA. Bạn viết user story đầu tiên thế nào, có bị PM trả lại vì “đây là requirement chứ không phải user story” không?
