Làm thế nào để đối phó với những câu chuyện chia sẻ chức năng

Tôi có hai câu chuyện (tôi biết họ đang thiếu phần lợi ích)

1. Là người dùng quản lý tín dụng, tôi có thể xem sự khác biệt về bảng lương hiện tại và trước đây cho Văn phòng.
2. Là Người dùng Quản lý Tín dụng, tôi có thể nhận được email có chứa bản PDF về chênh lệch bảng lương hiện tại và trước đây cho Văn phòng.

Hai cái này có liên quan ở chỗ chúng sẽ có cùng tiêu chí Truy vấn / Bộ lọc. Sự khác biệt duy nhất là trong câu chuyện "Xem", kết quả được hiển thị cho Người dùng và trong câu chuyện "Email", kết quả được ghi vào tệp PDF được gửi qua email cho Người dùng.

Tôi đang vật lộn với sự tách biệt các khía cạnh chung của hai câu chuyện này hoặc nếu tôi thậm chí nên làm như vậy.

Ví dụ, cả hai sẽ có cùng một truy vấn, những gì họ làm với kết quả là khác nhau.

Tôi có nên tách truy vấn ra thành một câu chuyện hoàn toàn là kỹ thuật không?

Việc tạo PDF và gửi email nên được thực hiện ngoại tuyến, điều đó có nên trở thành một câu chuyện kỹ thuật không?

Tôi có thể thấy việc chia hai câu chuyện đó thành 2 câu chuyện chức năng và 2 câu chuyện kỹ thuật.

1. Là Hệ thống, tôi có thể tính toán sự khác biệt trong bảng lương hiện tại và trước đây cho Văn phòng.

2. Là người dùng quản lý tín dụng, tôi có thể xem sự khác biệt trong bảng lương hiện tại và trước đây cho Văn phòng.

3. Với tư cách là Hệ thống, tôi có thể tạo một tài liệu PDF về sự khác biệt trong bảng lương hiện tại và trước đây cho Văn phòng.

4. Là Người dùng Quản lý Tín dụng, tôi có thể yêu cầu nhận email có chứa bản PDF về sự khác biệt trong bảng lương hiện tại và trước đây cho Văn phòng.

Vấn đề tôi tiếp tục quay trở lại là 4 câu chuyện không độc lập và không "cắt bánh".

Vì vậy, tôi không chắc chắn làm thế nào để đối phó với hai.

Câu chuyện của người dùng không phải là thông số kỹ thuật hệ thống hoặc yêu cầu chức năng. Thay vào đó, họ là khởi đầu của một cuộc trò chuyện có thể dẫn đến các thông số kỹ thuật hoặc yêu cầu như vậy.

Theo đó, tôi hy vọng sẽ có sự chồng chéo trong việc thực hiện hệ thống. Câu chuyện của người dùng không có nghĩa là để mô tả chức năng chồng chéo như vậy hoặc để loại bỏ nó. Mục đích của Câu chuyện người dùng là nắm bắt các kỳ vọng chức năng từ quan điểm của người dùng, không mô tả chi tiết triển khai.

Đừng: Thử và chia các câu chuyện, Thực hiện một câu chuyện và sau đó là câu chuyện khác.

Nên: Đảm bảo nhóm dev nhận thức được câu chuyện thứ hai.

Vấn đề với việc cố gắng lên kế hoạch cho các nhiệm vụ chi tiết và tạo ra một mô hình chung có thể xử lý cả hai một cách tao nhã là nó khó.

Mục đích của câu chuyện người dùng là để hoàn thành công việc. Thanh lịch là một mục tiêu thứ yếu và nên để tái cấu trúc.

Rõ ràng là cực kỳ khó chịu nếu bạn thực hiện điều này đến mức tối đa và không nói cho ai biết về mười nhiệm vụ tương tự khác cần thực hiện, nhưng cũng hoàn toàn có thể hình dung rằng nhiệm vụ thứ hai hoặc thứ ba không nghĩ đến cho đến khi nhiệm vụ đầu tiên được thực hiện. Nếu bạn muốn lập kế hoạch tất cả ra ngoài đi với thác nước.

Trong thỏa thuận bạo lực với Robert Harvey, mục đích của câu chuyện người dùng là để hiểu người dùng cần gì để có thể làm gì. Khi bạn chải chuốt, khách hàng hiểu và quan tâm đến câu chuyện của người dùng, nhưng các nhà phát triển quan tâm hơn một chút. Khi bạn hỏi đủ câu hỏi để hiểu và ước tính công việc, bạn có thể tạo các nhiệm vụ để hỗ trợ chúng.

Trong trường hợp cụ thể này, bạn có thể tạo các tác vụ cho phép cốt lõi của cả hai câu chuyện người dùng sẽ được thực hiện cùng với bất kỳ vấn đề nào bạn giải quyết trước.

Những điều quan trọng để thêm vào câu chuyện của người dùng là:

