Làm thế nào thường xuyên một nhóm Scrum đáp ứng cam kết Sprint của nó? [đóng cửa]

Cam kết là một lời hứa, và tất cả chúng ta đã được dạy rằng bạn cần phải giữ lời hứa. Nhưng nó có thực tế để giữ cam kết cho mỗi Sprint không? Đôi khi mọi người bị bệnh, đôi khi cách tiếp cận kỹ thuật được chứng minh là sai và bạn phải suy nghĩ lại mọi thứ, đôi khi trong các cuộc thảo luận thêm với chủ sở hữu sản phẩm hoặc người dùng mà bạn hiểu rằng tính năng này rất khác so với suy nghĩ ban đầu.

Tôi biết rằng Hướng dẫn Scrum chính thức hiện sử dụng từ "dự báo" thay vì cam kết, có lẽ để giải quyết những vấn đề này.

Vì vậy, câu hỏi của tôi là tần suất các nhóm trong tổ chức của bạn giữ đúng cam kết và bạn thích phương pháp này hay bạn muốn thay đổi nó.

Cảm ơn bạn.

Đây không phải là câu hỏi thường xuyên về việc một đội nên "giữ lời hứa" như thế nào.
Đó là một câu hỏi điều tra tại sao một đội sẽ có một vấn đề đáp ứng các cam kết của nó.

Nếu đó là một sự can thiệp thần thánh, điều đó không thực sự quan trọng. Nhưng nếu bạn thấy rằng bạn thường xuyên cần phải quay lại bảng vẽ, vì cách tiếp cận kỹ thuật của bạn hoàn toàn sai hoặc PO liên tục thay đổi suy nghĩ của anh ấy hoặc những câu chuyện không đủ rõ ràng khi bắt đầu chạy nước rút, thì bạn cần điều tra tại sao.

Không đáp ứng một cam kết nước rút là một triệu chứng; bạn cần quan tâm đến nguyên nhân gốc rễ.

Nếu tất cả đều ổn, thì việc các đội đáp ứng các cam kết của họ là điều bình thường. Họ nên chạy đủ mát để đối phó với quy mô nhỏ, sự gián đoạn hợp lý và có khả năng như bệnh ngày, bệnh khẩn cấp chăm sóc trẻ em, v.v ... mà không có nó ngay lập tức và tự động gây ra thất bại trong việc đưa ra cam kết nước rút. Nếu nó không thể thì theo quan điểm của tôi, các cuộc chạy nước rút đã kết thúc và đang chạy quá nóng vì lợi ích lâu dài của họ như là một đội.

Nếu chạy nước rút liên tục không cung cấp, thì scrum đã thực hiện theo lời hứa của mình, để làm cho "các vấn đề" hiển thị. Các vấn đề có thể bao gồm việc không có các nhiệm vụ được xác định đúng, không đủ kinh nghiệm trong nhóm hoặc văn hóa quản lý liên tục cố gắng giao quá mức - và vì vậy liên tục bị thiếu hụt.

Dù bằng cách nào, giải pháp là xác định nguyên nhân gốc và khắc phục nó, thay vì đánh đòn các nhà phát triển khó hơn.

Các nhóm luôn 'gần gũi' để đáp ứng các cam kết của họ sẽ thất bại theo cách nghiêm trọng hơn. Bạn có thể chắc chắn rằng họ không thực hiện đủ thử nghiệm.

Cá nhân tôi tin rằng nếu không ai trong tổ chức quan tâm đến việc đáp ứng cam kết của bạn, thì bạn không nói về cam kết. Bạn cần hai đối tác để thực hiện một thỏa thuận và hình thành một cam kết.

Một cam kết chạy nước rút là một cái gì đó mà bạn sẽ có thể giữ, có tính đến tất cả "biến thể bình thường". Bạn có thể đọc bài viết trên blog của tôi về những điều cơ bản của lập kế hoạch nhanh nếu bạn muốn biết thêm về những gì tôi muốn nói với biến thể cơ bản. Và như Stefan đã nêu , không đáp ứng cam kết của bạn là một triệu chứng không phải là bệnh.

Sau mỗi lần chạy nước rút, bạn có một khoảnh khắc để kiểm tra vận tốc thực tế của lần chạy nước rút đó và điều chỉnh "vận tốc trung bình" của bạn với điều đó (như được giải thích trong bài viết đã đề cập ở trên ). Nếu vận tốc của bạn tiếp tục đi xuống, chạy nước rút sau khi chạy nước rút, bạn bắt đầu thấy các mẫu có thể giúp bạn phát hiện nguyên nhân gốc thực sự của việc này. Đây có thể là quá nhiều công việc không có kế hoạch (ví dụ: các nhiệm vụ khẩn cấp nhỏ xuất hiện, lỗi trong mã mà bạn đang làm việc, thay đổi tiêu chí chấp nhận trong giai đoạn nước rút, ...). Tất cả các dữ liệu này cần phải được theo dõi, rất có thể là do chủ scrum để giúp cô ấy tìm ra những mẫu nào trong đó. Điều đó sẽ giúp nhóm đưa ra các hành động trong quá trình hồi cứu.

Quan điểm của tôi là các đội không đưa ra cam kết. Có thể cho rằng, họ thậm chí không đưa ra dự báo. Dự báo được thực hiện trước khi nước rút được lên kế hoạch - dự báo là trung bình chúng sẽ đáp ứng vận tốc của chúng. Điều đó có nghĩa là đôi khi họ sẽ làm nhiều hơn một vài điểm so với vận tốc của họ, đôi khi họ sẽ làm ít hơn một chút.

Nếu bạn đang làm ít hơn tốc độ của bạn một cách thường xuyên, vận tốc của bạn giảm xuống để phản ánh điều đó. Dự báo do đó cũng giảm. Nếu bạn tiếp tục kéo theo nhiều câu chuyện hơn tốc độ lịch sử của bạn nói rằng bạn có thể chạy nước rút sau khi chạy nước rút, thì đó không phải là một thất bại trong thực thi, đó là một thất bại trong kế hoạch. Bạn biết vận tốc của mình, vì vậy bạn không nên mang về nhiều điểm hơn lịch sử nói rằng bạn có thể hoàn thành.

Để trả lời câu hỏi cụ thể của bạn, trong ba tổ chức nơi tôi đã sử dụng scrum, chỉ có một tổ chức theo dõi các số liệu "bỏ lỡ cam kết" theo thời gian. Đối với công ty đó, các đội thường đạt dự báo khoảng 85% thời gian.

Nếu bạn không đáp ứng cam kết thì bạn nên giảm vận tốc. Nếu bạn luôn luôn đáp ứng nó, bạn nên tăng cho đến khi đôi khi bạn thất bại.

Vấn đề là bạn thất bại nặng nề như thế nào? Nó phải luôn luôn gần gũi. Hoặc là bạn làm cho nó với một chút chậm chạp hoặc thất bại chỉ một chút. Đó là một mục tiêu lành mạnh cho bất kỳ kỷ luật, thời gian chạy, nâng tạ, v.v ... Lý tưởng nhất là số lượng công việc trung bình được thực hiện trong một lần chạy nước rút nên là một phân phối bình thường xung quanh vận tốc của bạn.

Điều quan trọng hơn là xu hướng dài hạn trong vận tốc của bạn. Nếu mỗi tuần bạn thêm 15 điểm câu chuyện vào vận tốc của mình nhưng chỉ hoàn thành hơn 10 điểm so với tuần trước thì đó có thực sự là một điều tồi tệ? Tại một số nơi họ coi đây là "mục tiêu kéo dài".