Viết truyện người dùng là kỹ năng nền tảng đối với bất kỳ kỹ sư phần mềm nào bước vào môi trường Agile. Mặc dù nhiều đội ngũ phụ thuộc vào các nền tảng kỹ thuật số để quản lý công việc, nhưng việc hiểu rõ các cơ chế cốt lõi của một truyện người dùng mà không phụ thuộc vào phần mềm sẽ tạo nên nền tảng vững chắc hơn. Hướng dẫn này tập trung vào quy trình thủ công, sử dụng các công cụ vật lý như giấy dán, bảng trắng và thẻ ghi chú để xây dựng các yêu cầu rõ ràng, có thể hành động. Mục tiêu là sự minh bạch trong tư duy, chứ không phải sự tiện lợi của màn hình.
Khi bạn loại bỏ phần mềm, bạn buộc phải tham gia sâu vào nội dung. Không còn các tính năng tự động điền hay mẫu có sẵn để che giấu. Bạn phải diễn đạt rõ ràng giá trị, người thực hiện và nhu cầu. Sự kỷ luật thủ công này đảm bảo rằng đội ngũ hiểu rõ không gian vấn đề trước khi viết bất kỳ dòng mã nào. Dưới đây, chúng tôi khám phá cấu trúc của một truyện, các tiêu chí chấp nhận và các phương pháp tinh chỉnh ý tưởng mà không cần sự hỗ trợ kỹ thuật số.
📖 Hiểu rõ khái niệm cốt lõi
Một truyện người dùng là mô tả nhẹ nhàng về một tính năng được kể từ góc nhìn của người mong muốn khả năng mới, thường là người dùng hoặc khách hàng của hệ thống. Nó không phải là tài liệu quy định. Nó là một chỗ trống cho một cuộc trò chuyện. Hành động vật lý viết truyện lên thẻ hoặc giấy củng cố ý định này. Truyện được dự định để di chuyển, chỉnh sửa, loại bỏ hoặc kết hợp. Các hệ thống kỹ thuật số thường khiến bạn bị giam giữ trong cấu trúc cứng nhắc quá sớm. Các phương pháp thủ công giúp truyện luôn linh hoạt.
Tại sao phải làm thủ công?
Có nhiều lý do thuyết phục để luyện tập viết truyện bằng thủ công, đặc biệt là đối với các kỹ sư mới:
- Tập trung vào giá trị:Không có các trường để điền, bạn sẽ tập trung vào đề xuất giá trị thực sự.
- Tải nhận thức:Viết tay làm chậm lại quá trình, cho phép bạn suy nghĩ trước khi ghi lại văn bản.
- Hợp tác:Các thẻ vật lý cho phép đội ngũ sắp xếp lại công việc một cách trực tiếp, trực quan hóa luồng và mức độ ưu tiên.
- Tự chủ:Bạn học đến mức thành thạo định dạng, đến nỗi có thể viết các yêu cầu hợp lệ ngay cả khi công cụ không sẵn sàng.
📋 Cấu trúc của một truyện thủ công
Mỗi truyện người dùng tuân theo một cấu trúc cụ thể. Khi viết bằng tay, hãy sử dụng định dạng nhất quán trên các thẻ ghi chú hoặc giấy dán. Sự nhất quán này giúp đội ngũ quét thông tin nhanh chóng trong các buổi lập kế hoạch. Định dạng chuẩn gồm ba phần riêng biệt. Không được bỏ sót bất kỳ phần nào.
1. Nhân vật (Ai)
Xác định vai trò hoặc loại người dùng cụ thể. Tránh các thuật ngữ chung như “người dùng”. Hãy chính xác. Có phải là “Quản trị viên”, “Khách tham quan” hay “Thành viên cao cấp”? Nhân vật sẽ xác định quyền hạn và bối cảnh của tính năng.
2. Hành động (Làm gì)
Mô tả khả năng hoặc hành động mà người dùng muốn thực hiện. Đây là động từ. Nó nên là mục tiêu cấp cao, chứ không phải chi tiết triển khai kỹ thuật. Ví dụ, “tìm kiếm các mục” tốt hơn “nhập truy vấn vào cơ sở dữ liệu SQL”. Hành động này thể hiện ý định của người dùng.
3. Lợi ích (Để)
Đây là phần quan trọng nhất thường bị bỏ qua bởi người mới. Tại sao người dùng lại muốn điều này? Nó mang lại giá trị gì? Nếu bạn không thể trả lời, truyện có thể không mang lại giá trị. Cụm từ “Để” kết nối tính năng với kết quả kinh doanh hoặc người dùng.
Cấu trúc ví dụ
Viết điều này trên một hoặc hai dòng. Giữ cho ngắn gọn.
- Là một [Nhân vật],
- Tôi muốn [Hành động],
- Để [Lợi ích].
📝 Xác định tiêu chí chấp nhận
Một câu chuyện không thể hoàn chỉnh nếu thiếu tiêu chí chấp nhận. Đây là những điều kiện phải được đáp ứng để coi câu chuyện là hoàn thành. Khi viết thủ công, các tiêu chí này nên được liệt kê ngay dưới thẻ câu chuyện hoặc trên một tờ giấy riêng được đính kèm vào nó. Chúng đóng vai trò như các trường hợp kiểm thử cho công việc kỹ thuật.
Các tiêu chí chấp nhận loại bỏ sự mơ hồ. Chúng xác định ranh giới của tính năng. Không có chúng, hai kỹ sư có thể triển khai các giải pháp khác nhau cho cùng một câu chuyện. Viết thủ công buộc bạn phải suy nghĩ kỹ về các trường hợp biên trước khi bắt đầu phát triển.
Định dạng Given/When/Then
Để có các tiêu chí chính xác, hãy sử dụng cấu trúc Given/When/Then. Đây là bản dịch thủ công của Phát triển Hướng hành vi (BDD). Nó giúp cấu trúc logic một cách rõ ràng.
- Cho rằng:Bối cảnh hoặc trạng thái ban đầu.
- Khi:Sự kiện hoặc hành động được thực hiện.
- Thì:Kết quả mong đợi.
Ví dụ về tiêu chí
- Cho rằng người dùng đã đăng nhập,
- Khi họ nhấp vào nút đăng xuất,
- Thì họ sẽ được chuyển hướng đến trang chủ.
- Khi họ nhấp vào nút đăng xuất,
Bảng các loại tiêu chí
Có nhiều loại tiêu chí khác nhau. Bảng biểu giúp phân loại chúng trong quá trình viết thủ công.
| Loại | Mô tả | Ví dụ |
|---|---|---|
| Chức năng | Hành vi cụ thể của hệ thống | “Hệ thống gửi email sau khi gửi biểu mẫu” |
| Phi chức năng | Hạn chế về hiệu suất hoặc bảo mật | “Trang tải trong dưới 2 giây” |
| Logic kinh doanh | Các quy tắc điều chỉnh dữ liệu | “Chiết khấu chỉ áp dụng cho các đơn hàng trên 50 đô la” |
| Tính khả dụng | Yêu cầu về tính dễ sử dụng | “Nút phải hiển thị rõ ràng mà không cần cuộn trang” |
🌐 Xác minh bằng mô hình INVEST
Một khi bạn đã viết một câu chuyện bằng tay, bạn phải xác minh chất lượng của nó. Mô hình INVEST là khung chuẩn cho việc này. Bạn có thể sử dụng danh sách kiểm tra trên một tờ giấy riêng để đánh giá từng câu chuyện trước khi thêm vào danh sách công việc chờ xử lý. Điều này đảm bảo công việc có thể quản lý được và mang lại giá trị.
Độc lập
Câu chuyện phải tự hoàn chỉnh. Nó không nên phụ thuộc vào việc một câu chuyện khác phải hoàn thành trước để mang lại giá trị. Mặc dù tồn tại các phụ thuộc kỹ thuật, giá trị của câu chuyện phải độc lập. Nếu bạn phải chờ câu chuyện A để xây dựng câu chuyện B, hãy cân nhắc việc tách câu chuyện B ra.
Có thể thương lượng
Câu chuyện là lời hứa về việc thảo luận, chứ không phải một hợp đồng. Nó cho phép cuộc trao đổi giữa kỹ sư và bên liên quan. Nếu văn bản quá chi tiết, nó sẽ trở thành một tài liệu quy định, chứ không còn là một câu chuyện. Hãy để khoảng trống cho việc khám phá kỹ thuật.
Có giá trị
Mỗi câu chuyện phải mang lại giá trị cho người dùng hoặc doanh nghiệp. Nếu một câu chuyện không đáp ứng yêu cầu ‘Vì vậy’ một cách hiệu quả, nó nên bị loại bỏ hoặc sửa lại. Giá trị là yếu tố chính thúc đẩy danh sách công việc chờ xử lý.
Có thể ước lượng
Đội ngũ phải có thể ước lượng nỗ lực cần thiết. Nếu một câu chuyện quá mơ hồ, nó không thể ước lượng được. Nếu quá phức tạp, hãy chia nhỏ nó. Việc viết tay giúp phát hiện sự mơ hồ vì bạn phải viết ra chi tiết cụ thể.
Nhỏ gọn
Một câu chuyện nên đủ nhỏ để hoàn thành trong một lần lặp lại hoặc một vòng sprint. Những câu chuyện lớn là rủi ro. Chúng thường dẫn đến công việc chưa hoàn thành. Nếu một câu chuyện cảm giác như một dự án, hãy chia nó thành các câu chuyện nhỏ hơn, theo trình tự.
Có thể kiểm thử
Bạn phải có thể xác minh được rằng câu chuyện đã hoàn thành. Nếu không có tiêu chí chấp nhận, câu chuyện sẽ không thể kiểm thử. Việc viết tay buộc bạn phải xác định rõ ràng hình ảnh của ‘đã xong’.
Danh sách kiểm tra INVEST
Sử dụng bảng này để xem xét lại các câu chuyện của bạn trong quá trình lập kế hoạch.
| Chữ cái | Câu hỏi cần đặt ra | Trạng thái |
|---|---|---|
| I | Câu chuyện này có thể phát triển mà không cần các câu chuyện khác không? | [ ] |
| N | Phạm vi có mở ra để thảo luận không? | [ ] |
| V | Nó có mang lại giá trị rõ ràng không? | [ ] |
| E | Chúng ta có thể phỏng đoán nỗ lực không? | [ ] |
| S | Nó có thể vừa trong một sprint không? | [ ] |
| T | Có điều kiện rõ ràng để vượt qua/thất bại không? | [ ] |
🔍 Quy trình tinh chỉnh
Tinh chỉnh, còn được gọi là dọn dẹp, là hoạt động chuẩn bị các câu chuyện cho phát triển trong tương lai. Bạn không cần phần mềm để tinh chỉnh. Thật ra, hành động vật lý di chuyển các thẻ xung quanh bàn có thể cải thiện sự hiểu biết về luồng công việc. Một buổi tinh chỉnh bao gồm việc xem xét các câu chuyện, làm rõ chi tiết và chia nhỏ các mục lớn.
Bước 1: Xem xét
Thu thập đội nhóm quanh một chiếc bàn lớn. Xếp các thẻ ra. Đọc từng câu chuyện to lên. Hành động đơn giản này giúp phát hiện những lỗi không thể nhìn thấy khi đọc thầm. Lắng nghe sự mơ hồ trong phần “Để Làm Gì”.
Bước 2: Chia tách
Nếu một thẻ cảm giác quá nặng, hãy cắt nó. Viết câu chuyện mới nhỏ hơn lên một thẻ mới. Đặt thẻ mới phía trên thẻ gốc hoặc bên cạnh. Đảm bảo thẻ gốc được cập nhật để phản ánh việc chia tách. Sự tách biệt trực quan này giúp quản lý phạm vi.
Bước 3: Những câu hỏi
Trong quá trình xem xét, đội nhóm đặt ra các câu hỏi. Viết những câu hỏi này ra một tờ giấy riêng. Không trả lời ngay lập tức. Những câu hỏi cho thấy khoảng trống kiến thức. Chúng trở thành các nhiệm vụ hành động cho buổi họp tiếp theo. Điều này tách biệt việc lập kế hoạch khỏi việc trả lời.
Bước 4: Sắp xếp thứ tự
Sắp xếp các thẻ theo thứ tự phụ thuộc hoặc giá trị. Dùng dây hoặc băng dính trên bàn để thể hiện các mối liên hệ. Nếu Thẻ A phải xảy ra trước Thẻ B, hãy vẽ một đường nối giữa chúng. Luồng trực quan này giúp phát hiện các điểm nghẽn trước khi phát triển bắt đầu.
📈 Các kỹ thuật ưu tiên
Một khi bạn đã có danh sách các câu chuyện, bạn phải quyết định điều gì cần xây dựng trước. Các phương pháp ưu tiên thủ công thường hiệu quả hơn so với sắp xếp kỹ thuật số vì chúng liên quan đến tương tác vật lý với công việc.
Phương pháp MoSCoW
Mã hóa màu cho các thẻ của bạn hoặc dùng các hình dạng khác nhau để biểu thị mức độ ưu tiên. Đây là một kỹ thuật thủ công kinh điển.
- M – Phải Có:Quan trọng đối với bản phát hành. Không có ngoại lệ.
- S – Nên Có:Quan trọng nhưng không thiết yếu. Có thể hoãn lại nếu cần.
- C – Có Thể Có:Thích hợp nhưng không cần thiết.
- W – Không sẽ có:Đã đồng ý loại bỏ khỏi phạm vi hiện tại.
First (WSJF) – Công việc ngắn nhất có trọng số
Đối với cách tiếp cận mang tính toán học hơn, hãy gán các con số cho giá trị và thời gian. Viết các con số lên thẻ. Tính tỷ lệ một cách thủ công. Điều này buộc đội phải định lượng giá trị thay vì dựa vào cảm tính. Đây là một bài tập có giá trị đối với các kỹ sư mới để hiểu được các thỏa thuận kinh doanh.
⚠️ Những sai lầm phổ biến cần tránh
Ngay cả với cách tiếp cận thủ công, sai lầm vẫn xảy ra. Các kỹ sư mới thường rơi vào những cái bẫy cụ thể khi viết các câu chuyện mà không có sự hướng dẫn từ kiểm thử phần mềm.
1. Ngôn ngữ kỹ thuật
Đừng viết các câu chuyện từ góc nhìn của hệ thống. Tránh dùng các từ như “cơ sở dữ liệu”, “API” hay “backend”. Hãy viết từ góc nhìn của người dùng. Hệ thống là vô hình đối với người dùng. Nếu bạn viết “Hệ thống cập nhật bộ nhớ đệm”, người dùng sẽ không quan tâm. Họ chỉ quan tâm đến tốc độ trang.
2. Thiếu tiêu chí chấp nhận
Dễ dàng viết phần “Làm một…” nhưng quên mất phần “Để…”, hoặc các tiêu chí. Một câu chuyện không có tiêu chí là một mục trong danh sách việc cần làm, chứ không phải là một câu chuyện người dùng. Điều này tạo ra sự mơ hồ. Luôn yêu cầu có tiêu chí trước khi coi thẻ là hoàn thành.
3. Quá nhiều chi tiết
Viết một câu chuyện không phải là viết tài liệu mô tả. Nếu bạn viết năm đoạn văn trên một thẻ duy nhất, có lẽ bạn đã mô tả quá chi tiết. Giữ thẻ nhỏ gọn. Các chi tiết thuộc về cuộc trò chuyện trong quá trình tinh chỉnh, chứ không nằm trên thẻ.
4. Bỏ qua các trường hợp biên
Viết thủ công thường tập trung vào con đường thuận lợi. Bạn phải ghi rõ ràng điều gì xảy ra khi mọi thứ không như mong đợi. Thêm tiêu chí cho các trạng thái lỗi. “Cho rằng mạng bị ngắt, khi người dùng gửi, thì họ sẽ thấy thông báo thử lại.”
5. Thiếu sự hợp tác
Viết một câu chuyện một mình là phí phạm thời gian. Các câu chuyện là điểm khởi đầu cho cuộc trò chuyện. Nếu bạn viết một câu chuyện mà không thảo luận với đồng nghiệp, nó sẽ dễ bị hiểu sai. Luôn kiểm tra thủ công cùng một đồng nghiệp.
👩💻 Chuyển sang số hóa sau này
Mặc dù hướng dẫn này tập trung vào phương pháp thủ công, các đội cuối cùng sẽ chuyển sang hệ thống số hóa để theo dõi và báo cáo. Những kỹ năng bạn học được ở đây sẽ được chuyển trực tiếp. Khi bạn sử dụng nền tảng số hóa, bạn sẽ viết câu chuyện tốt hơn vì hiểu rõ cấu trúc cốt lõi. Bạn sẽ không phụ thuộc vào phần mềm để định nghĩa giá trị cho mình.
Sự chuyển đổi sẽ trơn tru nếu nền tảng vững chắc. Công cụ số hóa trở thành nơi lưu trữ cho công việc thủ công mà bạn đã suy nghĩ kỹ. Bạn chỉ cần sao chép nội dung thẻ vào hệ thống. Logic vẫn giữ nguyên.
📝 Bài tập thực hành cho kỹ sư mới
Để củng cố các khái niệm này, hãy thử bài tập sau. Bài tập này không cần phần mềm, chỉ cần giấy và bút.
- Bước 1:Chọn một tính năng bạn sử dụng mỗi ngày (ví dụ: thanh tìm kiếm trên một trang web).
- Bước 2:Viết câu chuyện người dùng trên một thẻ chỉ mục bằng định dạng chuẩn.
- Bước 3:Viết ba tiêu chí chấp nhận bằng cấu trúc Given/When/Then.
- Bước 4:Áp dụng bảng kiểm mô hình INVEST cho thẻ.
- Bước 5: Viết ra hai câu hỏi bạn có về câu chuyện mà một nhà phát triển sẽ đặt ra.
- Bước 6:Xem lại thẻ cùng một đồng nghiệp. Yêu cầu họ nhận xét phần “Để Mà”.
💬 Những suy nghĩ cuối cùng về kỷ luật thủ công
Thành thạo nghệ thuật kể chuyện người dùng là về sự chính xác và đồng cảm. Điều đó đòi hỏi bạn phải đặt mình vào vị trí của người dùng. Điều đó đòi hỏi bạn phải rõ ràng và súc tích. Quy trình thủ công loại bỏ tiếng ồn từ giao diện phần mềm và chỉ còn lại thông điệp. Kỷ luật này khiến bạn trở thành một kỹ sư tốt hơn. Nó khiến bạn trở thành một người giao tiếp tốt hơn.
Khi bạn loại bỏ các công cụ, bạn chỉ còn lại logic. Chính logic này là động lực thúc đẩy phần mềm. Bằng cách luyện tập thủ công, bạn đảm bảo rằng logic của mình là hợp lý trước khi yêu cầu máy tính thực thi. Cách tiếp cận này giảm thiểu công việc phải làm lại và nâng cao chất lượng. Đó là sự tự tin lặng lẽ về khả năng định nghĩa giá trị của bạn.
Hãy nhớ, mục tiêu không phải là lấp đầy danh sách công việc kỹ thuật số. Mục tiêu là giải quyết một vấn đề cho con người. Giữ con người trong vòng lặp. Giữ câu chuyện đơn giản. Giữ tiêu chí rõ ràng. Những nguyên tắc này sẽ phục vụ bạn tốt, bất kể bạn cuối cùng sử dụng công cụ nào.
📊 Tóm tắt những điểm chính cần ghi nhớ
- Cấu trúc:Luôn sử dụng Cái tôi là / Tôi muốn / Để mà.
- Tiêu chí:Xác định Given/When/Then để rõ ràng.
- Xác minh:Kiểm tra theo INVEST trước khi hoàn tất.
- Hợp tác:Xem xét thẻ một cách vật lý cùng đội nhóm.
- Trọng tâm:Ưu tiên giá trị người dùng hơn là triển khai kỹ thuật.