Tạo giá trị trong phát triển phần mềm đòi hỏi hơn cả việc viết mã. Nó đòi hỏi sự hiểu rõ vềaicần một tính năng vàtại saohọ cần nó. Đây chính là nơi câu chuyện người dùng phát huy vai trò. Một câu chuyện được xây dựng tốt sẽ cầu nối khoảng cách giữa mục tiêu kinh doanh và triển khai kỹ thuật.
Hướng dẫn này sẽ dẫn bạn qua quy trình viết câu chuyện người dùng hiệu quả đầu tiên của mình. Chúng ta sẽ tập trung vào sự rõ ràng, hợp tác và việc cung cấp giá trị mà không phụ thuộc vào công cụ cụ thể hay những lời quảng cáo hoa mỹ. Đến cuối hướng dẫn, bạn sẽ có một khung nền vững chắc để ghi nhận các yêu cầu mà đội của bạn thực sự có thể xây dựng.
🧩 Câu chuyện người dùng là gì?
Câu chuyện người dùng là một 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, thường là người dù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ãy nghĩ về một câu chuyện như một cam kết phải nói chuyện. Nó khuyến khích sự trao đổi giữa các nhà phát triển, kiểm thử viên và các bên liên quan. Nó đảm bảo mọi người đều đồng ý về hình ảnh thành công trước khi viết bất kỳ dòng mã nào.
Dưới đây là những đặc điểm cốt lõi của một câu chuyện tốt:
-
Tập trung vào giá trị:Nó giải thích lợi ích, chứ không chỉ là chức năng.
-
Độc lập:Nó có thể được phát triển riêng biệt so với các câu chuyện khác.
-
Có thể ước lượng:Đội ngũ có thể hiểu được kích thước và nỗ lực cần thiết.
-
Có giá trị:Nó mang lại giá trị cụ thể cho người dùng hoặc doanh nghiệp.
-
Có thể kiểm thử:Có các điều kiện rõ ràng để xác minh việc hoàn thành.
-
Nhỏ gọn:Nó phù hợp trong một lần lặp lại hoặc một vòng sprint duy nhất.
📝 Định dạng chuẩn
Mặc dù có sự linh hoạt, nhưng một định dạng nhất quán sẽ giúp các đội giao tiếp nhanh chóng. Mẫu phổ biến nhất tuân theo cấu trúc này:
Là một [loại người dùng],
Tôi muốn [mục tiêu nào đó],
Để rằng [một lợi ích nào đó].
Hãy phân tích từng phần để đảm bảo độ chính xác.
1. Nhân vật (Là một…)
Xác định vai trò cụ thể. Tránh dùng các thuật ngữ chung như “người dùng”. Hãy cụ thể về đối tượng mục tiêu. Điều này giúp câu chuyện gắn liền với thực tế.
-
Yếu: Là một người dùng…
-
Mạnh: Là một khách hàng quay lại…
-
Mạnh: Là một quản trị viên…
2. Hành động (Tôi muốn…)
Mô tả khả năng bạn cần. Giữ ở mức độ cao. Không mô tả chi tiết giải pháp ở đây. Lưu lại các chi tiết triển khai cho cuộc trò chuyện sau.
-
Yếu: Tôi muốn một nút trên màn hình…
-
Mạnh: Tôi muốn đặt lại mật khẩu của mình…
-
Mạnh: Tôi muốn lọc kết quả tìm kiếm…
3. Lợi ích (Để mà…)
Đây là phần quan trọng nhất. Nó trả lời câu hỏi “tại sao”. Nếu bạn không thể giải thích được giá trị, câu chuyện có thể không đáng để xây dựng.
-
Yếu: Để hệ thống hoạt động.
-
Mạnh: Để tôi có thể khôi phục truy cập nhanh chóng.
-
Mạnh: Để tôi có thể tìm thấy sản phẩm liên quan nhanh hơn.
🔍 Phân tích sâu mô hình INVEST
Để đảm bảo chất lượng, các đội thường áp dụng mô hình INVEST. Chữ viết tắt này đóng vai trò như một danh sách kiểm tra để đánh giá các câu chuyện của bạn.
|
Chữ cái |
Nghĩa |
Mô tả |
|---|---|---|
|
I |
Độc lập |
Các câu chuyện không nên phụ thuộc vào người khác để được thực hiện. |
|
N |
Có thể thương lượng |
Chi tiết là mở cho thảo luận giữa đội và bên liên quan. |
|
V |
Có giá trị |
Phải mang lại giá trị cho người dùng hoặc doanh nghiệp. |
|
E |
Có thể ước lượng |
Đội phải có đủ thông tin để ước lượng nỗ lực. |
|
S |
Nhỏ |
Phải phù hợp trong một lần lặp lại. |
|
T |
Có thể kiểm thử |
Tiêu chí rõ ràng để xác định hoàn thành. |
Áp dụng INVEST trong thực tiễn
Hãy xem xét một câu chuyện về đăng nhập. Nếu nó quá lớn, hãy chia nhỏ nó.
-
Quá lớn: Là một người dùng, tôi muốn đăng nhập và truy cập tất cả dữ liệu của tôi.
-
Chia 1: Là một người dùng, tôi muốn nhập thông tin xác thực của tôi.
-
Chia 2: Là một người dùng, tôi muốn xem bảng điều khiển hồ sơ của tôi.
Các câu chuyện nhỏ giúp giảm rủi ro. Chúng cho phép vòng phản hồi nhanh hơn. Nếu một câu chuyện không thể ước lượng, nó quá mơ hồ. Hãy đặt câu hỏi cho đến khi phạm vi rõ ràng.
✅ Xây dựng tiêu chí chấp nhận
Một câu chuyện không 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 để câu chuyện được chấp nhận. Chúng xác định ranh giới của công việc.
Sử dụng định dạng Given-When-Then để rõ ràng. Nó tạo bối cảnh, mô tả hành động và xác định kết quả.
Ví dụ: Đặt lại mật khẩu
-
Tình huống: Người dùng yêu cầu đặt lại.
-
Cho rằng Tôi đang ở trang đăng nhập và nhấp vào “Quên mật khẩu”.
-
Khi Tôi nhập địa chỉ email đã đăng ký của mình.
-
Thì Tôi nhận được email chứa liên kết đặt lại.
-
Và liên kết sẽ hết hạn sau 24 giờ.
Tại sao Tiêu chí chấp nhận lại quan trọng
-
Hiểu biết chung: Các nhà phát triển và kiểm thử đồng thuận về những gì đang được xây dựng.
-
Tự động hóa kiểm thử: Các tiêu chí thường có thể được chuyển đổi thành các kịch bản kiểm thử tự động.
-
Tiêu chuẩn hoàn thành: Chúng làm rõ khi nào công việc thực sự đã hoàn thành.
Đừng để tiêu chí chấp nhận như một danh sách mong muốn. Hãy làm cho chúng cụ thể. Tránh dùng những từ như “dễ dùng” hay “nhanh”. Sử dụng các thuật ngữ đo lường được như “tải trong dưới 2 giây” hoặc “có thể nhấp vào trong 3 lần nhấp”.
🚧 Những sai lầm phổ biến cần tránh
Ngay cả các đội có kinh nghiệm cũng mắc sai lầm khi thu thập yêu cầu. Dưới đây là những lỗi phổ biến nhất và cách khắc phục chúng.
|
Sai lầm |
Tại sao nó thất bại |
Giải pháp |
|---|---|---|
|
Tập trung vào kỹ thuật |
Mô tả các nhiệm vụ phía backend thay vì giá trị dành cho người dùng. |
Đổi hướng tập trung sang trải nghiệm người dùng. |
|
Động từ mơ hồ |
Sử dụng các từ như “tối ưu hóa” hoặc “nâng cao”. |
Sử dụng các hành động cụ thể như “cập nhật” hoặc “xóa”. |
|
Thiếu bối cảnh |
Không giải thích phần “Để mà”. |
Hỏi “Tại sao điều này quan trọng?” năm lần. |
|
Quá lớn |
Bao trùm nhiều tuần hoặc nhiều vòng phát triển. |
Chia thành các câu chuyện nhỏ hơn, độc lập. |
Ví dụ: Tập trung kỹ thuật so với tập trung người dùng
Xấu: Là một nhà phát triển, tôi muốn tái cấu trúc lược đồ cơ sở dữ liệu.
Tốt: Là một khách hàng, tôi muốn xem lịch sử đơn hàng của mình ngay lập tức sau khi thanh toán.
Ví dụ đầu tiên tập trung vào công việc. Ví dụ thứ hai tập trung vào giá trị. Ngay cả khi công việc kỹ thuật là giống nhau, câu chuyện vẫn phải chứng minh lý do cho nỗ lực thông qua lợi ích dành cho người dùng.
🤝 Hợp tác và tinh chỉnh
Viết một câu chuyện là một môn thể thao đồng đội. Nó liên quan đến toàn bộ đội nhóm. Người viết câu chuyện hiếm khi là người duy nhất cần hiểu nó.
Ba yếu tố C của câu chuyện người dùng
-
Thẻ: Đại diện vật lý hoặc số hóa của câu chuyện.
-
Cuộc trò chuyện: Những cuộc thảo luận làm rõ chi tiết.
-
Xác nhận: Các tiêu chí chấp nhận và bài kiểm thử.
Không bao giờ bỏ qua cuộc trò chuyện. Một thẻ mà không có cuộc trò chuyện chỉ là một vé. Một cuộc trò chuyện mà không có thẻ chỉ là tiếng ồn. Cần cân bằng cả hai.
Các buổi tinh chỉnh
Dành thời gian để xem xét các câu chuyện sắp tới. Quá trình này thường được gọi là dọn dẹp. Trong các buổi này:
-
Xem xét lại danh sách công việc để đảm bảo rõ ràng.
-
Xác định các tiêu chí chấp nhận còn thiếu.
-
Ước lượng nỗ lực tương đối so với các mục khác.
-
Đảm bảo các câu chuyện phù hợp với lộ trình hiện tại.
Việc tinh chỉnh giảm thiểu sự không chắc chắn. Nó ngăn đội ngũ bị bất ngờ bởi các yêu cầu phức tạp trong giai đoạn thực hiện công việc thực tế.
📈 Đo lường thành công
Làm sao bạn biết các câu chuyện của mình có hiệu quả không? Hãy nhìn vào dòng chảy công việc.
-
Tính nhất quán về tốc độ:Nếu ước lượng câu chuyện chính xác, tốc độ của đội bạn sẽ ổn định.
-
Giảm công việc làm lại:Các câu chuyện rõ ràng nghĩa là ít lỗi hơn và ít thay đổi hơn sau khi phát triển bắt đầu.
-
Sự hài lòng của các bên liên quan:Người sở hữu sản phẩm nên cảm thấy được lắng nghe và thấy được giá trị được cung cấp.
Theo dõi các chỉ số này theo thời gian. Nếu bạn thấy các thay đổi thường xuyên về yêu cầu trong giữa vòng lặp, các câu chuyện của bạn có thể quá mơ hồ. Nếu bạn luôn hoàn thành sớm, chúng có thể quá nhỏ. Điều chỉnh kích thước và chi tiết cho phù hợp.
🛠️ Các ví dụ thực tế
Hãy cùng xem một vài tình huống ở các lĩnh vực khác nhau để củng cố hiểu biết.
Tình huống 1: Thương mại điện tử
-
Là mộtngười mua sắm,
-
Tôi muốnlưu các sản phẩm vào danh sách mong muốn,
-
Để rằngTôi có thể mua chúng sau này khi có ngân sách nhiều hơn.
Tình huống 2: Quản lý dự án
-
Là mộttrưởng nhóm,
-
Tôi muốnxuất dữ liệu nhiệm vụ sang định dạng CSV,
-
Để rằngTôi có thể phân tích hiệu suất bằng công cụ bảng tính.
Tình huống 3: Y tế
-
Là mộtbệnh nhân,
-
Tôi muốn xem kết quả xét nghiệm của tôi trực tuyến,
-
Để rằng Tôi có thể hiểu tình trạng sức khỏe của mình mà không cần chờ cuộc gọi.
Lưu ý cách mỗi câu chuyện xác định một vai trò cụ thể, một hành động rõ ràng và một kết quả có ý nghĩa. Không có câu chuyện nào đề cập đến các tính năng phần mềm cụ thể như “cơ sở dữ liệu” hay “API”. Chúng tập trung vào nhu cầu của con người.
🧠 Tâm lý học của người dùng
Khi viết các câu chuyện, hãy đặt mình vào vị trí của người dùng. Tâm trạng cảm xúc của họ là gì? Họ có đang căng thẳng không? Họ có đang vội vàng không? Bối cảnh này ảnh hưởng đến thiết kế.
-
Bản đồ đồng cảm: Ghi chép lại những gì người dùng nhìn thấy, nghe thấy, suy nghĩ và cảm nhận.
-
Bản đồ hành trình: Trực quan hóa các bước mà người dùng thực hiện để đạt được mục tiêu của họ.
-
Vòng phản hồi: Thu thập phản hồi thực tế từ người dùng sớm để xác minh các giả định.
Hiểu rõ người dùng giúp tránh việc xây dựng các tính năng mà không ai sử dụng. Điều này giúp đội ngũ đồng lòng về yếu tố con người trong sản phẩm.
🔄 Lặp lại và phát triển
Các câu chuyện không phải là bất biến. Chúng phát triển theo thời gian khi bạn học được nhiều hơn. Nếu bạn phát hiện ra cách tốt hơn để giải quyết vấn đề trong quá trình phát triển, hãy thảo luận. Mục tiêu là tạo ra giá trị, chứ không phải con đường triển khai cụ thể.
-
Hãy linh hoạt: Cho phép câu chuyện thay đổi nếu nó không còn mang lại giá trị.
-
Ghi chép các quyết định: Ghi lại lý do vì sao các thay đổi được thực hiện để tham khảo trong tương lai.
-
Xem xét thường xuyên: Xem lại các câu chuyện cũ để đảm bảo chúng vẫn phù hợp với mục tiêu kinh doanh.
Tính linh hoạt nằm ở việc thích nghi với thay đổi. Các câu chuyện của bạn nên thể hiện sự linh hoạt đó. Đừng coi chúng như hợp đồng, hãy coi chúng như lời hứa mang lại giá trị.
📝 Danh sách kiểm tra cho câu chuyện tiếp theo của bạn
Trước khi chuyển một câu chuyện sang giai đoạn phát triển, hãy kiểm tra nó qua danh sách này.
-
☑ Nó có tuân theo định dạng Là một… Tôi muốn… Để rằng… không?
-
☑ Nhân vật đại diện có cụ thể và dễ nhận diện không?
-
☑ Lợi ích có rõ ràng và mang lại giá trị không?
-
☑ Có các tiêu chí chấp nhận được xác định không?
-
☑ Câu chuyện có đủ nhỏ để hoàn thành trong một lần lặp lại không?
-
☑ Đội nhóm có thể ước lượng nỗ lực không?
-
☑ Có phụ thuộc vào các câu chuyện khác không?
-
☑ Các bên liên quan đã xem xét các tiêu chí chưa?
Sử dụng danh sách kiểm tra đảm bảo tính nhất quán. Nó giảm thiểu khả năng bỏ sót các chi tiết quan trọng. Theo thời gian, điều này trở nên tự nhiên.
🌟 Những suy nghĩ cuối cùng
Viết các câu chuyện người dùng hiệu quả là một kỹ năng được cải thiện qua thực hành. Nó đòi hỏi sự thấu cảm, sự rõ ràng và kỷ luật. Bằng cách tập trung vào người dùng và giá trị, bạn sẽ tạo nên nền tảng cho việc giao hàng thành công.
Bắt đầu nhỏ. Chọn một câu chuyện hôm nay và áp dụng những nguyên tắc này. Rèn luyện nó cùng đội nhóm của bạn. Kiểm thử các tiêu chí chấp nhận. Nhìn xem chất lượng đầu ra của bạn được cải thiện như thế nào. Mục tiêu không phải là hoàn hảo ngay lần đầu, mà là cải tiến liên tục.
Đội nhóm của bạn đang chờ hướng dẫn rõ ràng. Người dùng của bạn đang chờ giải pháp. Các câu chuyện của bạn là cây cầu. Hãy xây dựng chúng thật tốt.