Hướng dẫn Kể Chuyện Người Dùng: Ngừng Viết Tính Năng và Bắt Đầu Viết Câu Chuyện Người Dùng

Trong thế giới phát triển sản phẩm nhanh chóng, rất dễ rơi vào cái bẫy liệt kê các khả năng. Các đội thường tạo ra những tài liệu đầy những ô chọn cho ‘Đăng nhập’, ‘Tìm kiếm’ hoặc ‘Xuất ra PDF’. Đó là những tính năng. Chúng là đầu vào. Chúng mô tả hệ thống làm gì, chứ không nói lên lý do tại sao điều đó quan trọng. Khi bạn tập trung vào tính năng, bạn có nguy cơ xây dựng những giải pháp không giải quyết được vấn đề thực sự.

Sự chuyển dịch từ tư duy dựa trên tính năng sang viết tập trung vào người dùng thay đổi toàn bộ hướng đi của dự án của bạn. Nó chuyển cuộc trò chuyện từ triển khai kỹ thuật sang giá trị dành cho người dùng. Hướng dẫn này khám phá lý do tại sao bạn nên ngừng viết tính năng và bắt đầu viết câu chuyện người dùng. Chúng ta sẽ xem xét cấu trúc của một câu chuyện mạnh mẽ, cách xác định tiêu chí chấp nhận, và cách đồng bộ hóa đội ngũ xung quanh những kết quả có ý nghĩa.

Hiểu rõ Sự Khác Biệt Cốt Lõi 🧠

Trước khi đi sâu vào chi tiết kỹ thuật, chúng ta cần làm rõ sự khác biệt giữa một tính năng và một câu chuyện. Một tính năng là một chức năng hoặc khả năng riêng biệt của hệ thống phần mềm. Nó là tĩnh. Một câu chuyện người dùng là chỗ trống cho một cuộc trò chuyện về nhu cầu. Nó là động.

Hãy xem xét câu nói: ‘Thêm chế độ tối’. Đây là một tính năng. Nó bảo đội kỹ thuật thay đổi các biến CSS và chuyển đổi các thành phần giao diện người dùng. Nó không giải thích ai cần điều này hay tại sao. Nó giả định giá trị là hiển nhiên.

Bây giờ hãy xem câu chuyện người dùng: ‘Là một nhà thiết kế đồ họa làm việc vào ban đêm, tôi muốn chuyển sang giao diện tối để giảm mỏi mắt trong các buổi chỉnh sửa kéo dài.’ Câu nói này cung cấp bối cảnh. Nó xác định nhân vật. Nó định nghĩa lợi ích.

Khi bạn viết tính năng, bạn giao cho người khác một danh sách nhiệm vụ. Khi bạn viết câu chuyện người dùng, bạn mời gọi sự hợp tác. Tính năng là đầu ra; câu chuyện là kết quả.

Cấu trúc của Một Câu Chuyện Người Dùng 🧩

Mặc dù định dạng cổ điển đơn giản, nhưng chiều sâu nằm ở chi tiết. Một câu chuyện người dùng được viết tốt tuân theo một cấu trúc cụ thể nhằm đảm bảo sự rõ ràng cho tất cả những người tham gia.

• Ai: Nhân vật hoặc loại người dùng.
• Cái gì: Hành động hoặc khả năng họ cần.
• Tại sao: Giá trị hoặc lợi ích họ nhận được.

Định dạng này buộc người viết phải suy nghĩ về yếu tố con người. Nếu bạn không thể điền vào phần ‘Tại sao’, thì có lẽ bạn chưa có một câu chuyện hợp lệ. Bạn chỉ có một mục trong danh sách mong muốn. Xác minh phần ‘Tại sao’ là bước đầu tiên trong việc ưu tiên.

Ví dụ về một câu chuyện Yếu:

“Là một người dùng, tôi muốn tải lên một tệp.”

Điều này quá mơ hồ. Tệp loại gì? Kích thước bao nhiêu? Nếu thất bại thì xảy ra gì? Mục tiêu kinh doanh là gì?

Ví dụ về một câu chuyện Mạnh:

“Là một quản lý dự án, tôi muốn tải lên các tập dữ liệu CSV lớn để có thể cập nhật hàng loạt hồ sơ nhân viên mà không cần nhập thủ công.”

Điều này xác định rõ vai trò, hành động, giới hạn (tập dữ liệu CSV lớn) và mục tiêu kinh doanh (cập nhật hàng loạt mà không cần nhập thủ công).

Mô hình INVEST 📏

Để đảm bảo các câu chuyện của bạn có chất lượng cao, chúng cần tuân theo các tiêu chí INVEST. Khung này giúp xác định xem một câu chuyện đã sẵn sàng cho phát triển hay chưa.

