Ngừng lãng phí thời gian vào những câu chuyện người dùng kém chất lượng: Hướng dẫn thực hành cho người mới bắt đầu

Làm việc trong môi trường linh hoạt thường cảm giác như một cuộc cân bằng. Bạn muốn di chuyển nhanh, nhưng đồng thời cũng cần xây dựng những thứ đúng đắn. Một trong những điểm nghẽn lớn nhất trong quá trình này là chất lượng của các câu chuyện người dùng. Khi các câu chuyện mơ hồ, các nhà phát triển tốn thời gian hỏi câu hỏi. Các tester gặp khó khăn khi xác minh công việc. Các bên liên quan cảm thấy sản phẩm không đáp ứng nhu cầu của họ. Kết quả là phải làm lại, chậm trễ và thất vọng.

Hướng dẫn này cung cấp một cách tiếp cận thực tế để viết các câu chuyện người dùng rõ ràng và có thể hành động. Chúng ta sẽ đề cập đến các thành phần thiết yếu, nguyên tắc INVEST và cách xác định tiêu chí chấp nhận mà không cần dùng công cụ cụ thể. Đến cuối hướng dẫn, bạn sẽ hiểu cách cấu trúc danh sách công việc của mình sao cho mỗi mục đều sẵn sàng cho phát triển.

Chính xác thì câu chuyện người dùng là gì? 🤔

Một câu chuyện người dùng là mô tả ngắn gọn, đơn giản 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. Nó không phải là một bản mô tả kỹ thuật. Đó là một công cụ giao tiếp. Nó tập trung vào giá trị được mang lại thay vì chi tiết triển khai.

Hãy nghĩ về một câu chuyện người dùng như một chỗ trống cho một cuộc trò chuyện. Văn bản viết ra không phải là hợp đồng. Cuộc trò chuyện giữa các thành viên trong nhóm mới là hợp đồng. Sự phân biệt này rất quan trọng. Nếu bạn coi văn bản câu chuyện là nguồn chân lý duy nhất, bạn sẽ giới hạn khả năng thích ứng và làm rõ của nhóm.

• Ai: Nhân vật hoặc vai trò của người dùng.
• Làm gì: Hành động họ muốn thực hiện.
• Tại sao: Giá trị hoặc lợi ích họ nhận được.

Cấu trúc này đảm bảo rằng mỗi mục trong danh sách công việc của bạn đều có mục đích con người. Nó ngăn nhóm xây dựng các tính năng mà không ai thực sự cần.

Định dạng chuẩn 📝

Hầu hết các nhóm sử dụng mẫu để duy trì tính nhất quán. Dù tính linh hoạt là quan trọng, nhưng định dạng chuẩn giúp mọi người quét danh sách công việc nhanh chóng. Định dạng phổ biến nhất bao gồm các thành phần sau:

• Vai trò: Người dùng là ai?
• Hành động: Họ muốn làm gì?
• Lợi ích: Tại sao họ muốn làm điều đó?

Ví dụ:

Là một khách hàng đã đăng ký, tôi muốn thiết lập lại mật khẩu của tôi để tôi có thể lấy lại quyền truy cập vào tài khoản của mình nếu tôi quên thông tin đăng nhập của mình.

Nhận thấy sự rõ ràng ở đây. Nó xác định người dùng, hành động cụ thể và lý do. Nó ngắn gọn đủ để vừa trên một thẻ hoặc thẻ kỹ thuật số, nhưng đủ chi tiết để hiểu được mục đích.

Tại sao những câu chuyện xấu lại tốn của bạn thời gian ⏳

Nhiều đội ngũ đánh giá thấp chi phí của các yêu cầu kém chất lượng. Khi một câu chuyện không rõ ràng, quá trình phát triển sẽ bị đình trệ. Nhà phát triển phải đoán xem điều gì là cần thiết. Nếu đoán sai, mã nguồn phải được viết lại. Điều này được gọi là công việc lại, và nó rất tốn kém.

Dưới đây là những dấu hiệu phổ biến cho thấy các câu chuyện của bạn đang gây lãng phí:

