Nhiều câu chuyện của người dùng chia sẻ cùng một nhiệm vụ kỹ thuật: phải làm gì?

Giới thiệu một chút về trường hợp của tôi:

Là một phần của sản phẩm lớn hơn, nhóm của tôi được yêu cầu hiện thực hóa một IDE nhỏ cho DSL. Người dùng sản phẩm này sẽ có thể thực hiện các cuộc gọi chức năng trong mã và chúng tôi cũng được yêu cầu cung cấp một số thư viện chức năng hữu ích. Nhóm, cùng với PO, đưa lên tường một số câu chuyện người dùng nhất định liên quan đến các thư viện khác nhau cho người dùng IDE. Khi ước tính câu chuyện đầu tiên, nhóm đã quyết định rằng cơ chế gọi hàm sẽ là một nhiệm vụ hấp dẫn nhưng không hoàn toàn rõ ràng, vì vậy ước tính cho câu chuyện người dùng đó đã tăng từ 3 đơn giản lên 5 nguy hiểm hơn.

Đến với vấn đề:

Sau đó, nhóm chuyển sang các câu chuyện của người dùng liên quan đến các thư viện khác, thực tế là 10 câu chuyện và thêm 2 điểm " cơ chế gọi chức năng " vào mỗi câu chuyện của người dùng đó. Điều này ngay lập tức nâng tổng số điểm cho sản phẩm 20 điểm! Mọi người trong nhóm đều biết rằng mỗi câu chuyện của người dùng có thể được PO chọn cho lần lặp tiếp theo bất cứ lúc nào, vì vậy chúng tôi không nên cách ly phần đó trong một câu chuyện của người dùng, nhưng 20 điểm đó cảm thấy vô cùng phi thực tế!

Tôi đã đề xuất một giải pháp, nhưng tôi hoàn toàn không hài lòng:

Chúng tôi đã tạo ra một "Câu chuyện thiết kế" và đặt 2 điểm khó chịu lên trên nó. Tuy nhiên, khi chúng tôi nhận ra và chứng minh điều đó với khách hàng của mình, chúng tôi không thể hiển thị điều gì đó thực sự có giá trị cho họ về câu chuyện đó!

Vấn đề ở đây là liệu chúng ta có nên bỏ qua nguyên tắc có các câu chuyện người dùng bị cô lập (không có bất kỳ sự phụ thuộc nào giữa chúng).

Bạn sẽ làm gì, hoặc thậm chí tốt hơn những gì bạn đã làm, trong những tình huống như thế này?

(một ghi chú nhỏ: theo gợi ý tôi đã chuyển câu hỏi này từ stackoverflow)

Nếu bạn cần ước tính một số câu chuyện của người dùng có một số yếu tố chung, nhưng bạn chưa biết những câu chuyện này sẽ được thực hiện theo thứ tự nào, thì tôi sẽ chia các nhiệm vụ tạo thành mỗi câu chuyện thành ba nhóm:

1. Các tác vụ thông thường, cần một lần : Các tác vụ xảy ra cho nhiều câu chuyện, nhưng chỉ thực sự được thực hiện một lần cho câu chuyện đầu tiên. Các cơ chế gọi chức năng được đề cập có thể sẽ nằm trong thể loại này.
2. Các tác vụ phổ biến, lặp đi lặp lại : Các tác vụ xảy ra trong nhiều câu chuyện và phải được thực hiện một lần nữa cho mỗi câu chuyện.
3. Nhiệm vụ cụ thể : Nhiệm vụ cụ thể cho một câu chuyện cụ thể.

Sau đó, bạn ước tính từng nhiệm vụ, trong đó các nhiệm vụ chung chỉ nên được ước tính một lần.

Trong phần trình bày cho khách hàng / PO, tôi sẽ đưa ra hai ước tính cho mỗi câu chuyện: Một với tất cả các nhiệm vụ "chung, cần một lần" được bao gồm và một với chúng bị loại trừ.
Chỉ cần giữ một kế toán chi tiết của các nhiệm vụ, phân loại và ước tính của họ trong tay nếu khách hàng muốn thông tin chi tiết hơn về sự khác biệt giữa các ước tính. Bản thân các nhiệm vụ không thể thương lượng, nhưng biết về chúng có thể giúp khách hàng / PO, đặc biệt nếu tập hợp các nhiệm vụ chung không giống nhau cho mỗi câu chuyện.

Tại sao phần mềm là khó.

Chúng tôi đã tạo ra một "Câu chuyện thiết kế" và đặt 2 điểm khó chịu lên trên nó. Tuy nhiên, khi chúng tôi nhận ra và chứng minh điều đó với khách hàng của mình, chúng tôi không thể hiển thị điều gì đó thực sự có giá trị cho họ về câu chuyện đó!

Chính xác. Câu chuyện người dùng đơn giản SCRUM là đơn giản. Đôi khi, phần mềm thực sự đủ phức tạp để phương pháp đơn giản không hoạt động. Điều này không nên đến như bất kỳ loại bất ngờ.

Vấn đề ở đây là liệu chúng ta có nên bỏ qua nguyên tắc có các câu chuyện người dùng bị cô lập (không có bất kỳ sự phụ thuộc nào giữa chúng).

Lựa chọn của bạn là gì? Quá giá mỗi câu chuyện người dùng vì mỗi người có một chi phí một lần ẩn? Điều đó cũng ngớ ngẩn không kém.

Đúng. Bạn phải bước ra khỏi sự đơn giản.

Bạn sẽ làm gì, hoặc thậm chí tốt hơn những gì bạn đã làm, trong những tình huống như thế này?

Bước ra khỏi sự đơn giản. Có những khoản đầu tư một lần làm cho một nhóm các câu chuyện ít tốn kém hơn. Bạn phải thực sự nói chuyện với mọi người về kiến ​​trúc thay vì giả vờ rằng sự tương tác duy nhất của bạn là một danh sách các câu chuyện sẽ được xây dựng.

Agile có nghĩa là bạn phải thực sự nói chuyện với PO và khách hàng.

Agile có nghĩa là một quy trình đơn giản không thể - và sẽ không - hoạt động.

Bạn biết rằng bạn chỉ phải thực hiện công việc làm thêm một lần, do đó, việc đưa cùng một công việc làm thêm vào 5 câu chuyện không có ý nghĩa gì. Nếu bạn không muốn một câu chuyện thiết kế mà người dùng không thể nhìn thấy, thì điều tốt nhất nên làm là tiếp tục, ngay bây giờ và chọn một trong những điều phụ thuộc vào công việc thiết kế đó và nói rằng đó phải là đầu tiên và thêm những điểm đó vào đó. Ghi chú về những câu chuyện khác mà chúng phải đến sau, và nếu vì lý do nào đó, bạn thay đổi suy nghĩ, bạn luôn có thể di chuyển các điểm xung quanh.