Làm thế nào để bạn xử lý các câu chuyện phụ thuộc trong scrum?


9

Trong công ty tôi hiện đang làm việc, chúng tôi nhận thấy rằng đôi khi, một số câu chuyện bị ràng buộc với nhau (như trong quá ghép nối). Điều này có thể là chúng thuộc cùng một tính năng hoặc là các tính năng khác nhau nhưng có một số tính năng cần được hoàn thành trước để tiếp tục với các tính năng tiếp theo, v.v.

Làm thế nào để bạn xử lý các trường hợp này, mà không dừng quá trình làm việc của vòng lặp? Có phải chúng ta làm sai điều gì?

Câu trả lời:


7

Đâ là một câu hỏi tuyệt vời. Lý thuyết nói rằng những câu chuyện của người dùng nên độc lập nhưng tôi không bao giờ có thể hoàn toàn đạt được điều đó.

Theo tôi, điều quan trọng nhất là truyền đạt sự phụ thuộc để cả nhóm và chủ sở hữu sản phẩm nhận thức được điều đó. Điều này sẽ buộc chủ sở hữu sản phẩm xác định lại các câu chuyện của người dùng để loại bỏ sự phụ thuộc (ví dụ: bằng cách hợp nhất các câu chuyện của người dùng) hoặc xác định mức độ ưu tiên kinh doanh phù hợp để câu chuyện người dùng chính được thực hiện trước tiên.

Dựa trên quyết định ưu tiên và PO, bạn sẽ thực hiện cả hai trong cùng một lần chạy nước rút hoặc quyết định phụ thuộc sẽ được thực hiện sau đó mà không gặp vấn đề gì vì hiệu trưởng sẽ được thực hiện.

Trường hợp xấu nhất là nếu A phụ thuộc vào B và B phụ thuộc vào A. Trong trường hợp đó, các câu chuyện của người dùng có thể được xác định không chính xác và có thể được viết lại thành A và B (chủ yếu là độc lập hoặc chỉ phụ thuộc một chiều) và C phụ thuộc vào A và B.


2

Lên kế hoạch cho chúng phù hợp.

Đặt chúng trong cùng một lần chạy nước rút và vì các câu chuyện của người dùng cũng được ưu tiên trong một hồ sơ tồn đọng nước rút, bạn sẽ không gặp phải bất kỳ vấn đề nào.

Vì nhóm của bạn tham gia vào việc này, họ nhận thức được sự phụ thuộc, vì vậy không có gì bạn phải sợ. Họ là người lớn và nếu bạn giải thích cho họ về những người phụ thuộc (thông thường họ sẽ giải thích điều đó cho bạn), mọi việc sẽ diễn ra suôn sẻ.

Trong Agile, giống như trong Thác nước, bạn chỉ có thể làm một việc tại một thời điểm. Và bạn thường làm A trước B nếu B cần A. Đó là lẽ thường.


1

Sự phụ thuộc có thể là một mùi mà bạn đang cắt các câu chuyện của mình theo chiều ngang thay vì theo chiều dọc thông qua hệ thống. Phát triển cho một tính năng cụ thể sẽ bao gồm mọi thứ từ sửa đổi thiết kế cơ sở dữ liệu cho đến giao diện người dùng. Nếu bạn thấy rằng bạn đang dành tất cả nỗ lực của mình cho một câu chuyện người dùng ở một mức độ thấp hơn của cấu trúc hệ thống, như, nói, viết các thói quen xử lý để tra cứu cơ sở dữ liệu, thì có nhiều khả năng bạn đang tạo ra sự phụ thuộc giữa các câu chuyện. Và, có lẽ bạn đang viết sai câu chuyện của người dùng.


1
Vì vậy, làm thế nào bạn sẽ xử lý chia tách câu chuyện trên một cửa hàng trực tuyến. Người dùng sẽ có thể xem danh sách các sản phẩm. Họ sẽ có thể tìm kiếm, lọc và sắp xếp các sản phẩm. Trong tâm trí của tôi, mỗi hành động này đủ lớn để đảm bảo câu chuyện của riêng nó. Nhưng bạn có thể triển khai loại sản phẩm trước khi có Danh sách sản phẩm ....
NSjonas

0

Đặt cược tốt nhất của bạn là chia nhỏ các câu chuyện người dùng phụ thuộc của bạn thành các bit nhỏ hơn có thể trở nên độc lập nhất có thể. Họ nên đọc những câu chuyện phụ thuộc nhiều nhất vào đầu tiên (như bạn đã nói: những câu chuyện cần được hoàn thành trước để tiếp tục những câu chuyện khác). Tạo một cái gì đó giống như một chỉ số phụ thuộc: Nếu câu chuyện 3 có nhiều phụ thuộc hơn câu chuyện 1, trước tiên bạn nên đọc câu chuyện 3.

Nếu sự phụ thuộc của bạn gây ra quá nhiều điểm dừng, có thể nên dừng hoàn toàn công việc (có ngay giữa giai đoạn nước rút hiện tại của bạn) và đánh giá lại câu chuyện người dùng ưu tiên của bạn và giải quyết chúng trước

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.