Làm cách nào để xử lý một câu chuyện người dùng mà tôi hoàn thành, nhưng với sự thỏa hiệp và cần xem lại?

Tôi vừa hoàn thành (đó có phải là một thuật ngữ tốt không?) Hai câu chuyện của người dùng trong một dự án tồn đọng mới mà tôi vừa xây dựng. Đây là đăng ký người dùng và đặt lại mật khẩu, cả hai đều yêu cầu thư. Tôi cần triển khai một thành phần thư thay thế bởi vì lựa chọn ban đầu của tôi và một thành phần đáng tin cậy thông thường, không hoạt động. Vì tôi tập trung vào việc phân phối các câu chuyện của người dùng, không gỡ lỗi thành phần thư, tôi đã trao đổi nó để cung cấp mã làm việc ở giai đoạn nước rút. Bây giờ tôi có đăng nhập một vấn đề hỗ trợ mới cho người gửi thư hay 'chèn lại' những câu chuyện này vào hồ sơ tồn đọng không? Nếu tôi làm sau, tôi có không giới thiệu quá nhiều chi tiết công nghệ vào câu chuyện của người dùng không?

Nếu bạn triển khai câu chuyện người dùng theo các tiêu chuẩn được xác định trong định nghĩa hoàn thành, thì những câu chuyện người dùng đó đã kết thúc và không nên đưa vào hồ sơ tồn đọng của sản phẩm.

Trong những tình huống tương tự, tôi đã nêu ra một câu chuyện người dùng mới, nhưng đã mô tả yêu cầu thực hiện thay đổi kỹ thuật về lợi ích kinh doanh của nó, thay vì có một cái gì đó hoàn toàn là kỹ thuật trong sản phẩm tồn đọng. Làm thế nào về:

"Là một nhà phát triển, tôi muốn sản phẩm sử dụng thành phần email tiêu chuẩn của công ty để việc hỗ trợ và bảo trì được đơn giản hóa."

Là một nhà phát triển, bạn cũng là một diễn viên và bạn có thể có các yêu cầu mà hệ thống hành xử theo một cách cụ thể khi bạn sử dụng (hỗ trợ / thay đổi) nó. Luôn luôn có thể nói rõ những điều này về lợi ích kinh doanh của họ và ưu tiên chúng với chủ sở hữu sản phẩm của bạn cùng với việc triển khai chức năng mới.

Nếu định nghĩa được thực hiện cho câu chuyện người dùng được điền đầy đủ (đầy đủ, mọi thứ bạn muốn gọi đã hoàn thành) thì cửa hàng người dùng của bạn đã hoàn tất và bạn không nên đưa nó vào phần tồn đọng.

Tuy nhiên, bạn đã mắc nợ kỹ thuật để hoàn thành việc đó và sau này bạn cần dành thời gian khác để khắc phục điều đó. Vì vậy, có vẻ với tôi rằng bạn cần một loại nhiệm vụ cho công việc nội bộ, chẳng hạn như các nhà tái cấu trúc.

Vì vậy, thêm một vấn đề mới vào backlog.

Nợ kỹ thuật chỉ là một câu chuyện khác

Nếu một câu chuyện được thực hiện có nghĩa là nó đã vượt qua QA và được Chủ sở hữu sản phẩm chấp nhận.

Bất kỳ công việc nào có thể cần phải được thực hiện để "dọn dẹp" hoặc "cải thiện" việc triển khai đều được coi là Nợ kỹ thuật và chỉ đơn giản là một Câu chuyện mới.

Bằng cách đó, nó sẽ được Chủ sở hữu sản phẩm theo dõi và ưu tiên giống như mọi thứ khác.

Điều đơn giản nhất sẽ làm việc hợp lý

Trong một bình luận liên quan , OP nói:

'Cách giải quyết' của tôi là một giải pháp chất lượng, nhưng việc triển khai dự kiến ​​ban đầu sẽ là một cải tiến cho cách giải quyết, vì vậy tôi có thể tạo một câu chuyện mới để cải thiện chức năng email không?

Nếu đó là trường hợp, câu hỏi ban đầu là moot. Các nguyên tắc YAGNI đòi hỏi một giải pháp không thể qua chế với dự đoán của các yêu cầu trong tương lai.

Nếu một giải pháp đáp ứng các mục tiêu chạy nước rút hiện tại, các chức năng như được thiết kế và đáp ứng "định nghĩa hoàn thành" của nhóm, thì nó đã được thực hiện. Nó không hoàn thành một nửa, sắp xếp xong hoặc "hoàn thành trong khi chờ tái cấu trúc theo kế hoạch."

