Trong thế giới phát triển phần mềm đầy tốc độ, sự rõ ràng là đồng tiền. Các đội có khả năng giao tiếp hiệu quả sẽ đưa ra sản phẩm tốt hơn, nhanh hơn. Ở trung tâm của sự giao tiếp này chính là câu chuyện người dùng. Nó không chỉ đơn thuần là một vé trong danh sách công việc; mà là lời hứa về một cuộc trò chuyện, phương tiện mang lại giá trị và công cụ để đồng thuận.
Hướng dẫn này sẽ dẫn bạn qua các thao tác tạo ra những câu chuyện người dùng chất lượng cao. Chúng ta sẽ đi từ những định nghĩa cơ bản đến các kỹ thuật nâng cao như lập bản đồ và tinh chỉnh. Đến cuối hướng dẫn, bạn sẽ có một khung thực tiễn để viết những câu chuyện mà các nhà phát triển hiểu được, người kiểm thử có thể xác minh và các bên liên quan có thể ưu tiên. Hãy bắt đầu nào.
Câu chuyện người dùng thực sự 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 có 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 yêu cầu cụ thể. Nó là một chỗ trống cho một cuộc trò chuyện.
Khác với các tài liệu yêu cầu truyền thống, có thể cứng nhắc và dài dòng, câu chuyện người dùng được thiết kế để nhẹ nhàng. Chúng tập trung vào ai, điều gì, và tại sao.
Định dạng Chuẩn
Hầu hết các đội Agile sử dụng một mẫu chuẩn để đảm bảo tính nhất quán. Mẫu này giúp duy trì sự tập trung vào giá trị người dùng thay vì chi tiết triển khai kỹ thuật.
- Là một:Tôi muốn: Để rằng:
- Là một: [vai trò người dùng]
- Tôi muốn: [hành động hoặc tính năng]
- Để rằng: [lợi ích hoặc giá trị]
Hãy xem xét một tình huống mà người dùng cần đặt lại mật khẩu. Một yêu cầu được viết kém có thể nói: “Hệ thống phải cho phép đặt lại mật khẩu qua email.” Một câu chuyện người dùng sẽ được viết như sau:
- Là mộtngười dùng đã đăng ký
- Tôi muốnđặt lại mật khẩu của tôi qua email
- Để rằngtôi có thể lấy lại quyền truy cập vào tài khoản của mình mà không cần liên hệ hỗ trợ
Định dạng này buộc đội phải suy nghĩ về giá trị cốt lõi đằng sau. Nó chuyển cuộc trò chuyện từ “chúng ta xây dựng nút này như thế nào” sang “tại sao người dùng cần truy cập vào nút này”.
Mô hình INVEST: Tiêu chí cho các câu chuyện chất lượng 🌟
Không phải mọi câu chuyện người dùng nào cũng được tạo ra như nhau. Một số thì mơ hồ, một số quá lớn, và một số là không thể kiểm thử về mặt kỹ thuật. Để lọc ra các mục chất lượng thấp, các đội thường sử 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.
Độc lập
Một câu chuyện nên độc lập tối đa. Nếu một câu chuyện phụ thuộc vào việc một câu chuyện khác phải hoàn thành trước khi có thể thảo luận, điều này sẽ tạo ra các điểm nghẽn. Mặc dù các phụ thuộc tồn tại trong phần mềm, chúng cần được quản lý một cách rõ ràng. Về lý tưởng, một đội nên có thể nhận một câu chuyện và hoàn thành nó mà không cần phải thực hiện một nhiệm vụ cụ thể phía trên.
Thương lượng được
Mô tả câu chuyện không phải là một hợp đồng. Nó chỉ là lời nhắc về một cuộc trò chuyện. Các chi tiết cần được thương lượng giữa đội phát triển và người sở hữu sản phẩm. Sự linh hoạt này cho phép đội đề xuất các giải pháp kỹ thuật có thể tốt hơn yêu cầu ban đầu.
Có giá trị
Mỗi câu chuyện phải mang lại giá trị. Nếu một câu chuyện không mang lại giá trị cho người dùng hoặc doanh nghiệp, thì nó không nên tồn tại. Giá trị có thể là chức năng, kỹ thuật (như giảm nợ kỹ thuật), hoặc liên quan đến tuân thủ. Nếu bạn không thể nêu rõ giá trị, câu chuyện đó có khả năng là không cần thiết.
Có thể ước lượng
Đội cần có khả năng ước lượng nỗ lực cần thiết để hoàn thành câu chuyện. Nếu một câu chuyện quá mơ hồ hoặc phụ thuộc vào công nghệ chưa biết, thì không thể ước lượng được. Trong những trường hợp này, câu chuyện cần được chia nhỏ hơn hoặc nghiên cứu kỹ hơn thông qua một thử nghiệm ngắn (spike).
Nhỏ
Các câu chuyện nên đủ nhỏ để có thể hoàn thành trong một lần sprint. Nếu một câu chuyện quá lớn, nó sẽ trở thành một dự án. Các câu chuyện lớn rất khó kiểm thử, khó ước lượng và khó ưu tiên. Việc chia nhỏ chúng thành các bước nhỏ hơn sẽ giúp nhận phản hồi nhanh hơn.
Kiểm thử được
Một câu chuyện phải có các điều kiện rõ ràng để coi là hoàn thành. Nếu bạn không thể viết một trường hợp kiểm thử cho nó, bạn sẽ không thể xác minh được nó đã hoàn thành hay chưa. Điều này liên quan trực tiếp đến định nghĩa về ‘đã hoàn thành’.
| Tiêu chí | Câu hỏi cần đặt ra | Ví dụ vấn đề |
|---|---|---|
| Độc lập | Chúng ta có thể xây dựng điều này mà không cần câu chuyện khác không? | “Đăng nhập” phụ thuộc vào “Hồ sơ người dùng” |
| Thương lượng được | Chúng ta có sẵn sàng thay đổi giải pháp không? | “Sử dụng API X” thay vì “Sử dụng Tính năng Y” |
| Có giá trị | Điều này có giúp người dùng không? | “Thay đổi màu phông chữ để phù hợp với thương hiệu” |
| Có thể ước lượng | Chúng ta có biết điều này mất bao lâu không? | “Tích hợp với bên thứ ba chưa biết” |
| Nhỏ | Liệu điều này có thể hoàn thành trong một sprint không? | “Xây dựng toàn bộ bảng điều khiển” |
| Có thể kiểm thử | Chúng ta có thể viết một bài kiểm thử cho điều này không? | “Làm cho ứng dụng nhanh hơn” |
Bước từng bước: Viết một câu chuyện người dùng 🛠️
Viết một câu chuyện người dùng là một quá trình lặp lại. Hiếm khi điều này xảy ra trong một lần ngồi viết. Dưới đây là cách tiếp cận có hệ thống để soạn thảo một câu chuyện có thể chịu được sự kiểm tra kỹ lưỡng.
Bước 1: Xác định nhân vật người dùng
Trước khi viết bất kỳ từ nào, hãy xác định ai là người bạn đang viết cho. Một câu chuyện dành cho quản trị viên khác với câu chuyện dành cho người dùng thường xuyên. Sử dụng thẻ nhân vật hoặc hồ sơ hiện có để đảm bảo bạn hiểu được mục tiêu và giới hạn của họ.
Bước 2: Xác định hành động
Hãy cụ thể về việc người dùng muốn làm gì. Tránh dùng những động từ mơ hồ như “quản lý” hoặc “xử lý”. Sử dụng các động từ hành động như “nhấp”, “lưu”, “xóa” hoặc “xuất”. Sự rõ ràng này giúp các nhà phát triển hiểu được tương tác cụ thể cần thiết.
Bước 3: Nêu rõ giá trị
Đây là phần quan trọng nhất. Tại sao người dùng lại quan tâm? Nếu bạn bỏ qua phần “Để mà” thì bạn có nguy cơ xây dựng các tính năng mà không ai sử dụng. Thường xuyên thách thức đội ngũ giải thích lợi ích của nó.
Bước 4: Thêm bối cảnh và ràng buộc
Đôi khi một câu chuyện cần thêm bối cảnh. Điều này có thể bao gồm các ràng buộc kỹ thuật, yêu cầu pháp lý hoặc các trường hợp đặc biệt. Đặt thông tin này vào phần mô tả hoặc như các bình luận đính kèm vào câu chuyện, chứ không đặt trong tiêu đề.
Bước 5: Xem xét theo tiêu chí INVEST
Trước khi thêm câu chuyện vào danh sách công việc, hãy kiểm tra nó theo danh sách kiểm tra INVEST. Nó có phù hợp không? Nếu không, hãy tinh chỉnh nó. Tốt hơn là dành năm phút để tinh chỉnh câu chuyện ngay bây giờ thay vì mất năm giờ để sửa hiểu lầm trong quá trình phát triển.
Tiêu chí chấp nhận: Giới hạn của trạng thái ‘đã hoàn thành’ ✅
Tiêu chí chấp nhận xác định ranh giới của một câu chuyện. Chúng là những điều kiện phải được đáp ứng để câu chuyện được coi là hoàn thành. Không có chúng, “đã hoàn thành” sẽ mang tính chủ quan.
Các loại tiêu chí chấp nhận
Có nhiều cách để cấu trúc tiêu chí chấp nhận. Cách hiệu quả nhất thường phụ thuộc vào quy trình làm việc của đội nhóm.
- Dựa trên tình huống:Sử dụng cú pháp Given/When/Then giúp làm rõ luồng logic.
- Danh sách kiểm tra:Những điểm đánh dấu đơn giản để xác minh các kết quả cụ thể.
- Quy tắc:Các quy tắc toán học hoặc logic phải được đáp ứng.
- Luồng người dùng:Mô tả hành trình mà người dùng trải qua qua tính năng.
Ví dụ về tiêu chí chấp nhận
Hãy cùng xem cách các tiêu chí khác nhau tùy theo loại câu chuyện.
| Tập trung vào câu chuyện | Ví dụ về tiêu chí chấp nhận |
|---|---|
| Chức năng | |
| Bảo mật | |
| Hiệu suất | |
| Khả năng sử dụng |
Viết các tiêu chí hiệu quả
Khi viết các tiêu chí này, hãy giữ chúng ở mức nguyên tử. Không kết hợp nhiều điều kiện vào một câu. Mỗi tiêu chí phải là một điều kiện có thể kiểm thử duy nhất. Điều này giúp người kiểm thử dễ dàng xác minh công việc và nhà phát triển biết chính xác những gì cần thực hiện.
Tránh sử dụng các thuật ngữ chủ quan như “nhanh”, “dễ”, hoặc “hiện đại”. Thay vào đó, hãy dùng các thuật ngữ có thể đo lường như “dưới 200ms”, “ít hơn 3 lần nhấp”, hoặc “phù hợp với WCAG 2.1”.
Bản đồ câu chuyện người dùng: Trực quan hóa hành trình 🗺️
Đôi khi một danh sách các câu chuyện là chưa đủ. Bạn cần nhìn thấy bức tranh toàn cảnh. Bản đồ câu chuyện người dùng là một kỹ thuật được sử dụng để trực quan hóa trải nghiệm người dùng và sắp xếp các câu chuyện thành một kế hoạch phát hành thống nhất.
Tạo xương sống
Bắt đầu bằng cách xác định các hoạt động chính mà người dùng thực hiện. Đây là xương sống ngang của bạn. Đối với một trang thương mại điện tử, các hoạt động này có thể bao gồm: Duyệt, Tìm kiếm, Thêm vào giỏ hàng, Thanh toán và Quản lý tài khoản.
Thêm các bước
Dưới mỗi hoạt động, hãy liệt kê các bước cụ thể cần thiết. Đây chính là các câu chuyện người dùng của bạn. Sắp xếp chúng theo chiều ngang theo thứ tự thực hiện. Điều này tạo thành xương sống của hành trình người dùng.
Ưu tiên cho phát hành
Sau khi bản đồ được xây dựng, bạn có thể cắt nó theo chiều ngang. Dòng trên cùng đại diện cho Sản phẩm Tối thiểu Khả thi (MVP). Dòng tiếp theo thêm giá trị hơn. Điều này giúp các đội ưu tiên xây dựng những gì trước dựa trên giá trị người dùng, thay vì sự thuận tiện về kỹ thuật.
Lợi ích của việc lập bản đồ
- Cung cấp cái nhìn toàn diện về sản phẩm.
- Phát hiện các khoảng trống trong luồng người dùng.
- Hỗ trợ lập kế hoạch và lên lịch phát hành tốt hơn.
- Khuyến khích sự hợp tác giữa các nhà thiết kế và nhà phát triển.
Tinh chỉnh và ước lượng 📏
Viết câu chuyện chỉ là một nửa cuộc chiến. Đội ngũ phải hiểu rõ phạm vi và nỗ lực cần thiết. Điều này xảy ra trong các buổi tinh chỉnh.
Làm rõ sự mơ hồ
Trong quá trình tinh chỉnh, đội ngũ đặt ra các câu hỏi. “Điều gì xảy ra nếu người dùng không có kết nối internet?” “Chúng ta xử lý thế nào khi có email trùng lặp?” Những câu hỏi này làm nổi bật sự phức tạp ẩn giấu. Đừng chờ đến khi sprint bắt đầu mới đặt ra những câu hỏi này.
Đo lường quy mô các câu chuyện
Các đội thường sử dụng đo lường tương đối thay vì giờ. Điều này công nhận rằng việc ước lượng thời gian là khó khăn và khác nhau tùy theo từng người. Các phương pháp phổ biến bao gồm:
- Bài đánh giá kế hoạch:Các thành viên trong đội bỏ phiếu về quy mô bằng cách sử dụng thẻ bài.
- Điểm câu chuyện:Một giá trị số đại diện cho độ phức tạp, nỗ lực và rủi ro.
- Kích cỡ áo thun:Nhỏ, Trung bình, Lớn, X-Large cho lập kế hoạch cấp cao.
Dù sử dụng phương pháp nào, mục tiêu là đạt được sự đồng thuận. Nếu đội ngũ không đồng ý rõ rệt, câu chuyện cần được chia nhỏ hơn hoặc nghiên cứu sâu hơn.
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 xử lý các câu chuyện người dùng. Nhận thức về những sai lầm phổ biến này có thể tiết kiệm thời gian và sự bực bội đáng kể.
1. Viết các câu chuyện kỹ thuật dưới dạng câu chuyện người dùng
Những nhiệm vụ như “Tái cấu trúc lược đồ cơ sở dữ liệu” hay “Nâng cấp phiên bản thư viện” là quan trọng, nhưng chúng không phải là câu chuyện người dùng. Chúng là các nhiệm vụ kỹ thuật. Mặc dù chúng nên tồn tại trong danh sách công việc, chúng cần được trình bày dưới dạng nợ kỹ thuật hoặc công việc cơ sở hạ tầng, chứ không phải giá trị trực tiếp cho người dùng. Nếu bạn buộc phải viết một câu chuyện cho việc này, hãy trình bày như sau: “Là một nhà phát triển, tôi muốn cập nhật thư viện để tránh các lỗ hổng bảo mật.”
2. Bỏ qua phần “để mà”
Bỏ qua mệnh đề lợi ích dẫn đến hiện tượng mở rộng tính năng. Các đội xây dựng những thứ trông tốt nhưng không giải quyết được vấn đề. Luôn buộc đội phải chứng minh được giá trị của nó.
3. Quá tải mô tả
Mô tả câu chuyện không nên giống như một tiểu thuyết. Nếu câu chuyện đòi hỏi 10 trang tài liệu, thì nó quá lớn. Hãy chia nhỏ lại. Mô tả chỉ nên là bản tóm tắt, có thể kèm liên kết đến tài liệu chi tiết nếu cần thiết.
4. Xem các câu chuyện như hợp đồng cố định
Hãy nhớ đến khía cạnh có thể thương lượng. Nếu đội tìm ra cách giải quyết vấn đề tốt hơn, họ nên đề xuất. Việc tuân thủ cứng nhắc yêu cầu ban đầu có thể kìm hãm sự đổi mới.
5. Bỏ qua các trường hợp biên
Các câu chuyện thường tập trung vào con đường thuận lợi. Người kiểm thử và nhà phát triển phải cụ thể hóa các trường hợp biên. Điều gì xảy ra nếu đầu vào là null? Điều gì xảy ra nếu mạng bị lỗi? Những tình huống này phải là một phần trong tiêu chí chấp nhận.
Hợp tác và giao tiếp 🗣️
Câu chuyện người dùng là công cụ để hợp tác. Nó kết nối người sở hữu sản phẩm, đội phát triển và người kiểm thử. Không có giao tiếp, câu chuyện chỉ là văn bản trên màn hình.
Ba người bạn
Một thực hành phổ biến là cuộc họp “Ba người bạn”. Cuộc họp này bao gồm người sở hữu sản phẩm, một nhà phát triển và một người kiểm thử thảo luận về một câu chuyện trước khi nó bước vào sprint. Họ cùng nhau xem xét câu chuyện để đảm bảo sự hiểu biết và bao phủ đầy đủ.
- Người sở hữu sản phẩm:Xác nhận giá trị và mức độ ưu tiên.
- Nhà phát triển:Xác nhận tính khả thi kỹ thuật và độ phức tạp.
- Người kiểm thử:Xác nhận khả năng kiểm thử và các trường hợp biên.
Phản hồi liên tục
Đừng chờ đến buổi đánh giá sprint để nhận phản hồi. Chia sẻ các bản nháp câu chuyện với các bên liên quan từ sớm. Nhận ý kiến phản hồi về cách diễn đạt và đề xuất giá trị. Điều này giúp giảm thiểu rủi ro xây dựng sai thứ gì đó.
Trợ giúp hình ảnh
Chỉ có văn bản là chưa đủ. Hãy sử dụng sơ đồ bố cục, bản mô phỏng hoặc sơ đồ để bổ sung cho câu chuyện. Một bức ảnh có thể giải thích một quy trình phức tạp nhanh hơn một đoạn văn bản. Đính kèm các tài liệu này trực tiếp vào hồ sơ câu chuyện.
Suy nghĩ cuối cùng về nghệ thuật viết câu chuyện 🎯
Thành thạo nghệ thuật viết câu chuyện người dùng đòi hỏi luyện tập. Nó yêu cầu thay đổi tư duy từ việc viết yêu cầu sang việc thúc đẩy các cuộc trò chuyện. Mục tiêu không phải là tạo ra những tài liệu hoàn hảo, mà là tạo ra sự hiểu rõ ràng.
Bắt đầu nhỏ. Tập trung vào mô hình INVEST. Đảm bảo mỗi câu chuyện đều mang lại giá trị. Sẵn sàng chia nhỏ hơn nếu chúng cảm giác quá lớn. Tham gia đội ngũ vào quá trình viết.
Khi được thực hiện tốt, các câu chuyện người dùng trở thành nền tảng cho quá trình giao hàng của bạn. Chúng đồng bộ hóa đội nhóm, làm rõ tầm nhìn và đảm bảo mỗi dòng mã đều phục vụ một mục đích. Tiếp tục tinh chỉnh phương pháp của bạn, và để các câu chuyện dẫn dắt công việc của bạn.