Câu chuyện người dùng Q&A: Câu trả lời cho những câu hỏi phổ biến nhất từ các nhà phát triển mới bắt đầu

Chào mừng bạn đến với thế giới phát triển linh hoạt. Nếu bạn đang đọc điều này, có lẽ bạn thường xuyên gặp từ ngữcâu chuyện người dùngthường xuyên trong các cuộc họp nhóm, phiên lập kế hoạch hoặc bảng dự án của bạn. Mặc dù khái niệm nghe có vẻ đơn giản, nhưng việc triển khai đúng cách có thể gây khó khăn đối với những người mới làm quen với phương pháp này. Hướng dẫn này giải đáp những câu hỏi phổ biến nhất mà các nhà phát triển, chủ sản phẩm và nhà thiết kế thường đặt ra khi bắt đầu hành trình với các yêu cầu lấy người dùng làm trung tâm.

Hiểu rõ cách thu thập yêu cầu một cách hiệu quả sẽ đảm bảo phần mềm được xây dựng thực sự giải quyết được những vấn đề thực tế. Chúng ta sẽ khám phá cách viết các tài liệu mô tả rõ ràng, xác định tiêu chí chấp nhận và hợp tác với các bên liên quan mà không phụ thuộc vào công cụ cụ thể hay thuật ngữ chuyên môn.

🤔 Câu chuyện người dùng thực sự 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 có khả năng mới, thường là người dùng hoặc khách hàng. Nó không phải là một bản mô tả kỹ thuật chi tiết. Thay vào đó, nó là lời hứa về một cuộc trò chuyện. Mục tiêu là hiểu rõtại saotính năng này cần thiết, chứ không chỉ làcái gìcần được xây dựng.

Hãy nghĩ nó như một chỗ trống cho một cuộc thảo luận. Nó chuyển trọng tâm từ chi tiết triển khai kỹ thuật sang giá trị mang lại cho người dùng. Khi một nhà phát triển đọc một câu chuyện người dùng, họ nên hiểu được bối cảnh và kết quả mong muốn trước khi viết bất kỳ dòng mã nào.

📝 Công thức chuẩn

Hầu hết các đội đều tuân theo một mẫu chuẩn để đảm bảo tính nhất quán. Định dạng này giúp mọi người thống nhất về ba thành phần cốt lõi: người thực hiện, hành động và giá trị.

• Ai:Người dùng hoặc vai trò cụ thể.
• Làm gì:Hành động họ muốn thực hiện.
• Tại sao:Lợi ích hoặc giá trị họ nhận được.

Định dạng này thường được viết như sau:

Là một [vai trò], tôi muốn [hành động], để [lợi ích].

Ví dụ:

• Là mộtngười dùng đã đăng ký, tôi muốnthiế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 mật khẩu.
• Là một người mua sắm khách, tôi muốn xem chi tiết sản phẩm, để mà tôi có thể quyết định xem mình có muốn mua mặt hàng này hay không.

❓ Câu hỏi phổ biến từ các nhà phát triển mới bắt đầu

Dưới đây là những câu hỏi thường gặp nhất về câu chuyện người dùng, được trả lời bằng những hiểu biết thực tế và ví dụ minh họa.

Câu hỏi 1: Sự khác biệt giữa một Câu chuyện người dùng và một Nhiệm vụ là gì?

Đây là một sự phân biệt quan trọng. Một câu chuyện người dùng đại diện cho một phần chức năng mang lại giá trị cho người dùng. Một nhiệm vụ đại diện cho công việc kỹ thuật cần thiết để xây dựng phần chức năng đó.

Tính năng	Câu chuyện người dùng	Nhiệm vụ
Trọng tâm	Giá trị cho người dùng	Triển khai kỹ thuật
Ai viết nó?	Người sở hữu sản phẩm / Bên liên quan	Lập trình viên / Kỹ sư
Định dạng	Là một… Tôi muốn… Để mà…	Câu mệnh lệnh (ví dụ: “Tạo lược đồ cơ sở dữ liệu”)
Kích thước	Bước tăng nhỏ, có thể kiểm thử	Bước kỹ thuật cụ thể

Ví dụ:

• Câu chuyện: Là một người dùng, tôi muốn tìm kiếm các mặt hàng theo danh mục.
• Nhiệm vụ: Tạo điểm cuối API cho lọc danh mục.
• Nhiệm vụ:Cập nhật thanh tìm kiếm phía frontend để chấp nhận đầu vào danh mục.
• Nhiệm vụ:Viết các bài kiểm thử đơn vị cho logic tìm kiếm.

Bạn không thể hoàn thành một câu chuyện mà không hoàn thành các nhiệm vụ, nhưng các nhiệm vụ chỉ là phương tiện, chứ không phải mục đích. Luôn ưu tiên câu chuyện.