• I – Độc lập: Câu chuyệ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. Các phụ thuộc sẽ tạo ra điểm nghẽn.
• N – Có thể thương lượng: Các chi tiết không cố định. Chúng mở ra để thảo luận giữa các nhà phát triển và người sở hữu sản phẩm.
• V – Có giá trị: Nó phải mang lại giá trị cho người dùng hoặc doanh nghiệp. Nếu không, tại sao lại xây dựng nó?
• E – Có thể ước lượng: Đội ngũ phải có khả năng ước lượng nỗ lực cần thiết. Nếu phạm vi chưa rõ ràng, câu chuyện sẽ quá mơ hồ.
• S – Nhỏ: Nó nên đủ nhỏ để có thể hoàn thành trong một lần sprint hoặc vòng lặp duy nhất.
• T – Có thể kiểm thử: Phải có các tiêu chí rõ ràng để xác định câu chuyện đã hoàn thành hay chưa.

Khi một câu chuyện không đạt tiêu chí ‘Có thể kiểm thử’, thường là danh sách tính năng được che giấu dưới dạng một câu chuyện. Các tiêu chí chấp nhận là chìa khóa để làm cho một câu chuyện có thể kiểm thử.

So sánh Tính năng và Câu chuyện Người dùng 📊

Việc trực quan hóa sự khác biệt giúp làm rõ khi nào nên sử dụng định dạng nào. Mặc dù câu chuyện người dùng là tiêu chuẩn vàng cho công việc phát triển, nhưng tính năng vẫn có vị trí nhất định trong lập kế hoạch cấp cao.

Khía cạnh	Danh sách Tính năng	Câu chuyện Người dùng
Trọng tâm	Khả năng Hệ thống	Giá trị Người dùng
Bối cảnh	Thấp (Kỹ thuật)	Cao (Con người)
Tính linh hoạt	Cứng nhắc	Có thể thương lượng
Kết quả	Chức năng đã cung cấp	Vấn đề đã được giải quyết
Sự đồng thuận của các bên liên quan	Khó biện minh hơn	Dễ biện minh hơn
Tốt nhất cho	Bản đồ hành trình & Lập kế hoạch cấp cao	Lập kế hoạch và thực hiện Sprint

Sử dụng tính năng cho lộ trình để thể hiện định hướng. Sử dụng truyện kể cho Sprint để xác định công việc. Sự nhầm lẫn giữa chúng sẽ dẫn đến hiểu lầm.

Viết tiêu chí chấp nhận ✅

Một câu chuyện mà không có tiêu chí chấp nhận là một lời hứa bạn không thể giữ được. Tiêu chí chấp nhận xác định ranh giới của câu chuyện. Chúng nói với nhà phát triển khi nào nên dừng mã hóa và với người kiểm thử khi nào nên dừng kiểm thử.

Các tiêu chí hiệu quả cần rõ ràng, súc tích và không mơ hồ. Tránh các cụm từ như ‘thân thiện với người dùng’ hay ‘nhanh’. Những từ này mang tính chủ quan. Thay vào đó, hãy sử dụng các thuật ngữ có thể đo lường được.

Tiêu chí xấu:

• Trang web phải tải nhanh.
• Biểu mẫu phải dễ sử dụng.

Tiêu chí tốt:

• Trang web phải tải trong dưới 2 giây trên kết nối 4G.
• Biểu mẫu phải ngăn chặn việc gửi nếu trường email trống.
• Người dùng phải nhận được thông báo xác nhận trong vòng 1 giây kể từ khi gửi.

Một số đội sử dụng định dạng Given-When-Then để cấu trúc các tiêu chí này. Cách tiếp cận này phù hợp tốt với các khung kiểm thử và đảm bảo logic được bao phủ.

• Cho trước:Bối cảnh hoặc trạng thái ban đầu.
• Khi:Hành động hoặc sự kiện.
• Thì:Kết quả mong đợi.

Ví dụ:

Cho trước tôi đã đăng nhập, khi tôi nhấp vào nút xuất, thì tôi phải thấy quá trình tải xuống bắt đầu ngay lập tức.

Những sai lầm phổ biến khi viết truyện kể 🚧

Chuyển sang sử dụng truyện kể không phải là điều xảy ra ngay lập tức. Các đội thường gặp khó khăn với những sai lầm phổ biến làm suy yếu quy trình.

1. Câu chuyện kiểu “Là một nhà phát triển”

