Chạy nước rút Scrum có nghĩa là làm việc với tốc độ nhanh nhất có thể?

Gần đây tôi đã phỏng vấn một số công ty làm Agile, Scrum để chính xác hơn và có một số điều không giống với Agile đối với tôi. Tôi sẽ lấy một trường hợp đặc biệt khiến tôi quan tâm ngay bây giờ, đó là nước rút Scrum.

Một người quản lý dự án cụ thể mà tôi đã nói chuyện (vâng, tôi đã nói người quản lý dự án) tự hào tuyên bố rằng mọi người trong nhóm của cô ấy hiểu ("được nói" là những gì tôi đã chọn từ bối cảnh) rằng bạn không về nhà khi hết giờ làm việc , bạn về nhà khi công việc đã hoàn thành, bất kể nó mất bao nhiêu. Những gì tôi đã đọc ở giữa các dòng là chúng tôi đóng gói càng nhiều tính năng càng tốt vào một lần chạy nước rút và làm thêm giờ để biến nó thành hiện thực.

Bây giờ, tôi chưa làm Agile cho đến bây giờ (làm việc với các tổ chức tài chính và chính phủ mà hầu hết vẫn thích thác nước) nhưng sự hiểu biết của tôi là:

• chạy nước rút trong Scrum là tên của phép lặp chung trong Agile;
• nhóm nên làm việc với tốc độ bền vững và cố gắng tránh làm thêm giờ trong thời gian dài vì điều đó chỉ có tác dụng trong thời gian ngắn và các tác động bị lấn át bởi các vấn đề mà họ phải chịu trong thời gian dài.

Là tuyên bố của tôi phải không? Và, tôi có nên lấy bài thuyết trình của người quản lý làm cờ đỏ không?

Bạn không cần phải tìm kiếm xa để thấy rằng những thực tiễn này đi ngược lại với các nguyên tắc đằng sau Agile. Một trong những nguyên tắc đằng sau Tuyên ngôn Agile nêu rõ:

Các quy trình nhanh nhẹn thúc đẩy phát triển bền vững. Các nhà tài trợ, nhà phát triển và người dùng sẽ có thể duy trì tốc độ không đổi vô thời hạn.

Vài năm trước, Scrum đã thực hiện một thay đổi tinh tế nhưng quan trọng . Thay vì các nhóm cam kết với công việc có thể đạt được, họ dự báo những gì họ nghĩ họ có thể hoàn thành.

Sự thay đổi xảy ra do lạm dụng, nghe có vẻ rất giống thái độ không về nhà cho đến khi nó được thực hiện. Trong quá trình phát triển, có nhiều yếu tố bên ngoài các đội kiểm soát mà họ không thể cam kết - để sử dụng phép tương tự thời tiết, bạn không thể "cam kết" rằng trời sẽ mưa vào ngày mai.

Để trực tiếp trả lời câu hỏi của bạn:

• vâng, Sprint là tên của một lần lặp trong Scrum, hãy xem câu trả lời này cho sự khác biệt
• vâng, các đội nên làm việc với một tốc độ bền vững. Điều chắc chắn duy nhất của việc làm thêm giờ là nó sẽ làm giảm năng suất của các đội trong dài hạn.
• vâng, nó là một lá cờ đỏ!

Vâng, bạn nói đúng, và nếu tôi được nói những gì bạn đã nói, tôi sẽ chạy khỏi đó càng nhanh càng tốt. Họ chỉ sử dụng nhanh như một cái cớ. Âm thanh như cuộc diễu hành cái chết cổ điển.

Có một điều quan trọng có thể khiến điều này được chấp nhận: nhóm chấp nhận phạm vi chạy nước rút.

Trong Scrum, các nhóm không chỉ nhận công việc được giao. Chủ sở hữu sản phẩm đàm phán với nhóm để ưu tiên công việc sản phẩm và công việc kỹ thuật (nợ). Người quản lý dự án, chủ sở hữu sản phẩm và nhóm sau đó đàm phán về những gì được kéo vào giai đoạn nước rút và phạm vi của công việc đó là gì.

Trong thế giới này, nhóm về cơ bản nói rằng "chúng ta có thể hoàn thành công việc X, thử nghiệm và vận chuyển lần lặp này". Vì vậy, tôi mong đợi một nhóm thỉnh thoảng làm việc ngoài giờ để đáp ứng các cam kết này.

Điều đó nói rằng, rất nhiều nơi khốn khổ nhanh nhẹn - và rất ít đội trưởng có thể đàm phán hiệu quả với những người thường là ông chủ của họ ... Tôi sẽ coi đây là một lá cờ đỏ khổng lồ.