Câu hỏi 2: Mô hình INVEST là gì?

INVEST là một từ gợi nhớ được sử dụng để đánh giá xem một câu chuyện người dùng có được xây dựng tốt hay không. Nó đại diện cho: Độc lập, Thương lượng được, Có giá trị, Có thể ước lượng, Nhỏ gọn và Kiểm thử được. Một câu chuyện đáp ứng đầy đủ các tiêu chí này sẽ dễ quản lý hơn và ít gây nhầm lẫn hơn.

• Độc lập:Câu chuyện không nên phụ thuộc vào các câu chuyện khác để hoàn thành. Các phụ thuộc sẽ khiến việc lên lịch trở nên khó khăn.
• Thương lượng được:Các chi tiết không cố định. Có khoảng trống để thảo luận giữa đội ngũ và bên liên quan.
• Có giá trị:Nó phải mang lại giá trị cho người dùng hoặc doanh nghiệp. Nếu nó không mang lại điều gì cho họ, thì không nên xây dựng.
• Có thể ước lượng:Đội ngũ phải có đủ thông tin để ước lượng nỗ lực cần thiết.
• Nhỏ gọn:Nó nên vừa vặn trong một lần sprint duy nhất. Những câu chuyện lớn rất khó kiểm thử và quản lý.
• Kiểm thử được:Phải có các tiêu chí rõ ràng để xác minh khi câu chuyện đã hoàn thành.

Câu hỏi 3: Làm thế nào để viết các Tiêu chí chấp nhận tốt?

Các tiêu chí chấp nhận định nghĩa ranh giới của một câu chuyện. Chúng trả lời câu hỏi: ‘Chúng ta biết điều này đã xong khi nào?’ Không có chúng, một nhà phát triển có thể xây dựng thứ gì đó hoạt động về mặt kỹ thuật nhưng lại không đáp ứng nhu cầu của người dùng.

Sử dụng các điểm đánh dấu để liệt kê các điều kiện. Tránh các từ mơ hồ như ‘nhanh’ hay ‘dễ’. Hãy cụ thể.

Ví dụ xấu:

• Đăng nhập phải an toàn.

Ví dụ tốt:

• Hệ thống phải yêu cầu mật khẩu ít nhất 8 ký tự.
• Hệ thống phải khóa tài khoản sau 5 lần thử đăng nhập thất bại.
• Hệ thống phải gửi thông báo email khi đăng nhập thành công từ thiết bị mới.

Câu hỏi 4: Làm thế nào để xử lý các Câu chuyện người dùng quá lớn?

Khi một câu chuyện quá lớn để hoàn thành trong một lần lặp lại, thì nó được gọi là một epic. Bạn phải chia nhỏ nó thành các câu chuyện nhỏ hơn và độc lập. Quá trình này thường được gọi là cắt nhỏ.

Các kỹ thuật cắt nhỏ:

• Theo vai trò người dùng: Các tính năng khác nhau cho các loại người dùng khác nhau (ví dụ: Quản trị viên so với Khách).
• Theo mức độ ưu tiên: Xây dựng chức năng cốt lõi trước, sau đó thêm các tính năng nâng cao.
• Theo quy trình làm việc: Chia quy trình thành các bước (ví dụ: Draft, Xem xét, Xuất bản).
• Theo dữ liệu: Xử lý các loại dữ liệu khác nhau riêng biệt (ví dụ: Ảnh so với Văn bản).

Câu hỏi 5: Story Points là gì và chúng ta đánh giá như thế nào?

Các điểm câu chuyện là một thước đo tương đối về nỗ lực. Chúng không đại diện cho giờ. Chúng đại diện cho độ phức tạp, rủi ro và khối lượng. Các đội thường sử dụng dãy Fibonacci (1, 2, 3, 5, 8, 13) để đánh giá.

Tại sao không dùng giờ?

• Giờ thường không chính xác do các sự gián đoạn và chuyển đổi ngữ cảnh.
• Giờ có thể dẫn đến cảm giác an toàn giả tạo về các mốc thời gian.
• Các điểm câu chuyện tập trung vào kích thước tương đối so với các câu chuyện khác.

Quy trình Poker lập kế hoạch:

1. Trình bày câu chuyện cho đội.
2. Thảo luận về các yêu cầu và tiêu chí chấp nhận.
3. Mỗi nhà phát triển chọn ngầm một lá bài đại diện cho ước tính của họ.
4. Bật mí các lá bài cùng lúc.
5. Nếu các con số chênh lệch lớn, thảo luận lý do và bỏ phiếu lại.
6. Tính trung bình kết quả để xác định kích thước câu chuyện.

🚫 Những sai lầm phổ biến cần tránh