Đây là một lỗi phổ biến. Viết một câu chuyện như ‘Là một nhà phát triển, tôi muốn tái cấu trúc cơ sở dữ liệu’ là một nhiệm vụ kỹ thuật, chứ không phải là một câu chuyện người dùng. Dù nợ kỹ thuật là có thật, nhưng nó cần được trình bày dưới góc độ giá trị. ‘Là một hệ thống, tôi muốn tối ưu hóa truy vấn để thời gian tải người dùng giảm đi.’ Nếu giá trị không rõ ràng với doanh nghiệp, công việc này có thể bị ưu tiên thấp hơn.

2. Bẫy Epic

Epic là những khối công việc lớn kéo dài qua nhiều lần lặp. Chúng cần thiết để theo dõi các sáng kiến lớn. Tuy nhiên, đừng nhầm Epic với một câu chuyện. Epic là tập hợp nhiều câu chuyện. Đừng cố gắng ước lượng một Epic như thể nó là một câu chuyện duy nhất. Hãy chia nhỏ nó.

3. Bỏ qua yếu tố ‘Tại sao’

Nếu bạn viết ra ‘Cái gì’ nhưng quên ‘Tại sao’, đội sẽ xây dựng sai thứ. Kỹ sư cần hiểu rõ vấn đề để tìm ra giải pháp tốt nhất. Không có ‘Tại sao’, họ có thể xây dựng một giải pháp kỹ thuật vượt trội nhưng lại không giải quyết được vấn đề nào cho ai.

4. Quá độ kỹ thuật hóa định nghĩa

Đừng viết một tiểu thuyết cho mỗi câu chuyện. Nếu một câu chuyện quá phức tạp, nó cần được chia nhỏ. Mục tiêu là sự rõ ràng, chứ không phải sự đầy đủ trong tài liệu. Cuộc trò chuyện chính là tài liệu. Văn bản viết ra chỉ là lời nhắc về cuộc trò chuyện đó.

Hợp tác vượt lên trên tài liệu 🤝

Một trong những hiểu lầm lớn nhất về câu chuyện người dùng là chúng là tài liệu. Chúng không phải vậy. Chúng là lời mời để bắt đầu cuộc trò chuyện. Giá trị nằm ở cuộc thảo luận 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à cuộc trò chuyện ‘Ba Người Bạn’. Trước khi một câu chuyện bước vào sprint, ba vai trò này nên cùng xem xét nó.

• Người sở hữu sản phẩm:Làm rõ giá trị kinh doanh và các yêu cầu.
• Nhà phát triển:Xác định các giới hạn kỹ thuật và chi tiết triển khai.
• Người kiểm thử:Xác định các trường hợp biên và tiêu chí chấp nhận.

Khi bạn viết tính năng, sự hợp tác này thường xảy ra quá muộn, sau khi mã đã được viết. Khi bạn viết câu chuyện, sự hợp tác này diễn ra trước khi công việc bắt đầu, giúp tiết kiệm thời gian và công sức sửa chữa.

Ưu tiên và giá trị 📈

Câu chuyện người dùng giúp việc ưu tiên dễ dàng hơn. Vì mỗi câu chuyện đều liên quan đến một giá trị cụ thể cho người dùng, nên việc xếp hạng chúng trở nên dễ dàng hơn. Bạn có thể đặt câu hỏi: ‘Câu chuyện nào mang lại giá trị lớn nhất cho người dùng ngay lúc này?’

Danh sách tính năng thường ưu tiên dựa trên độ khó hoặc nợ kỹ thuật. Câu chuyện người dùng ưu tiên dựa trên tác động. Sự đồng bộ này đảm bảo rằng đội luôn làm việc trên những việc quan trọng nhất.

Sử dụng các kỹ thuật như MoSCoW (Phải có, Nên có, Có thể có, Không có) hoặc WSJF (Job đầu tiên có trọng số ngắn nhất) để xếp hạng câu chuyện của bạn. Những phương pháp này dựa vào định nghĩa rõ ràng về giá trị được cung cấp bởi định dạng câu chuyện.

Xử lý yêu cầu kỹ thuật 🛠️

Còn những nhiệm vụ không ảnh hưởng trực tiếp đến người dùng thì sao? Nợ kỹ thuật, nâng cấp hạ tầng và bản vá bảo mật là công việc thực sự. Chúng thường không phù hợp với mẫu “Như một người dùng”.

Bạn có hai lựa chọn cho những mục này.

1. Định dạng chúng thành Câu chuyện Hệ thống: “Như một hệ thống, tôi muốn giảm độ trễ để ứng dụng duy trì ổn định dưới tải.”
2. Sử dụng các Câu chuyện Khảo sát Kỹ thuật: Nếu giá trị chưa rõ, hãy tạo một câu chuyện khảo sát có thời gian giới hạn để tìm hiểu đủ thông tin nhằm ước lượng công việc thực tế.