• Số lượng câu hỏi cao trong quá trình tinh chỉnh:Nếu đội ngũ đặt câu hỏi trong suốt sprint, nghĩa là câu chuyện chưa sẵn sàng.
• Mở rộng phạm vi:Câu chuyện phát triển lớn hơn trong quá trình phát triển do ranh giới không rõ ràng.
• Lỗi thường xuyên:Sự mơ hồ thường dẫn đến các lỗi logic mà kiểm thử nên đã phát hiện sớm hơn.
• Sự thất vọng của đội ngũ:Các nhà phát triển cảm thấy họ đang xây dựng những thứ không phù hợp với mong đợi.

Đầu tư thời gian viết các câu chuyện tốt ngay từ đầu sẽ tiết kiệm được thời gian đáng kể sau này. Tốt hơn hết là dành thêm một giờ để làm rõ câu chuyện ngay bây giờ thay vì phải mất ba ngày để sửa chữa sau này.

Nguyên tắc INVEST được giải thích 📊

Để đảm bảo các câu chuyện của bạn hiệu quả, bạn có thể áp dụng mô hình INVEST. Từ viết tắt này đại diện cho Độc lập, Thương lượng được, Có giá trị, Có thể ước lượng, Nhỏ và Kiểm thử được. Hãy cùng phân tích ý nghĩa thực tế của từng thuật ngữ.

1. Độc lập

Một câu chuyện nên có thể được phát triển mà không cần phụ thuộc vào câu chuyện khác phải hoàn thành trước. Các phụ thuộc sẽ tạo ra điểm nghẽn. Nếu Câu chuyện A không thể xây dựng cho đến khi Câu chuyện B hoàn thành, bạn sẽ mất đi sự linh hoạt trong lập kế hoạch. Hãy cố gắng chia nhỏ các câu chuyện để chúng có thể tồn tại độc lập.

2. Thương lượng được

Mô tả câu chuyện là lời nhắc về một cuộc trò chuyện, chứ không phải một hợp đồng cố định. Cần có không gian để thảo luận chi tiết với người sở hữu sản phẩm. Nếu câu chuyện quá chi tiết, sẽ loại bỏ cơ hội để đội ngũ đề xuất các giải pháp kỹ thuật tốt hơn. Giữ các yêu cầu cấp cao rõ ràng, nhưng để mở các chi tiết triển khai.

3. 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 tính năng không hỗ trợ người dùng hoặc doanh nghiệp, thì nó không nên nằm trong danh sách chờ. Hãy tự hỏi bản thân: “Liệu điều này có giải quyết được một vấn đề không?” Nếu câu trả lời là không, hãy cân nhắc loại bỏ nó.

4. Có thể ước lượng

Đội ngũ phải có khả năng ước lượng nỗ lực cần thiết để hoàn thành câu chuyện. Nếu phạm vi quá mơ hồ, đội ngũ không thể đưa ra ước lượng đáng tin cậy. Nếu đội ngũ không thể ước lượng, họ sẽ không thể lập kế hoạch sprint. Đảm bảo bạn có đủ thông tin để đưa ra đánh giá về mức độ phức tạp.

5. Nhỏ

Một câu chuyện nên đủ nhỏ để có thể hoàn thành trong một lần lặp lại hoặc một sprint. Các câu chuyện lớn mang rủi ro vì chúng khó ước lượng và khó theo dõi. Hãy chia nhỏ chúng thành các phần nhỏ hơn. Nếu một câu chuyện mất hơn vài ngày, thì có khả năng nó quá lớn.

6. Kiểm thử được

Bạn phải có thể xác minh được rằng câu chuyện đã hoàn thành. Nếu bạn không thể viết một trường hợp kiểm thử cho nó, thì đó không phải là một câu chuyện hoàn chỉnh. Điều này liên quan trực tiếp đến các tiêu chí chấp nhận, sẽ được thảo luận tiếp theo.

Xác định các tiêu chí chấp nhận một cách rõ ràng ✅

Các tiêu chí chấp nhận là những điều kiện mà sản phẩm phần mềm phải đáp ứng để được người dùng, khách hàng hoặc bên liên quan khác chấp nhận. Chúng xác định ranh giới của câu chuyện. Không có chúng, “hoàn thành” sẽ có ý nghĩa khác nhau đối với mỗi người.

Các tiêu chí chấp nhận tốt nên có:

