Mục Sprint mất nhiều thời gian hơn sau đó dự kiến ​​sẽ được hoàn thành. Chúng ta nên làm gì?

Chúng ta nên làm gì nếu một mục trong scrum mất nhiều thời gian hơn dự kiến? Tôi đang hỏi điều này bởi vì tôi đã nhận thấy các mục mà các nhà phát triển đang vật lộn để hoàn thành vì nó khó khăn hơn nhiều so với suy nghĩ ban đầu.

Trong tình huống như vậy chúng ta nên

• loại bỏ các mục từ chạy nước rút trở lại danh mục sản phẩm để chúng ta có thể đáp ứng thời gian chạy nước rút?
• di chuyển đến mục chạy nước rút dễ dàng hơn và để lại nước rút có vấn đề cho đến khi kết thúc dòng thời gian
• biện minh tại xem xét nước rút tại sao các mục không thể được hoàn thành tại nước rút hiện tại cho các bên liên quan?

Làm thế nào chúng ta có thể tránh tình trạng như vậy trong tương lai? Có phải do thiếu kế hoạch trả trước hoặc chúng tôi đã không nỗ lực để chia mục chạy nước rút thành mục nhỏ hơn?

Với "mục", tôi cho rằng bạn có nghĩa là "nhiệm vụ".

Lập kế hoạch lạc quan trong phần mềm cũng cũ như chính phần mềm. Điểm hay của scrum là bạn sẽ sớm đối mặt với nó và tạo ra khả năng hiển thị của nó: đây là lý do tại sao vận tốc của các đội dựa trên dữ liệu trong quá khứ chứ không phải ước tính trong tương lai.

Để hoàn thành một câu chuyện, bạn cũng phải hoàn thành các nhiệm vụ khó khăn hơn nhiều so với dự đoán. Không có lý do để trì hoãn chúng. (Đây là lý do tại sao Định nghĩa Hoàn thành rất quan trọng). Nếu điều đó có nghĩa là nhóm thất bại trong một câu chuyện, thì quá tệ, bạn sẽ có điều gì đó để nói về quá trình hồi tưởng tiếp theo của bạn. Vận tốc sẽ đi xuống (trở nên thực tế hơn) và nhóm sẽ học cách ước tính tốt hơn hoặc để lại giới hạn an toàn hơn cho các nhiệm vụ không lường trước. Chủ sở hữu sản phẩm sẽ có được cái nhìn thực tế hơn về kế hoạch phát hành của mình.

Chúng ta nên làm gì nếu một mục trong scrum mất nhiều thời gian hơn dự kiến?

Giả sử rằng theo mục bạn có nghĩa là câu chuyện, vào cuối giai đoạn nước rút, bạn thường đưa nó trở lại trong hồ sơ tồn đọng của sản phẩm (và có khả năng lập kế hoạch cho lần lặp lại tiếp theo). Đội ghi điểm 0 cho nó trong lần lặp hiện tại.

Một cách khác, nếu câu chuyện đủ lớn, là cắt nó theo chiều dọc . Ví dụ: câu chuyện "tìm kiếm danh mục sản phẩm", có thể được chia thành "tìm kiếm theo danh mục" và "tìm kiếm toàn văn bản", nhưng không phải trong "hình thức tìm kiếm" và "kết quả tìm kiếm".

Làm thế nào chúng ta có thể tránh tình trạng như vậy trong tương lai?

Không có câu trả lời trực tiếp dễ dàng cho điều này. Trong scrum bạn thực hiện hồi tưởng chạy nước rút mỗi lần lặp, trong đó bạn thường thảo luận về những điều này với nhóm. Có nhiều khả năng khác nhau:

• Nhóm, hoặc một số thành viên trong nhóm, có một tuần tồi tệ
• Đường ống nhóm của bạn làm việc theo chiều ngang (ví dụ: phụ trợ-> frontend-> QA)
• Những câu chuyện quá lớn do nhầm lẫn.
• Nhóm "tấm vàng" các câu chuyện bằng cách thêm các công việc bổ sung không thực sự cần thiết để hoàn thành câu chuyện.
• Những câu chuyện rất lớn về bản chất, bạn cần chạy nước rút dài hơn (không chắc)
• Nhóm ước tính những câu chuyện không chính xác (không mạch lạc)
• Dự án có rất nhiều nợ công nghệ / cơ sở mã thối và vận tốc của bạn quá thấp
• Bạn không đo lường và ước tính chính xác khả năng chạy nước rút của mình (hoặc hoàn toàn).

Vân vân.

Bạn nói rằng bạn sẽ không hoàn thành nó, nhưng điều đó không tệ, đó chỉ là dữ liệu.

"Đáp ứng dòng thời gian nước rút" không phải là một mục tiêu. Mục tiêu của bạn là hoàn thành câu chuyện của người dùng. Dòng thời gian chỉ là một công cụ giúp bạn đo lường và tìm hiểu bao nhiêu công việc bạn có thể làm trong một lần chạy nước rút.

Nếu bạn chắc chắn rằng bạn không thể hoàn thành công việc trong lần chạy nước rút, một giải pháp là chuyển nó xuống cuối danh sách ưu tiên và thực hiện các câu chuyện khác trong lần chạy nước rút trước. Sau đó, với thời gian còn lại, bạn có thể bắt đầu làm việc với nó. Ước tính lại công việc đi vào nước rút tiếp theo và hoàn thành nó sau đó.

Hãy chắc chắn trong phần hồi tưởng của bạn rằng bạn thảo luận về những gì đã sai để bạn có thể cải thiện các ước tính của mình trong tương lai.

Nếu một nhiệm vụ mất nhiều thời gian hơn dự kiến, điều này sẽ được đưa ra trong quá trình hồi cứu và thảo luận. Có một số phần bị bỏ lỡ trong phân tích đầu? Đây có phải là điều mà đội đã không được thực hiện thường xuyên không? Có rất nhiều lý do có thể khiến một cái gì đó có thể mất nhiều thời gian hơn so với ước tính ban đầu.

Nhóm nên cố gắng hoàn thành nhiệm vụ tốt nhất có thể và sau đó trong phần hồi tưởng thảo luận về các chiến lược về điều này trong tương lai. Nếu nhóm còn khá mới với việc sử dụng Scrum thì đó có thể là một phần trong việc thực hiện vận tốc ban đầu của đội. Một số đội có thể nghĩ rằng họ có thể làm được 20 điểm và một số đội có thể làm được 60 điểm, điểm quan trọng là số lượng điểm có thể được thực hiện như thế nào mỗi lần chạy nước rút.

Điều này sẽ xảy ra trong tương lai vì bất cứ khi nào nhóm có nhiệm vụ mới, nó đã không được thực hiện trước khi có một thời gian để xử lý các kẽ hở của việc ước tính. Đây là một phần của quá trình học tập không thực sự đáng ngạc nhiên.

Những gì chúng ta thường làm trong công ty của mình khi một nhiệm vụ bắt đầu mất nhiều thời gian hơn dự kiến ​​là chia nó thành các nhiệm vụ nhỏ hơn.

Bằng cách đó, chúng tôi không đổ lỗi cho nhà phát triển vì quá chậm, nhưng chúng tôi cũng thừa nhận rằng nhiệm vụ được thiết kế không chính xác.

Một điều khác có thể là giao nhiệm vụ cho một thành viên khác trong Nhóm phát triển của bạn để tránh nhà phát triển quá cố của bạn tự đào lỗ hổng. Và nếu nhiệm vụ thực sự quan trọng, một số XP có thể là giải pháp.