Đánh dấu nó xong và tiếp tục.

Caveat nhỏ

Nếu bạn thực sự nghĩ rằng có một câu chuyện khác ở đó, hoặc một loại nợ kỹ thuật nào đó không ngăn được câu chuyện gốc được thực hiện, thì bạn nên nêu một câu chuyện khác cho Product Backlog .

Tác phẩm mới luôn cần được đặt trên Product Backlog để nâng cao khả năng hiển thị-- không bao giờ có tác phẩm vô hình! Cuối cùng, công việc của Chủ sở hữu sản phẩm là quyết định xem cải tiến được đề xuất có phù hợp với mục tiêu sản phẩm hay không và ưu tiên câu chuyện người dùng mới của bạn trong Product Backlog nếu anh ấy chọn thêm câu chuyện.

Theo câu hỏi của bạn và nhận xét bổ sung cho câu trả lời của @ Klee, tôi nghĩ rằng vấn đề hơi khác một chút.

Bạn đã hoàn thành một câu chuyện. Điều đó có nghĩa là bạn đã thông qua tất cả các định nghĩa về việc đã hoàn thành - nếu không thì câu chuyện của người dùng không thể được coi là đã hoàn thành. Nhưng nếu bạn đã hoàn thành câu chuyện và thông qua tất cả các định nghĩa về việc thực hiện thì điều đó có nghĩa là giải pháp hiện tại của bạn đang thỏa mãn. Mặt khác, chủ sở hữu khách hàng / sản phẩm phải nêu lý do tại sao nó không thỏa mãn (không phải bạn) và từ chối hoàn thành của bạn hoặc xác định câu chuyện người dùng khác mở rộng câu chuyện này với định nghĩa mới được thực hiện mà giải pháp hiện tại của bạn không hài lòng.

Nợ kỹ thuật chỉ được tăng khi giải pháp hiện tại của bạn không đáp ứng một số yêu cầu hoặc ràng buộc. Có bất kỳ ràng buộc nào bạn đã vi phạm bằng cách sử dụng một cách giải quyết không? Nếu có, bạn không nên đánh dấu câu chuyện người dùng của bạn là hoàn thành ở nơi đầu tiên.

Có bất kỳ sao chép mã hoặc thực hành xấu khác được giới thiệu bởi cách giải quyết của bạn? Sau đó, bạn đã tạo ra nợ kỹ thuật và bạn nên giải quyết nó càng sớm càng tốt. Bạn có thể công bằng với chủ sở hữu sản phẩm và chỉ cần nói với anh ta rằng trong lần chạy nước rút tiếp theo, bạn phải dành thời gian để khắc phục các sự cố kỹ thuật của mình, điều này sẽ dẫn đến các câu chuyện người dùng ít kế hoạch hơn. Hoặc nếu mối quan hệ của bạn với chủ sở hữu sản phẩm không tốt lắm chỉ đơn giản là lập kế hoạch cho các câu chuyện của người dùng ít hơn vì sự phức tạp "mới được phát hiện" trong bất kỳ vấn đề nào và khắc phục nợ kỹ thuật của bạn.

Nếu không có sự trùng lặp mã hoặc bất kỳ lý do thực sự nào khiến mã của bạn được cải thiện chỉ đơn giản là đừng chạm vào nó. Vì lý do thực tế, tôi có nghĩa là không có ràng buộc nào được xác định bởi chủ sở hữu khách hàng / sản phẩm (ví dụ: chính sách của công ty, hiệu suất, thời gian được xác định trước để tạo mẫu email mới không thể đạt được với giải pháp hiện tại của bạn, v.v.). Không có nợ kỹ thuật trong mã của bạn. Những gì bạn đang cố gắng được gọi là mạ vàng - cung cấp các tính năng không bắt buộc = lãng phí tài nguyên của khách hàng.

Nếu giải pháp của bạn sẽ không thỏa mãn bất kỳ câu chuyện người dùng nào trong tương lai, chỉ cần chuyển cấu trúc lại và cải thiện mã của bạn sang câu chuyện người dùng đó. Nó không phải được giải quyết ngay bây giờ vì nó đã vượt qua định nghĩa hiện tại về việc đã hoàn thành. Xử lý các cải tiến khi chúng phải được thực hiện để vượt qua định nghĩa được thực hiện cho các câu chuyện mới được thực hiện và để tránh các thực tiễn xấu.