Vì sao chủ đề quan trọng
Bài 2 cho bạn một story map với những thẻ rất ngắn: "Chọn khung giờ nhận", "In tổng suất theo món lúc 10:00". Thẻ ngắn đủ để xếp map, nhưng chưa đủ để một lập trình viên bắt tay làm. Họ sẽ hỏi: ai chọn khung giờ, chọn để làm gì, khung dài bao nhiêu? Nếu story không trả lời, lập trình viên sẽ tự đoán, và đoán thì thường đúng về kỹ thuật nhưng sai về người dùng.
User story (câu chuyện người dùng) là một mô tả ngắn về một nhu cầu, viết từ góc nhìn người cần nó. Nó không phải đặc tả đầy đủ. Nó là lời hứa sẽ có một cuộc trò chuyện, cộng với một câu đủ rõ để mọi người cùng nhớ cuộc trò chuyện đó về cái gì.
Bài này dạy hai thứ. Thứ nhất là khuôn câu "Là…, tôi muốn…, để…", viết từ persona thật bạn đã dựng ở khóa Persona & User Journey dựa trên bằng chứng. Thứ hai là bộ tiêu chí INVEST để kiểm tra một story có tốt hay không, từng chữ một, mỗi chữ có ví dụ kém và tốt trên Căng tin số. Đầu ra là các thẻ trên lát 1 của story map, viết lại thành story đạt INVEST, cho cả sinh viên lẫn người vận hành.
Bức tranh lớn
Một user story có ba phần:
Là [ai] -> persona hoặc vai trò cụ thể, không phải "người dùng"
tôi muốn [làm gì] -> hành động, không phải màn hình hay nút bấm
để [được gì] -> kết quả, lý do tồn tại của story
Phần "để…" là phần hay bị bỏ nhất, và cũng quan trọng nhất. Nó cho phép đội tìm cách làm rẻ hơn mà vẫn đạt kết quả. Nếu story chỉ nói "tôi muốn thấy danh sách món", lập trình viên chỉ có một cách. Nếu nó nói thêm "để quyết định có ghé quầy bánh mì luôn không", họ có thể đề xuất chỉ hiện món đã hết, gọn hơn nhiều.
Story phải viết từ persona, không từ "người dùng" chung chung. Bốn persona từ khóa 3 là:
- Người chạy lịch: Minh Anh, lớp kết thúc 11:30, lớp sau 12:45.
- Người tới muộn: Quốc Bảo, làm thêm buổi sáng, tới khoảng 12:40.
- Người ăn cẩn trọng: Thảo Vy, dị ứng đậu phộng, nhận suất ăn hỗ trợ.
- Cô Hạnh: bếp trưởng quầy cơm, không cầm điện thoại được giờ cao điểm.
flowchart TD
M[Thẻ trên story map] --> P[Chọn persona hoặc vai trò]
P --> W[Viết Là, tôi muốn, để]
W --> I{Qua đủ sáu chữ INVEST}
I -->|Chưa| F[Sửa chữ bị trượt]
F --> I
I -->|Đạt| C[Thêm tiêu chí nghiệm thu ở bài 5]Ví dụ chi tiết
INVEST là sáu chữ cái, mỗi chữ là một câu hỏi bạn tự đặt cho story. Bảng dưới cho mỗi chữ một story kém và một story tốt, tất cả lấy từ lát 1 của Căng tin số.
| Chữ | Câu hỏi kiểm tra | Story kém | Story tốt |
|---|---|---|---|
| I Độc lập | Làm riêng được không | Làm màn hình thực đơn, sau đó làm chức năng đặt món dựa trên màn hình đó | Là Người chạy lịch, tôi muốn đặt một suất cơm cho trưa mai, để có phần chờ sẵn khi tan lớp 11:30 |
| N Thương lượng được | Còn chỗ để bàn cách làm không | Hiện danh sách món dạng lưới 3 cột, nút đỏ góc phải ghi Hết | Là Người tới muộn, tôi muốn biết món mặn nào ở quầy cơm đã hết, để quyết định ghé quầy bánh mì luôn |
| V Có giá trị | Ai đó được gì thật | Tạo bảng cơ sở dữ liệu đơn đặt trước | Là Anh Tuấn, tôi muốn xuất danh sách đơn đã trả và đã nhận trong ngày, để đối soát không mất cả tiếng |
| E Ước lượng được | Đội đoán được độ lớn không | Hệ thống thanh toán cho căng tin | Là Người chạy lịch, tôi muốn trả trước suất đã đặt bằng chuyển khoản QR, để không phải trả ở quầy |
| S Nhỏ | Xong trong một vòng lặp không | Là sinh viên, tôi muốn đặt món, trả tiền, nhận món và góp ý | Là Cô Hạnh, tôi muốn có bản in tổng suất theo từng món lúc 10:00, để nấu đủ mẻ từ 10 giờ 30 |
| T Kiểm thử được | Biết khi nào là xong không | Là sinh viên, tôi muốn ứng dụng nhanh và dễ dùng | Là nhân viên quầy, tôi muốn tìm đơn bằng mã 4 số, để trao suất trong vài giây |
I, Độc lập. Story kém buộc hai việc vào nhau theo thứ tự. Story tốt tự đứng được: nó cần một thực đơn tồn tại, nhưng không cần một màn hình cụ thể nào xong trước.
N, Thương lượng được. Story kém đã thiết kế sẵn giao diện, không còn gì để bàn. Story tốt nói nhu cầu, lấy thẳng từ câu của Quốc Bảo "Giá mà biết trước là hết thì em ghé quầy bánh mì luôn", và để đội tự tìm cách hiển thị.
V, Có giá trị. "Tạo bảng cơ sở dữ liệu" là một việc kỹ thuật, không ai ngoài đội được gì. Đó là việc con (task) bên trong một story, không phải story. Story tốt giải P7, đúng lời Anh Tuấn "Cuối ngày tôi mất cả tiếng đối soát tiền mặt với chuyển khoản."
E, Ước lượng được. "Hệ thống thanh toán" có thể là một tuần hoặc ba tháng. Story tốt giới hạn: một cách trả, một thời điểm trả. Nó cũng thể hiện cách nhóm chọn ở mâu thuẫn C1: trả trước, như Anh Tuấn yêu cầu.
S, Nhỏ. Story kém là cả xương sống trong một câu. Story tốt là một thẻ trên map. Nó cũng là story cho bếp, không phải cho sinh viên, và nó tôn trọng câu "Giờ cao điểm cô không cầm điện thoại được": bản in, không phải thông báo trên điện thoại.
T, Kiểm thử được. "Nhanh và dễ dùng" không ai kiểm được. Story tốt có một thứ quan sát được: mã 4 số, trao suất. Bài 5 sẽ biến nó thành tiêu chí nghiệm thu, bài 6 sẽ biến "nhanh" thành con số.
Story cho người ăn cẩn trọng. Thảo Vy có hai nỗi đau. Story cho P3: "Là Người ăn cẩn trọng, tôi muốn thấy món nào có đậu phộng trước khi đặt, để không phải hỏi cô bán mỗi lần." Story cho P12: "Là Người ăn cẩn trọng nhận suất hỗ trợ, tôi muốn dùng suất hỗ trợ mà người đứng sau không biết, để không ngại khi nhận món." Câu thứ hai không nhắc tới phiếu giấy hay mã QR. Nó nói kết quả, và để đội tìm cách làm.
Story cho người quản trị. Chị Lan cần thấy ứng dụng có giảm 25 email phàn nàn mỗi tháng hay không: "Là chuyên viên Phòng Quản trị – Đời sống, tôi muốn xem số góp ý theo tuần và theo loại, để biết xếp hàng và hết món có giảm không." Story này không nằm ở lát 1, nhưng viết sớm giúp bạn nhớ lưu loại góp ý ngay từ đầu.
flowchart TD
A[Là sinh viên, tôi muốn đặt món] --> B{Ai cụ thể}
B --> C[Là Người chạy lịch]
C --> D{Để được gì}
D --> E[để có phần chờ sẵn khi tan lớp]
E --> F{Có quá to không}
F -->|To| G[Tách theo bài 4]
F -->|Vừa| H[Story sẵn sàng bàn tiêu chí]Lộ trình từng bước
- Lấy một thẻ trên lát 1 của story map.
- Chọn đúng persona hoặc vai trò cần thẻ đó. Nếu thấy mình viết "người dùng", dừng lại.
- Viết "tôi muốn" bằng hành động của người đó, không bằng tên màn hình.
- Viết "để" bằng kết quả, tốt nhất mượn lời trích dẫn gốc.
- Đi qua sáu chữ INVEST, từng chữ một, ghi chữ nào trượt.
- Sửa chữ trượt. Nếu trượt chữ S, đánh dấu để tách ở bài 4.
- Đọc story cho người trong persona đó nghe. Nếu họ không nhận ra mình, viết lại.
Thói quen & kỷ luật
| Thói quen | Tần suất | Kết quả mong đợi |
|---|---|---|
| Gạch chữ người dùng chung chung | Mỗi story mới | Story luôn gắn với persona có thật |
| Đọc phần để thành tiếng | Mỗi story mới | Phát hiện story không có lý do tồn tại |
| Đếm story cho vai trò vận hành | Mỗi lát phát hành | Bếp, quầy và quản lý không bị bỏ sót |
| Chấm INVEST cùng một người khác | Mỗi buổi chuẩn bị backlog | Bớt điểm mù của người viết |
Cần luyện tập
Drill một: Viết ba story cho Cô Hạnh dựa trên ba câu của cô: nấu theo mẻ từ 10 giờ 30, món nấu quá bốn tiếng phải bỏ, phần đặt quá 30 phút không tới lấy thì bán cho hàng. Kiểm tra từng story theo INVEST và ghi chữ nào khó đạt nhất.
Drill hai: Lấy một story từ đồ án của bạn. Viết lại phần "để". Nếu không viết được, story đó có thể chỉ là một việc kỹ thuật.
Drill ba: Viết story cho Anh Tuấn ứng với câu "Hoàn tiền thì chỉ tôi được duyệt, nhân viên quầy không được." Sau đó viết story cho nhân viên quầy khi một sinh viên đòi hoàn tiền. Hai story đó khác nhau ở chữ nào trong INVEST?
Checklist hành động tuần này
- [ ] Viết lại mọi thẻ lát 1 thành story đầy đủ ba phần
- [ ] Đảm bảo có ít nhất ba story cho người vận hành
- [ ] Chấm INVEST từng story và ghi chữ bị trượt
- [ ] Đánh dấu các story trượt chữ S để tách ở bài 4
- [ ] Đọc hai story cho một sinh viên ngoài nhóm nghe
Chỉ số cho cách làm
Các con số dưới đây đo cách nhóm làm bước này, không đo app có thành công hay không. Câu hỏi app có hiệu quả không, và làm gì tiếp, là việc của khóa Đo lường thành công.
| Loại chỉ số | Ví dụ | Vai trò |
|---|---|---|
| North Star | Tỉ lệ story lát 1 đạt đủ sáu chữ INVEST | Cho biết backlog sẵn sàng để làm |
| Chỉ số chất lượng | Số story có phần để mượn lời trích dẫn gốc | Giữ liên kết với bằng chứng |
| Chỉ số bao phủ | Số story cho vai trò vận hành so với tổng | Tránh ứng dụng chỉ phục vụ một phía |
| Chỉ số cảnh báo | Số câu hỏi làm rõ lập trình viên gửi lại mỗi story | Báo story còn mơ hồ |
Dấu hiệu bạn đã thành thạo
Bạn không còn viết "Là người dùng". Bạn nhận ra "tạo bảng cơ sở dữ liệu" là việc con chỉ trong một giây. Story của bạn cho Cô Hạnh không cần cô cầm điện thoại. Và khi lập trình viên đề xuất cách làm khác mà vẫn đạt phần "để", bạn vui chứ không phòng thủ.
Cạm bẫy thường gặp
| Cạm bẫy | Biểu hiện | Cách tránh |
|---|---|---|
| Story không có người thật | Là người dùng, là hệ thống | Viết từ persona hoặc vai trò có tên |
| Thiếu phần để | Story chỉ có ai và làm gì | Bắt buộc có kết quả, mượn lời trích dẫn |
| Viết giao diện vào story | Nút đỏ, lưới 3 cột | Để thiết kế cho cuộc trò chuyện |
| Việc kỹ thuật đội lốt story | Tạo bảng, viết API | Chuyển thành việc con của story có giá trị |
| Chỉ viết cho sinh viên | Không có story cho bếp và đối soát | Đếm story theo từng làn của story map |
Chốt lại
Một user story tốt có người thật, hành động thật và kết quả thật. INVEST là sáu câu hỏi để kiểm: độc lập, thương lượng được, có giá trị, ước lượng được, nhỏ, kiểm thử được. Trên Căng tin số, story tốt mượn lời Minh Anh, Quốc Bảo, Thảo Vy, và viết cả cho Cô Hạnh, nhân viên quầy, Anh Tuấn, Chị Lan. Đầu ra của bài là story lát 1 đạt INVEST, với những story trượt chữ S được đánh dấu. Bài 4 dạy tám cách tách chúng.