• Cụ thể: Tránh dùng những từ mơ hồ như “nhanh” hay “dễ sử dụng”. Hãy dùng con số hoặc các trạng thái cụ thể.
• Có thể kiểm thử:Bạn nên có thể viết một bài kiểm thử mà nó sẽ vượt qua hoặc thất bại.
• Rõ ràng:Phải chỉ có một cách hiểu duy nhất.

Một định dạng phổ biến để viết tiêu chí làGiven-When-Then mẫu. Cấu trúc này giúp mọi người hiểu rõ bối cảnh, hành động và kết quả mong đợi.

Ví dụ sử dụng Given-When-Then

1. Cho biết:Người dùng đang ở trang đăng nhập.
2. Khi:Người dùng nhập địa chỉ email và mật khẩu hợp lệ.
3. Thì:Hệ thống chuyển hướng họ đến bảng điều khiển.

Định dạng này loại bỏ sự mơ hồ. Nó nói rõ cho người kiểm thử biết chính xác phải nhập gì và kết quả mong đợi là gì. Nó cũng giúp nhà phát triển hiểu rõ luồng logic.

Những sai lầm phổ biến và cách khắc phục 🛠️

Ngay cả những người viết có kinh nghiệm cũng mắc sai lầm. Dưới đây là bảng tóm tắt những lỗi phổ biến và cách sửa chúng.

Sai lầm	Ví dụ	Sửa chữa
Quá kỹ thuật	“Thêm một cột mới vào cơ sở dữ liệu.”	“Cho phép người dùng lưu một ghi chú hồ sơ tùy chỉnh.”
Quá mơ hồ	“Làm cho trang web nhanh hơn.”	“Đảm bảo trang chủ tải trong dưới 2 giây.”
Nhiều tính năng	“Cập nhật hồ sơ và thay đổi mật khẩu.”	Chia thành hai câu chuyện riêng biệt.
Giá trị bị thiếu	“Thêm một nút bấm.”	“Thêm một nút bấm để người dùng có thể xuất dữ liệu.”
Không có tiêu chí chấp nhận	“(Trống)”	Xác định các điều kiện cụ thể cho sự thành công.

Xem xét lại danh sách công việc của bạn thường xuyên. Nếu bạn thấy các câu chuyện phù hợp với các danh mục này, hãy tinh chỉnh chúng trước khi vòng lập bắt đầu.

Hợp tác là chìa khóa 🤝

Viết một câu chuyện người dùng không phải là nhiệm vụ đơn độc. Nó đòi hỏi sự hợp tác giữa người sở hữu sản phẩm, các nhà phát triển và người kiểm thử. Điều này thường được gọi là thực hành “Ba người bạn”, mặc dù tên gọi có thể thay đổi.

Trong buổi họp tinh chỉnh:

• Người sở hữu sản phẩm:Giải thích giá trị và mục tiêu kinh doanh.
• Nhà phát triển:Đặt các câu hỏi kỹ thuật về tính khả thi và các giới hạn.
• Người kiểm thử:Xác định các trường hợp biên và rủi ro tiềm tàng.

Cuộc trò chuyện này đảm bảo rằng mọi người đều đồng ý về hình ảnh của “đã hoàn thành”. Nó ngăn cản nhà phát triển xây dựng thứ mà người kiểm thử cho là sai. Nó cũng giúp người sở hữu sản phẩm nhận ra nếu một câu chuyện quá phức tạp.

Mẹo cho hợp tác hiệu quả

• Mời mọi người sớm:Đừng chờ đến khi vòng lập bắt đầu mới thảo luận về câu chuyện.
• Sử dụng các công cụ trực quan:Vẽ sơ đồ hoặc bản phác thảo để làm rõ các luồng phức tạp.
• Lắng nghe chủ động:Nếu một nhà phát triển nói nó quá khó, hãy hỏi lý do. Có thể có một giải pháp đơn giản hơn.
• Ghi chép kết quả:Đảm bảo các tiêu chí chấp nhận được cập nhật dựa trên cuộc thảo luận.

Xem xét lại danh sách công việc của bạn 🔍

Một khi bạn đã viết các câu chuyện, bạn cần duy trì chúng. Danh sách công việc là một tài liệu sống động. Nó thay đổi khi bạn hiểu thêm về sản phẩm và người dùng.

