Tài liệu có phải là Câu chuyện của người dùng không? [đóng cửa]

Chúng tôi cần làm một số tài liệu người dùng cho một sản phẩm mà chúng tôi đã làm việc trong vài lần chạy nước rút vừa qua. Chúng tôi hiện đang bắt đầu một dự án mới trong lần chạy nước rút tiếp theo và PO đang tạo tài liệu cho sản phẩm được sản xuất trước đó là câu chuyện Người dùng cho lần chạy nước rút này.

Tôi chỉ tự hỏi ý kiến ​​của bạn về phương pháp này. Cá nhân, tôi không đồng ý rằng tài liệu là Câu chuyện của người dùng trong Scrum vì nó không tạo ra bất kỳ mã nào.

EDIT: Cảm ơn ý kiến ​​của bạn các bạn. Tôi đã nghĩ rằng việc chạy nước rút là triển khai phần mềm làm việc, nhưng quan điểm của bạn đã thay đổi quan điểm của tôi. Cảm ơn bạn cho tất cả các câu trả lời của bạn.

"Là người dùng của X, tôi cần biết X hoạt động như thế nào" dường như là một câu chuyện người dùng hợp pháp đối với tôi. Điều này có thể dẫn đến tài liệu bằng văn bản hoặc trợ giúp trực tuyến.

Điểm không chỉ là mã - nó đáp ứng yêu cầu của người dùng.

Lý tưởng nhất, tài liệu là một phần của mọi câu chuyện của người dùng và không bao giờ được xây dựng. Nhưng, trong thế giới thực, điều đó thường không xảy ra. Trong trường hợp đó, bạn nên tạo một câu chuyện người dùng để bắt kịp một phần tài liệu bị thiếu cụ thể.

Bạn nói đúng, nó không tạo ra bất kỳ mã nào. Nhưng nó đáp ứng yêu cầu của người dùng và nên được ưu tiên so với các yêu cầu khác của người dùng.

Nếu điều này có nghĩa là nó không bao giờ được thực hiện, bởi vì điều này và chức năng đó đang được thực hiện thì có lẽ bạn không cần tài liệu đó quá tệ.

Tôi đồng ý với đánh giá tài liệu của pdr nếu đó là về tài liệu yêu cầu, kỹ thuật hoặc dự án. Lý tưởng nhất là nó nên được kết hợp vào công việc chạy nước rút.

Tài liệu sản phẩm tôi cảm thấy rất khác biệt vì nó là một người dùng thực tế được yêu cầu cung cấp và trực tiếp cung cấp giá trị cho người dùng. Tất nhiên, điều này nên được hiểu rằng Tài liệu sản phẩm về cơ bản không phải là Nhiệm vụ kỹ thuật mà là Nhiệm vụ chức năng và có thể hoặc không phải là một hoạt động phù hợp cho tài nguyên kỹ thuật trong dự án.

Tôi nghĩ đó nên là một câu chuyện của người dùng, tuy nhiên tôi cảm thấy rằng một tài nguyên dự án có hiểu biết vững chắc về các yêu cầu kinh doanh, quan điểm người dùng và kỹ năng viết kỹ thuật tốt nên được giao những nhiệm vụ này. Lý tưởng nhất sẽ là một nhà phân tích kinh doanh nếu có sẵn, hoặc có lẽ là một người kiểm tra QA bậc cao hơn với sự hiểu biết vững chắc về các yêu cầu, câu chuyện của người dùng và kỹ năng viết kỹ thuật tốt. Đây cũng có thể là một nhà phát triển, tuy nhiên tài liệu sản phẩm được viết bởi các nhà phát triển có xu hướng không có chất lượng cao hoặc hữu ích vì các nhà phát triển thường quá gần với các chi tiết kỹ thuật.

Trong tổ chức của chúng tôi, nhóm công cụ, chịu trách nhiệm duy trì và tăng cường hệ thống tích hợp liên tục của chúng tôi đang sử dụng Scrum để giúp họ quản lý công việc. Tuy nhiên, họ không viết mã nhưng họ đang thực hành Scrum.

Để trả lời câu hỏi của bạn một cách cụ thể, tôi sẽ hỏi liệu nhóm có cho rằng tài liệu đó là một phần của "Định nghĩa Hoàn thành" hay không.

Nếu nhóm cho rằng tài liệu là một phần của "định nghĩa hoàn thành" thì không cần câu chuyện bổ sung và câu chuyện không thể được chấp nhận trừ khi tài liệu được viết và xác nhận.

Nếu nhóm cho rằng tài liệu không phải là một phần của "định nghĩa hoàn thành", tôi sẽ tạo một câu chuyện riêng để Chủ sở hữu sản phẩm có thể quản lý công việc của họ.