Trong Scrum, cách xử lý sự tranh chấp / khối lượng công việc khi kết thúc nước rút

Nhóm của tôi bắt đầu sử dụng Scrum một vài lần chạy nước rút trước đây. Dự án của chúng tôi liên quan đến việc xây dựng phần mềm giao tiếp với các thiết bị vật lý (nghĩ là robot và cảm biến) và tồn đọng Sản phẩm điển hình của chúng tôi thường đại diện cho việc thêm thiết bị điều khiển cho toàn hệ thống.

Chúng tôi chia ra nhiệm vụ gần với ví dụ ở đây . Mỗi tính năng tích hợp thiết bị được chia thành mã, kiểm tra, kiểm tra tích hợp, đánh giá ngang hàng, v.v ... Rõ ràng, có một chuỗi vốn có cho mỗi Mục tồn đọng của sản phẩm. Thông thường, nước rút của chúng tôi trong 2 tuần qua và nhóm có từ 4 đến 6 thành viên.

Chúng tôi gặp phải 2 vấn đề ở cuối nước rút:

• Đầu tiên là giữ cho tất cả mọi người bận rộn vào cuối nước rút.
• Thứ hai (liên quan) là sự tranh chấp trên hệ thống. Chúng tôi cuối cùng đã hòa nhập khá nhiều trong những ngày cuối cùng của cuộc đua nước rút. Chúng tôi chỉ có một hệ thống tích hợp, vì vậy mọi người thường bị chặn tiếp tục thực hiện nhiệm vụ của mình vì họ không thể truy cập hệ thống. Vì nó là kết thúc của cuộc chạy nước rút, không còn nhiều việc phải làm trong việc tồn đọng nước rút. Những người này nên làm gì? Nhận các mục từ đầu của sản phẩm tồn đọng không được đón nhận từ chủ sở hữu sản phẩm, vì các mục hiện tại không được thực hiện. Làm việc về nợ kỹ thuật sẽ giúp toàn bộ dự án nhưng sẽ không giúp hoàn thành chạy nước rút.

Có bất kỳ thực hành tốt nhất để chạy nước rút cấu trúc để tránh những vấn đề này? Lời khuyên để đàm phán với chủ sở hữu sản phẩm?

trong một số cách, thật tốt khi bạn chậm ở giai đoạn nước rút, điều đó có nghĩa là bạn ước tính tốt và không quá cam kết, cho đến khi bận rộn, trong các nhóm scrum tôi đã làm việc, chúng tôi luôn bổ sung các nhiệm vụ nghiên cứu cho những gì sắp tới tăng tốc.

Điều này có thể là bằng chứng về các khái niệm cho những thứ sắp xuất hiện hoặc xem xét nơi để tái xác định mã hiện có, làm việc để có được phạm vi kiểm tra tốt hơn về mã của bạn, v.v.

Bạn nên sửa chữa hệ thống tích hợp của mình để nhóm của bạn có thể tích hợp công việc của họ ngay khi mỗi nhiệm vụ hoàn thành, thay vì chờ đợi một tiếng nổ lớn vào cuối giai đoạn nước rút.

Tôi khuyên bạn nên làm việc với các câu chuyện của người dùng đủ ngắn để hoàn thành trong một vài ngày. Hoàn thành ở đây có nghĩa là mã hoàn thành, thử nghiệm và tích hợp.

Luôn nhớ rằng nó là toàn bộ Team trách nhiệm cung cấp, không phải thành viên cá nhân, mỗi gia nhập , là nó có thể có tất cả bốn đến sáu thành viên làm việc trên mỗi KÈM nhiệm vụ - đẩy mỗi người thông qua quá trình này và di chuyển vào tiếp theo. Điều này thoạt nghe có vẻ không hiệu quả, nhưng nếu những điểm nghẽn mà bạn đang thấy là tồi tệ, thì đó có thể là một lựa chọn hợp lệ.

Ngoài ra, bạn có thể muốn xem xét lý thuyết về các ràng buộc ( Mục tiêu của Goldratt ) và xem cách bạn có thể phân tích tốt nhất lý do tại sao và nơi bạn có các nút thắt tích hợp này.

Chúng tôi đã giải quyết điều này bằng cách áp dụng phương pháp Kanban.

Chúng tôi có hàng đợi trong phần mềm theo dõi (Jira) với mức tối thiểu và tối đa.

Chúng tôi chải chuốt 'khi cần thiết'. Có thể là một lần một tuần, có thể là 3 lần, tùy thuộc vào giới hạn và công việc được hoàn thành.

Điều này sẽ giúp bạn trong việc khiến chủ sở hữu sản phẩm tập trung vào việc giữ hàng đợi của bạn với nhiều việc phải làm và có thể giảm việc quản lý vi mô các vé riêng lẻ. Chỉ cần nhớ rằng như mọi khi thay đổi sẽ mất thời gian.

Chúng tôi vẫn demo hai tuần một lần và chúng tôi phát hành hàng tuần.

Ồ, nếu bạn không nói robot, tôi sẽ cho rằng bạn đang ở trong đội của tôi ngay bây giờ. Chúng tôi có chính xáccùng một bộ vấn đề. Đã làm việc trên nhiều dự án nhanh nhẹn với mức độ trung thực khác nhau với tuyên ngôn và mức độ thành công khác nhau, phân tích của tôi là vấn đề của chúng tôi là nước rút quá ngắn. Chúng tôi đang thực hiện chạy nước rút hai tuần gây ra một vài vấn đề. Một là chúng ta cuối cùng đã quá thận trọng trong kế hoạch và thường kết thúc với những ngày chết ở cuối. Thứ hai là sự nghe lỏm rất lớn của việc xem xét, hồi cứu và lập kế hoạch chiếm 1-2 ngày trong mỗi hai tuần. Một cách khác là, như bạn đã nói, phải tích hợp vào phút cuối và thường xuyên thất bại hàng giờ trước khi xem xét. Dự án nhanh nhẹn đầu tiên và thành công nhất của tôi đã có bốn tuần nước rút, mà tôi thu thập được là khá lớn theo tiêu chuẩn ngành, nhưng nó đã làm việc rất tốt cho chúng tôi.

EDIT: Nhớ một điều nữa từ dự án đầu tiên đó là một lợi ích. Chúng tôi luôn có một hồ sơ tồn đọng sản phẩm được ưu tiên hoàn toàn và cho phép các nhà phát triển tự do lấy các nhiệm vụ khỏi nó nếu nhiệm vụ chạy nước rút của họ hoàn tất và không có nhiệm vụ chạy nước rút nào khác.

Vấn đề thứ hai có lẽ là hậu quả của việc cố gắng khắc phục sự cố không phải là vấn đề # 1. Bạn nên có được những người không bận rộn, để giúp đỡ đồng nghiệp của họ; thay vì làm việc trên các nhiệm vụ không chạy nước rút, gây ra sự tranh chấp về sự tích hợp hạn chế.

Ngoài ra, bạn không nên tích hợp vào cuối nước rút, nhưng liên tục.

Bạn chỉ mới bắt đầu. Cung cấp cho các đội một cơ hội để tự giải quyết vấn đề này thông qua quá trình hồi cứu của họ.

Thứ hai, chủ sở hữu sản phẩm của bạn nên tin tưởng vào nhóm để biết cách tổ chức và tối ưu hóa bản thân tốt nhất. Đổi lại, nhóm tin tưởng PO để biết rõ nhất khách hàng cần gì.

Đây là những thách thức rất phổ biến với các đội nhanh nhẹn mới. Thật tuyệt khi thấy một đội bắt đầu phá vỡ silo của chính họ và phát triển.