Không bao giờ giấu công việc kỹ thuật bên trong một câu chuyện người dùng mà không giải thích lợi ích. Nếu đội không hiểu lợi ích, họ sẽ coi công việc đó là gánh nặng không cần thiết.

Chuyển đổi Văn hóa Đội Nhóm của Bạn 🔄

Chuyển từ tính năng sang câu chuyện là một thay đổi văn hóa. Nó đòi hỏi sự tin tưởng. Bạn phải tin tưởng đội của mình hiểu người dùng. Bạn phải tin tưởng người dùng sẽ cung cấp phản hồi.

Bắt đầu nhỏ. Chọn một sprint sắp tới và yêu cầu tất cả các mục phải được viết dưới dạng câu chuyện người dùng. Tổ chức buổi đào tạo để giải thích lý do ‘Tại sao’. Khuyến khích đội hỏi câu hỏi nếu một câu chuyện không rõ ràng.

Theo dõi kết quả. Đo tốc độ giao hàng. Đo mức độ hài lòng của người dùng. Khi đội thấy rằng câu chuyện dẫn đến kết quả tốt hơn, việc áp dụng sẽ trở nên tự nhiên.

Đo lường Thành công 📊

Làm sao bạn biết phương pháp này đang hoạt động? Hãy tìm những dấu hiệu sau:

• Giảm công việc phải làm lại: Ít lỗi và hiểu lầm hơn có nghĩa là ít thời gian hơn để sửa lỗi.
• Chuẩn bị nhanh hơn:Các thành viên mới trong nhóm hiểu sản phẩm tốt hơn khi các câu chuyện giải thích được giá trị.
• Giao tiếp với các bên liên quan tốt hơn:Các bên liên quan quan tâm hơn khi họ thấy giá trị dành cho người dùng thay vì các nhiệm vụ kỹ thuật.
• Tốc độ cao hơn:Với các tiêu chí chấp nhận rõ ràng, đội ngũ làm việc nhanh hơn mà không làm giảm chất lượng.

Nếu bạn thấy những cải tiến này, bạn đã thành công trong việc thay đổi quy trình làm việc của mình. Nếu không, hãy xem lại các tiêu chí chấp nhận và thói quen hợp tác của bạn.

Câu hỏi thường gặp ❓

Tôi vẫn có thể sử dụng danh sách công việc chờ xử lý được không?

Có. Danh sách công việc chờ xử lý đơn giản chỉ là một danh sách các công việc. Bạn có thể có một danh sách công việc chờ xử lý gồm các câu chuyện người dùng. Thực tế, danh sách công việc chờ xử lý gồm các câu chuyện người dùng là loại danh sách tốt nhất vì nó được sắp xếp theo giá trị.

Thế nếu tôi không biết người dùng thì sao?

Hãy sử dụng một nhân vật đại diện chung. “Như một khách hàng” là chấp nhận được nếu bạn không có dữ liệu cụ thể. Tuy nhiên, hãy nỗ lực tạo ra các nhân vật đại diện cụ thể khi bạn thu thập dữ liệu. Tính cụ thể sẽ dẫn đến những quyết định tốt hơn.

Liệu điều này chỉ dành cho các đội Agile thôi sao?

Mặc dù phổ biến trong Agile, nguyên tắc này áp dụng được cho bất kỳ phương pháp phát triển nào. Bất kỳ đội nào muốn xây dựng sản phẩm có giá trị đều được lợi khi tập trung vào kết quả người dùng thay vì đầu vào tính năng.

Làm thế nào để xử lý lỗi?

Lỗi thường được viết dưới dạng câu chuyện: “Như một người dùng, tôi không thể lưu dữ liệu của mình, vì vậy tôi muốn hệ thống tự động lưu tiến độ của tôi.” Điều này đặt vấn đề lỗi thành một lời hứa về giá trị bị vi phạm.

Suy nghĩ cuối cùng về giá trị 🌟

Mục tiêu của phát triển phần mềm là giải quyết vấn đề. Tính năng chỉ là công cụ để giải quyết những vấn đề đó. Các câu chuyện người dùng là bản đồ đảm bảo bạn đang sử dụng công cụ đúng cách.

Bằng cách chuyển trọng tâm từ tính năng sang các câu chuyện người dùng, bạn đồng bộ đội nhóm với những người quan trọng nhất: người dùng. Bạn giảm lãng phí, tăng sự rõ ràng và xây dựng những sản phẩm thực sự tạo được tiếng vang.

Bắt đầu ngay hôm nay. Nhìn vào danh sách công việc chờ xử lý hiện tại của bạn. Xác định các tính năng. Viết lại chúng dưới dạng câu chuyện. Hỏi “Tại sao?”. Sự khác biệt bạn thấy sẽ ngay lập tức rõ ràng.