• Tiêu chí chấp nhận
• Giả định

Nói đúng ra, Câu chuyện của người dùng là lời hứa của một cuộc trò chuyện để hiểu kết quả được yêu cầu.

Ví dụ: lấy câu chuyện người dùng thứ hai của bạn

Là Người dùng Quản lý Tín dụng, tôi có thể nhận được email có chứa bản PDF về chênh lệch bảng lương hiện tại và trước đây cho Văn phòng.

Hãy suy nghĩ về những điều sau đây:

• "Nhu cầu" người dùng đang thúc đẩy yêu cầu này là gì? (Có PDF trong email như một giải pháp đến từ họ không? Điều này có thể không giải quyết được nhu cầu và nhóm của bạn có thể đưa ra giải pháp tốt hơn)
• Các lát tối thiểu có thể giải quyết "nhu cầu" của người dùng này và xác nhận giải pháp của bạn là gì? Các vòng phản hồi ngắn có giá trị.

Khi tiếp cận chia tách câu chuyện, hãy nhớ tiêu chí ĐẦU TƯ của bạn nếu có thể.

1. Tôi phụ thuộc
2. N vô nghĩa
3. V aluable
4. E kích thích
5. S trung tâm
6. T estable

Có thể có những câu chuyện có một trật tự tự nhiên. Hãy xem xét điều đó - thường thì câu chuyện đầu tiên lớn hơn vì nó mang lại chức năng cần thiết và câu chuyện thứ hai được xây dựng trên đó.

Tôi sẽ thách thức các câu chuyện "kỹ thuật", vì nhìn chung chúng rất có thể là các nhiệm vụ để giúp hỗ trợ việc thực hiện các câu chuyện tập trung vào kết quả của người dùng.

TL; DR

Giả sử cả hai câu chuyện của người dùng được đưa vào phạm vi trong cùng một lần lặp, công việc của nhóm là phân tách các câu chuyện thành một kế hoạch thực hiện và các nhiệm vụ tiếp viên của nó. Câu chuyện của người dùng cung cấp bối cảnh và phạm vi; họ không triển khai, thông số kỹ thuật hoặc các mục danh sách cú đấm.

Câu chuyện nên được phân tách thành nhiệm vụ lặp

Cho dù bạn đang theo dõi Scrum hay một số phương pháp nhanh nhẹn khác, đó là một lỗi phổ biến để bỏ qua giai đoạn lập kế hoạch của một lần lặp. Trong Scrum, khi một Mục tồn đọng của sản phẩm (không cần phải là câu chuyện của người dùng, nói đúng ra) được đưa vào Sprint hiện tại, nhóm sau đó phải sử dụng một phần của Lập kế hoạch Sprint để xác định điểm chung giữa các mục công việc, xác định các phụ thuộc và sau đó phát triển Sprint Backlog để nắm bắt công việc ở cấp độ nhiệm vụ.

Như bạn đã chỉ ra trong bài đăng của mình, không có gì lạ (và thực tế là mong muốn) cho một phép lặp nhanh để chứa các câu chuyện người dùng liên quan chặt chẽ. Trong Scrum, điều này được thể hiện thông qua việc sử dụng Mục tiêu Sprint. Bên ngoài khuôn khổ Scrum, thường vẫn có ý nghĩa để kéo theo những câu chuyện liên quan vì các mục tiêu chung hoặc phụ thuộc chung của chúng. Bằng cách trích xuất và sau đó làm việc trên các phụ thuộc được chia sẻ trong một lần lặp duy nhất, các nhóm thường có thể tránh được yêu cầu phải cấu trúc lại hoặc lặp lại mã cho các tính năng tương tự nhưng không giống nhau trong tương lai.

Nhiệm vụ thực hiện Câu chuyện

Đây là một cách khác để suy nghĩ về kế hoạch phụ thuộc cho câu chuyện của người dùng. Nói chung:

1. Một sử thi / chủ đề được sử dụng để lập kế hoạch dài hạn hoặc nhóm trên một hồ sơ tồn đọng.
2. Một câu chuyện người dùng được sử dụng để truyền đạt các mục tiêu, bối cảnh và phạm vi.
3. Lập kế hoạch đúng lúc được sử dụng để phát triển một triển khai phù hợp với một lần lặp duy nhất.
4. Nhiệm vụ thực hiện kế hoạch đúng lúc đáp ứng Định nghĩa Hoàn thành cho một hoặc nhiều câu chuyện của người dùng.

Đối xử với các câu chuyện của người dùng như một kế hoạch thực hiện hoặc một danh sách nhiệm vụ được hầu hết các học viên coi là một mô hình chống nhanh nhẹn. Dù bạn chọn cách nào để gọi nó, đừng bỏ qua giai đoạn lập kế hoạch kịp thời của khung nhanh nhẹn của bạn và đảm bảo theo dõi các phụ thuộc và chi tiết triển khai được chia sẻ ở đâu đó trong quy trình của nhóm bạn.