Scrum được chia thành các lần chạy nước rút trong đó bạn ước tính một nhóm các nhiệm vụ sẽ được hoàn thành trong thời gian của lần chạy nước rút đó (thường là 2 tuần, nhưng tôi đã thấy bất cứ nơi nào từ 1 ngày đến 4 tuần). Tôi nghĩ rằng điều này tạo ra một động lực để đánh giá sai nhiệm vụ. PO (chủ sở hữu sản phẩm) sẽ muốn ước tính thấp để có được một cam kết lớn trên mỗi lần chạy nước rút. Nhóm nghiên cứu sẽ đưa ra các ước tính lớn để tạo ra các biểu đồ phát triển tốt đẹp cho các Thủ tướng để xem. Đây là, tất nhiên, chỉ ra của một tổ chức crappy. Bạn thực sự muốn có được ước tính chính xác và không sợ bị hụt hẫng và mang câu chuyện đến lần chạy nước rút tiếp theo hoặc hoàn thành sớm và kéo các nhiệm vụ bổ sung ra khỏi hồ sơ tồn đọng. Tôi nghĩ thuật ngữ "chạy nước rút" tạo ra hình ảnh này của những người làm việc nhanh hơn.

Không: chạy nước rút scrum là một timebox, không hơn, không kém. Khi bắt đầu chạy nước rút / lặp lại, nhóm đưa ra ước tính về số điểm câu chuyện mà họ tin rằng họ có thể đạt được, dựa trên những thứ như hiệu suất trước đó, tính sẵn có, sự kiện sắp tới, trở ngại mở, v.v. Sau đó, họ đàm phán với chủ sở hữu sản phẩm về những câu chuyện người dùng được đưa vào nước rút. Đó là (hoặc là? Xem câu trả lời khác) cam kết mà nhóm đưa ra cho chủ sở hữu sản phẩm.

Trong quá trình phát triển, nếu hóa ra mọi thứ không thực sự như dự đoán (rốt cuộc đó là phát triển phần mềm) và có nguy cơ nhóm sẽ không đáp ứng cam kết, họ thông báo cho chủ sở hữu sản phẩm rằng sẽ có rủi ro một hoặc nhiều câu chuyện sẽ xảy ra không được hoàn thành

Và điều đó tốt. Chắc chắn, nó cảm thấy tồi tệ, phải thừa nhận vào cuối cuộc đua nước rút rằng cuộc đua nước rút thất bại, nhưng nó không phải là thất bại, đó là một cơ hội để cải thiện. Bởi vì vào cuối giai đoạn nước rút / bắt đầu cuộc đua mới, bạn có thể thực hiện hồi cứu chạy nước rút, và điều đầu tiên bất cứ ai sẽ hỏi là 'Tại sao chúng ta thất bại trong lần chạy nước rút này, và chúng ta cần làm gì để không thất bại lần nữa ? '. Một lựa chọn sẽ là đưa ra ít cam kết hơn (= chiếm ít điểm câu chuyện hơn).

tl; dr: Tốc độ bền vững. Scrum là về nhịp, một cái gì đó mà nhóm có thể theo kịp vô thời hạn trên cơ sở chạy nước rút. Làm thêm giờ không được; nhóm sẽ trở nên làm việc quá sức, công việc sẽ trở nên cẩu thả, các thành viên sẽ bị ốm hoặc bỏ việc hoàn toàn, và sau đó bạn có một vấn đề lớn hơn cả một lần chạy nước rút thất bại.

Các quy trình nhanh nhẹn thúc đẩy phát triển bền vững. Các nhà tài trợ, nhà phát triển và người dùng sẽ có thể duy trì tốc độ không đổi vô thời hạn.

Từ những người tuyên bố Agile

Làm việc ngoài giờ mọi lúc không có vẻ bền vững với tôi.

Điều đó nói rằng, tôi thấy không có vấn đề gì với cam kết mùa xuân là một điều mạnh mẽ (nếu đó là cách nhóm muốn làm việc) và phải làm việc thêm giờ khi bạn làm việc quá sức hoặc làm hỏng các ước tính là một động lực tốt để ước tính hoặc giao tiếp tốt hơn kỳ vọng vào PO.

Một người quản lý dự án cụ thể mà tôi đã nói chuyện (vâng, tôi đã nói người quản lý dự án) tự hào tuyên bố rằng mọi người trong nhóm của cô ấy hiểu ("được nói" là những gì tôi đã chọn từ bối cảnh) rằng bạn không về nhà khi hết giờ làm việc , bạn về nhà khi công việc đã hoàn thành, bất kể nó mất bao nhiêu. Những gì tôi đã đọc ở giữa các dòng là chúng tôi đóng gói càng nhiều tính năng càng tốt vào một lần chạy nước rút và làm thêm giờ để biến nó thành hiện thực.

Đó không phải là Scrum. Khối lượng công việc được đề xuất cho một bảng thời gian dựa trên vận tốc nhóm , không phải trên danh sách mong muốn của người quản lý. Họ chỉ đơn giản là cố gắng lừa bạn tin rằng làm việc ngoài giờ vô tận là "Agile", điều đó không phải. Nhóm sẽ hoạt động hiệu quả hơn trong khi làm việc không bị xáo trộn và tập trung, nhưng Scrum không phải là cây đũa thần cho hiệu quả vô tận .

Người quản lý có một sự hiểu lầm nhỏ về Agile, hoặc (nhiều khả năng) anh ta nghĩ rằng các nhà phát triển thật ngu ngốc. Mặt khác, khi nhóm chấp nhận chạy nước rút hết lần này đến lần khác, biết rằng họ sẽ cần phải làm thêm giờ, có lẽ họ thực sự ngu ngốc và không xứng đáng với điều đó hơn?

Tôi đoán, bạn biết câu trả lời ... ;-)