Câu chuyện của người dùng là gì và không phải là gì?

Question

Tôi gặp vấn đề tại nơi làm việc, nơi chúng tôi mới bắt đầu sử dụng scrum như một nhóm phát triển. Tôi đang gặp một số rắc rối với những câu chuyện của người dùng mà chúng tôi được cung cấp trong đó họ dường như không phù hợp với những gì tôi giải thích về câu chuyện của người dùng.

Dưới đây là một ví dụ thực tế trong những câu chuyện người sử dụng, chúng tôi đã được trao cho chạy nước rút này:

• Là một người sử dụng trang web tôi muốn có một trang đăng ký để tôi có thể đăng ký và cung cấp thông tin chi tiết của tôi.

• Là người dùng người bán, tôi muốn có xác thực trên biểu mẫu đăng ký để tôi cung cấp thông tin chính xác. (Điều này liên quan đến Xác thực biểu mẫu)

• Là người dùng người bán, tôi muốn hỗ trợ khi đăng ký để mọi câu hỏi mà tôi có về các chi tiết bắt buộc được trả lời. (Điều này liên quan đến Công cụ lời khuyên về hình thức)

Người đầu tiên trong tâm trí của tôi là câu chuyện người dùng. Thứ hai có vẻ là yêu cầu truyền thống của câu chuyện người dùng đầu tiên và tôi nghĩ rằng có lẽ họ nên là tiêu chí chấp nhận của câu chuyện người dùng đầu tiên.

Sự rắc rối khác mà tôi có là trong chạy nước rút cuối cùng chúng tôi đã có:

• Là một người sử dụng tôi muốn để có thể đăng nhập vào trang web.

• Là người dùng tôi muốn có thể đăng nhập vào trang web bằng tên người dùng.

Chủ sở hữu sản phẩm cho biết đây là hai câu chuyện người dùng khác nhau cần được kiểm tra riêng.

Vấn đề của tôi là trong việc tạo ra các trường hợp thử nghiệm và tiêu chí chấp nhận cho hai trường hợp thứ hai - rất khó vì chúng quá cụ thể và liên quan đến câu chuyện của người dùng đầu tiên. Có vẻ như chúng tôi đang đưa ra các yêu cầu truyền thống về một thẻ lên bảng và gọi nó là cái gì đó khác. Tôi chủ yếu chỉ muốn biết nếu tôi sai về điều này/tại sao? Có vẻ như với tôi rằng chúng tôi hiện chỉ cho phép người dùng tạo bất kỳ thứ gì họ muốn làm câu chuyện của người dùng và không giúp họ lọc chúng khỏi yêu cầu thành câu chuyện phù hợp của người dùng. Tôi nói rằng chúng ta cần phải giữ chúng riêng biệt để báo cáo để chúng tôi có thể giữ một bản ghi mọi thứ mà người dùng yêu cầu.

Answer 1

Câu chuyện của người dùng tập trung vào giá trị khách hàng. ... Các công việc thực tế đang được thực hiện là thịt ra thông qua sự cộng tác xoay quanh câu chuyện của người dùng khi hệ thống tiến triển phát triển. ... Để giới hạn phạm vi, các câu chuyện của người dùng có các tiêu chí chấp nhận được phát triển cộng tác xác định khi câu chuyện của người dùng đáp ứng các kỳ vọng của các bên liên quan. Các trường hợp kiểm tra thường là được phát triển dưới dạng mã (với sự phát triển theo thử nghiệm) hoặc được ghi thành mã được phát triển.

[Mỏ nhấn mạnh.]

Là người dùng tôi muốn có thể đăng nhập vào trang web.

Là người dùng tôi muốn có thể đăng nhập vào trang web bằng tên người dùng.

Kể từ khi không cung cấp bất kỳ giá trị khách hàng, không phải là những câu chuyện người dùng.

Bạn sử dụng phần mềm ứng dụng để quản lý thông tin, đưa ra quyết định và (cuối cùng) thực hiện hành động. Nếu câu chuyện của người dùng không cung cấp một số gợi ý về thông tin, quyết định hoặc hành động nào được thực hiện, thì không có giá trị khách hàng, đó chỉ là chi tiết triển khai về thư mục kỹ thuật mà khách hàng phải chịu đựng để đến phần thú vị của ứng dụng.

Đăng nhập, cụ thể, không có số giá trị khách hàng. Đó là một rào cản mà CNTT xây dựng giữa khách hàng và thông tin giá trị mà họ cần để đưa ra quyết định và hành động. Đó là một cơ chế bảo mật và hầu hết mọi người không thực sự thích bảo mật. Bảo mật được áp dụng cho khách hàng bởi CNTT. Mật khẩu phổ biến nhất (IIRC) là "aaaaaaaa". Tại sao? Khách hàng không thích bảo mật.

Chi tiết, vi mô đăng nhập câu chuyện của người dùng có thể là một triệu chứng không nhìn thấy giá trị thực cho khách hàng.

---

Nó chỉ có vẻ với tôi rằng chúng tôi đang chỉ cho phép các người dùng tạo bất cứ điều gì họ muốn là một câu chuyện sử dụng

Tốt.

Tôi được thông báo rằng chúng tôi cần giữ riêng tất cả các báo cáo để chúng tôi có thể lưu nhật ký mọi thứ mà người dùng yêu cầu.

Không phải là một kế hoạch xấu.

Vấn đề là tách "sự cố người dùng đã nói" từ "nội dung có ý nghĩa mà chúng tôi có thể tạo". Nó rất, rất quan trọng để cho phép người dùng nói bất kỳ crap họ muốn nói. Đó là một điều tốt để cho họ đổ xô.

Định kỳ (trước mỗi lần chạy nước rút), bạn sẽ ưu tiên một số thứ mà bạn có thể xây dựng trong lần chạy nước rút, và (2) tạo giá trị người dùng quan trọng và ấn tượng nhất mà bạn có thể tạo nên. Một số câu chuyện sẽ bị bỏ qua. Một số sẽ được ưu tiên thấp. Một số sẽ được kết hợp và một số sẽ được tách ra. Một số điều người dùng nói sẽ mâu thuẫn. Một số sẽ là hoàn toàn dối trá. Một số sẽ không đầy đủ. Tất cả đều tốt. Nó chỉ là crap người dùng đã xảy ra để nói. Không phải chỉ thị thiêng liêng từ miệng của các vị thần trực tiếp cho bạn.

Tập hợp câu chuyện người dùng đã sửa đổi này thúc đẩy chạy nước rút. Giờ đây, bạn bắt đầu cộng tác với người dùng để có được thông tin chi tiết, viết các trường hợp kiểm tra, xác định sự chấp nhận, v.v.

Khi bạn đang chạy nước rút về phía giao hàng, người dùng có thể tiếp tục nói rằng nó sẽ được thêm vào các câu chuyện của người dùng chưa được thực hiện. Nó rất, rất quan trọng để cho phép người dùng nói bất kỳ crap họ muốn nói. Đó là một điều tốt để cho họ đổ xô.