Ngay cả các đội có kinh nghiệm cũng vấp phải những cái bẫy phổ biến này. Nhận thức được chúng có thể giúp đội của bạn tiết kiệm thời gian và sự thất vọng.

• Viết cho nhà phát triển: Tránh sử dụng ngôn ngữ kỹ thuật trong chính câu chuyện. Giữ bối cảnh người dùng rõ ràng.
• Quá nhiều câu chuyện trong một Sprint: Cam kết quá mức dẫn đến công việc chưa hoàn thành. Tốt hơn hết là giao ít câu chuyện hoàn chỉnh hơn là nhiều câu chuyện chưa hoàn tất.
• Bỏ qua nợ kỹ thuật:Đôi khi cần một câu chuyện chỉ để sửa chữa cơ sở hạ tầng nền tảng. Đảm bảo điều này được hiển thị rõ ràng cho các bên liên quan.
• Bỏ qua giai đoạn tinh chỉnh:Đừng chờ đến cuộc họp lập kế hoạch mới thảo luận về các câu chuyện. Hãy xem xét chúng trước để cuộc họp chỉ dành cho lập kế hoạch, chứ không phải đọc.
• Tiêu chí chấp nhận mơ hồ:Sự mơ hồ dẫn đến lỗi. Hãy rõ ràng về các trường hợp biên.

🤝 Hợp tác và Giao tiếp

Câu chuyện người dùng là công cụ giao tiếp, chứ không chỉ là công cụ tài liệu hóa. Giá trị nằm ở cuộc trò chuyện xung quanh câu chuyện, chứ không phải văn bản trên thẻ.

Các thực hành tốt nhất cho hợp tác:

• Tham gia toàn bộ đội ngũ:Các nhà phát triển, kiểm thử và nhà thiết kế nên cùng đóng góp ý kiến trong quá trình tạo câu chuyện.
• Làm rõ từ sớm:Nếu một câu chuyện không rõ ràng, hãy đặt câu hỏi trong giai đoạn tinh chỉnh, chứ không phải trong quá trình phát triển.
• Giữ bối cảnh rõ ràng:Đảm bảo các bên liên quan hiểu được mức độ ưu tiên và lý do đằng sau công việc.
• Đánh giá thường xuyên:Cập nhật các câu chuyện khi yêu cầu thay đổi. Đừng để chúng trở nên lỗi thời.

✅ Danh sách kiểm tra đánh giá

Trước khi thêm một câu chuyện vào sprint, hãy kiểm tra qua danh sách này để đảm bảo chất lượng.

Kiểm tra	Trạng thái
Câu chuyện có tuân theo định dạng Là một… Tôi muốn… Để… không?	☐
Các tiêu chí chấp nhận có rõ ràng và kiểm thử được không?	☐
Câu chuyện có đủ nhỏ để hoàn thành trong một sprint không?	☐
Câu chuyện có mang lại giá trị cho người dùng không?	☐
Có phụ thuộc nào vào các công việc khác không?	☐
Có được ước lượng bởi đội phát triển không?	☐

📈 Tiến bước về phía trước

Thành thạo các câu chuyện người dùng đòi hỏi thực hành. Bạn sẽ gặp những câu chuyện mơ hồ, những câu chuyện quá phức tạp và những câu chuyện thay đổi hướng đi. Điều này là bình thường. Điều quan trọng là duy trì sự tập trung vào giá trị và giao tiếp rõ ràng.

Bắt đầu bằng việc viết một câu chuyện mỗi ngày. Xem xét lại nó theo các tiêu chí INVEST. Hãy hỏi đồng nghiệp của bạn phản hồi. Theo thời gian, quy trình này trở nên tự nhiên. Bạn sẽ nhận ra rằng những câu chuyện rõ ràng dẫn đến các chu kỳ phát triển trơn tru hơn và người dùng hạnh phúc hơn.

Hãy nhớ, mục tiêu không phải là sự hoàn hảo trong cách viết, mà là sự rõ ràng trong hiểu biết. Nếu đội ngũ hiểu được mục tiêu, mã nguồn sẽ theo kịp.

Tóm tắt các khái niệm chính

• Câu chuyện người dùng:Tập trung vào giá trị người dùng, không phải các thông số kỹ thuật.
• Tiêu chí chấp nhận:Xác định khi nào công việc được hoàn thành.
• INVEST:Sử dụng mô hình này để xác minh chất lượng câu chuyện.
• Điểm câu chuyện:Đo lường nỗ lực một cách tương đối, chứ không phải theo thời gian.
• Hợp tác:Câu chuyện là một công cụ cho cuộc trò chuyện.

Bằng cách tuân thủ những nguyên tắc này, bạn xây dựng nền tảng cho phát triển bền vững. Hãy tiếp tục đặt câu hỏi, tiếp tục hoàn thiện kỹ năng của mình và luôn ưu tiên người dùng.