Dưới đây là danh sách kiểm tra để xem xét các mục trong danh sách công việc của bạn:

• Giá trị vẫn còn phù hợp chứ?Ưu tiên thay đổi. Một câu chuyện được viết cách đây vài tháng có thể không còn quan trọng nữa.
• Câu chuyện vẫn nhỏ chứ?Khi bạn học thêm nhiều, bạn có thể nhận ra rằng nó cần được chia nhỏ hơn nữa.
• Các tiêu chí chấp nhận có còn cập nhật không?Yêu cầu có thay đổi trong suốt sprint không?
• Định nghĩa hoàn thành có rõ ràng không?Liệu đội có đồng thuận về thời điểm một câu chuyện được coi là hoàn thành không?

Việc đánh giá định kỳ ngăn chặn danh sách chờ trở thành nơi chôn vùi những ý tưởng cũ. Điều này giúp đội tập trung vào công việc mang lại giá trị cao.

Nâng cao: Xử lý các trường hợp biên 🧩

Một sai sót phổ biến là bỏ qua những gì xảy ra khi mọi thứ không như mong đợi. Một câu chuyện người dùng tốt bao quát đường đi thuận lợi, nhưng cũng phải giải quyết các trường hợp ngoại lệ.

Hãy xem xét lại một câu chuyện đăng nhập. Đường đi thuận lợi là nhập mật khẩu đúng. Nhưng nếu:

• Mật khẩu sai?
• Tài khoản bị khóa?
• Kết nối internet thất bại?
• Máy chủ bị sập?

Các trường hợp biên này nên được nêu rõ trong tiêu chí chấp nhận. Điều này đảm bảo hệ thống vững chắc. Nó ngăn đội xây dựng một tính năng chỉ hoạt động trong điều kiện lý tưởng.

Đo lường sự cải thiện của bạn 📈

Làm sao bạn biết viết của bạn đang cải thiện? Bạn có thể theo dõi một vài chỉ số theo thời gian.

• Tốc độ sprint:Nếu tốc độ của bạn trở nên ổn định hơn, câu chuyện của bạn có khả năng được định nghĩa rõ ràng hơn.
• Tỷ lệ chuyển sang sprint tiếp theo:Nếu ít câu chuyện được chuyển sang sprint tiếp theo, bạn đang ước lượng tốt hơn.
• Số lượng lỗi:Nếu ít lỗi hơn được phát hiện sau khi phát hành, tiêu chí chấp nhận của bạn có khả năng rõ ràng hơn.
• Tâm trạng đội nhóm:Hỏi đội nhóm họ cảm thấy thế nào về danh sách chờ. Ít nhầm lẫn hơn nghĩa là câu chuyện tốt hơn.

Những chỉ số này cung cấp phản hồi. Sử dụng chúng để điều chỉnh quy trình của bạn. Nếu bạn thấy số lượng lỗi tăng đột biến, hãy xem lại phong cách viết tiêu chí chấp nhận của bạn. Nếu tốc độ giảm, hãy xem lại kích thước câu chuyện.

Kết luận

Viết các câu chuyện người dùng tốt là một kỹ năng được cải thiện qua thực hành. Nó đòi hỏi sự chú ý đến chi tiết, giao tiếp rõ ràng và tập trung vào giá trị. Bằng cách tuân theo các định dạng và nguyên tắc được nêu ở đây, bạn có thể giảm lãng phí và cải thiện tốc độ giao hàng.

Bắt đầu bằng việc tinh chỉnh danh sách chờ hiện tại của bạn. Áp dụng mô hình INVEST cho các câu chuyện lớn nhất. Khuyến khích sự hợp tác trong các buổi tinh chỉnh. Theo thời gian, bạn sẽ nhận thấy sự thay đổi trong cách đội làm việc. Ma sát sẽ giảm đi, và đầu ra sẽ tăng lên.

Hãy nhớ, mục tiêu không phải là sự hoàn hảo. Mục tiêu là sự rõ ràng. Một câu chuyện rõ ràng là một câu chuyện có thể được xây dựng. Một câu chuyện rõ ràng là một câu chuyện mang lại giá trị. Tập trung vào hai điều đó, hành trình agile của bạn sẽ trở nên trơn tru hơn nhiều.