Làm cách nào để xử lý các khía cạnh ứng dụng liên quan đến các tính năng và câu chuyện của người dùng?

Khi vẽ một hồ sơ tồn đọng, tôi có một số yêu cầu áp dụng cho rất nhiều câu chuyện của người dùng, tức là các khía cạnh của ứng dụng như xử lý lỗi và phản hồi. Làm cách nào để bao gồm những điều này (không sử dụng lệnh #incoide trong mỗi câu chuyện của người dùng)? Tôi có nên coi trình bày lỗi là một tính năng, sau đó có các câu chuyện của người dùng cho tính năng này như "hệ thống bắt ngoại lệ và hiển thị thông tin cho người dùng" không?

Xử lý phản hồi của người dùng rất quan trọng đối với trải nghiệm người dùng, nhưng cũng áp dụng cho các phần khác nhau của ứng dụng theo những cách khác nhau.

Lấy hai ví dụ sau:

Một câu chuyện có thể tập trung vào tương tác người dùng trực tiếp trong đó xảy ra lỗi nghiêm trọng. Một hộp thoại phương thức được sử dụng để thông báo cho người dùng về lỗi và thông báo rằng không thể khôi phục. Câu chuyện cho điều này sẽ là: "Là người dùng tôi muốn được thông báo về việc nhập không hợp lệ một số dạng dữ liệu để tôi có thể quay lại và sửa lỗi này ngay lập tức" . Câu chuyện người dùng này ngụ ý rằng đây là lỗi chặn nghiêm trọng mà người dùng cần khắc phục ngay lập tức.

Trong câu chuyện thứ hai , người dùng quên nhập dữ liệu bắt buộc vào một biểu mẫu. Câu chuyện sẽ là: "Là người dùng, tôi muốn các trường bị thiếu trong một mục được tô sáng để tôi biết các trường bắt buộc là gì."

Thông báo tinh tế này rất khác nhau và không thể kết hợp với câu chuyện đầu tiên thành một câu chuyện xử lý lỗi chung. Tuy nhiên, cả hai có thể phát sinh từ ngoại lệ nội bộ.

Hãy nhớ rằng điều quan trọng là truyền đạt "cái gì" của một câu chuyện, vì vậy, ví dụ như kịch bản lỗi cần được xử lý trong một tình huống cụ thể. Cách thức xảy ra lỗi (tức là một ngoại lệ đang bị ném ở đâu đó) gần như không liên quan đến chủ sở hữu sản phẩm vì nó không có giá trị kinh doanh. Từ quan điểm kỹ thuật có kiến ​​trúc âm thanh là điều tôi mong đợi từ sản phẩm của mình dưới bất kỳ hình thức nào.

Cuối cùng, bạn sẽ có được sự linh hoạt và khả năng mở rộng bằng cách tập trung vào giá trị doanh nghiệp và có những câu chuyện người dùng nhỏ và tách biệt .

Tôi tin rằng giải pháp là sự phân tách tốt các mối quan tâm. Những việc như xử lý lỗi, ghi nhật ký, phản hồi và những thứ đó nên được xử lý trên toàn cầu chỉ với một đoạn mã. Chỉ các yêu cầu, khác với hành vi toàn cầu này nên được lưu ý là một phần của câu chuyện người dùng hoặc trong cuộc thảo luận về việc triển khai câu chuyện người dùng đã nói.

Vì vậy, từ phía quản lý dự án, cần có một Câu chuyện người dùng có nội dung "Là người dùng tôi muốn thấy lỗi theo cách như vậy, cho phép tôi báo cáo với quản trị viên." hoặc điều tương tự. Và câu chuyện người dùng này nên áp dụng như một quy tắc toàn cầu cho tất cả các trường hợp sử dụng.

Một ý tưởng (lấy từ SCRUM): Những điều cần kiểm tra cho mọi câu chuyện của người dùng được đưa vào cái gọi là "định nghĩa hoàn thành" .

Thông thường "định nghĩa hoàn thành" bao gồm những thứ kỹ thuật, như:

• tất cả các bài kiểm tra là màu xanh lá cây
• mã sạch hợp lý
• mã gây ra không hồi quy

Nhưng nó cũng có thể bao gồm những thứ người dùng có thể nhìn thấy:

• không có thao tác người dùng nào mất hơn một giây, hoặc
• tất cả các điều khiển GUI có thể được sử dụng chỉ với bàn phím

Nhóm phải kiểm tra "định nghĩa hoàn thành" cho mọi câu chuyện của người dùng trước khi họ tuyên bố hoàn thành.

Một lựa chọn sẽ là bao gồm xử lý lỗi thích hợp vào "định nghĩa hoàn thành" này. Tuy nhiên, như các câu trả lời khác chỉ ra, các ví dụ bạn trích dẫn (lỗi và phản hồi) thực sự có thể không phải là ví dụ thực sự tốt cho các yêu cầu áp dụng "ở mọi nơi":

Xử lý lỗi và phản hồi đúng cách thường phụ thuộc vào ngữ cảnh, do đó, nó cần được xác định riêng cho những nơi cần thiết. Vì vậy, trong trường hợp này, có thể tốt hơn để hình thành xử lý lỗi dưới dạng các câu chuyện người dùng riêng biệt, như được giải thích bằng câu trả lời của malte.