Có ai khác cảm thấy Scrum không nhanh nhẹn không?

Tôi là một fan hâm mộ lớn của sự phát triển nhanh và đã sử dụng XP cho một dự án rất thành công vài năm trước. Tôi yêu tất cả mọi thứ về nó, cách tiếp cận phát triển lặp lại, viết mã xung quanh một bài kiểm tra, lập trình cặp, có một khách hàng trên trang web để điều hành mọi thứ. Đó là một môi trường làm việc năng suất cao và tôi không bao giờ cảm thấy như mình bị áp lực.

Tuy nhiên, một vài nơi gần đây tôi đã làm việc sử dụng / sử dụng Scrum. Tôi biết đó là đứa trẻ quảng cáo cho sự phát triển nhanh nhẹn ngày nay nhưng tôi không tin chắc 100% là nó nhanh nhẹn. Dưới đây là hai lý do chính khiến tôi cảm thấy không nhanh nhẹn.

Quản lý dự án thích nó

Các nhà quản lý dự án, những người mà bản chất của họ bị ám ảnh bởi các mốc thời gian, tất cả dường như yêu thích Scrum. Theo kinh nghiệm của tôi, họ dường như sử dụng Sprint Backlog như một phương tiện để theo dõi các yêu cầu về thời gian và ghi lại thời gian dành cho một nhiệm vụ nhất định. Thay vì sử dụng bảng trắng, tất cả họ đều sử dụng bảng excel, mỗi nhà phát triển được yêu cầu điền vào, một cách tôn giáo.

Theo tôi đây là cách quá nhiều tài liệu / theo dõi thời gian cho một quy trình nhanh. Tại sao tôi lại lãng phí thời gian để ước tính một nhiệm vụ sẽ mất bao lâu khi tôi có thể tự mình thực hiện nhiệm vụ. Hoặc tương tự tại sao tôi lại lãng phí thời gian để ghi lại thời gian thực hiện một nhiệm vụ khi tôi có thể chuyển sang nhiệm vụ tiếp theo trong tay.

Cuộc họp chờ

Các cuộc họp chờ ở nơi tôi làm việc trước đây là một cơn ác mộng. Hàng ngày chúng tôi phải giải thích những gì chúng tôi đã làm ngày hôm qua và những gì chúng tôi sẽ làm ngày hôm đó. Nếu chúng tôi tiếp tục "ước tính" thời gian cho một nhiệm vụ, người quản lý dự án sẽ bắt đầu bốc mùi và tham khảo Sprint Backlog như một phương tiện thể hiện sự bất tài của bạn vì không tuân thủ dòng thời gian.

Bây giờ tôi hiểu nhu cầu giao tiếp nhưng chắc chắn giai điệu của các cuộc họp hàng ngày nên nhẹ nhàng và tập trung vào việc chia sẻ kiến ​​thức. Tôi không nghĩ nó sẽ biến thành nơi diễu hành theo phong cách bài tập về nhà của bạn. Ngoài ra, điểm chắc chắn của sự nhanh nhẹn là thời gian thay đổi, chúng không nên được đặt trong đá.

Phần kết luận

Ý tưởng của agile là làm cho phần mềm tốt hơn bằng cách làm cho cuộc sống của các nhà phát triển dễ dàng hơn. Do đó, theo tôi, bất kỳ quy trình nhanh nào được sử dụng bởi một nhóm nên được nhà phát triển dẫn dắt. Tôi không nghĩ việc người quản lý dự án sử dụng một quy trình mà họ đã gắn nhãn "nhanh nhẹn" để theo dõi dự án có liên quan gì đến sự phát triển nhanh.

Suy nghĩ của ai?

Có một số yếu tố nhất định trong Scrum dễ bị đồi trụy hơn, nhưng thành thật mà nói, những gì bạn đang mô tả là kết quả của việc cố gắng để một tổ chức chấp nhận Scrum mà không giáo dục tất cả các bên liên quan về tất cả những gì về hoạt động của nó và tại sao nó hoạt động. Bạn cần mua trên toàn bộ công ty để có kết quả.

Bất kỳ sự chuyển đổi nhanh nào cũng sẽ phơi bày mọi thứ tồi tệ đang diễn ra trong tổ chức của bạn, bao gồm, nhưng không giới hạn ở các tổ chức vi mô, những người quyền lực với các chương trình nghị sự của riêng họ, các nhà phát triển được đào tạo không đầy đủ, các silo truyền thông, v.v. Nếu không có ý chí tập thể để giải quyết các vấn đề này và bạn chỉ "làm nổi bật" và chỉ "làm việc trong giai đoạn nước rút", việc triển khai Scrum sẽ không thay đổi.

Tôi không thể nhấn mạnh điều này đủ: nếu bạn muốn làm Scrum, bạn cần những huấn luyện viên có năng lực, người có thể chỉ cho bạn con đường. Không đủ để đọc Essential Scrum và sau đó chỉ cần xem nó đưa bạn đến đâu ...

Đúng. Ngay cả một trong những "cha đẻ" của agile cũng không đồng ý rằng Scrum thực sự nhanh nhẹn: youtube.com/watch?v=hG4LH6P8Syk - Euphoric

Tôi nghĩ rằng liên kết này từ một trong những ý kiến ​​trên thực sự nói lên tất cả. Đó là một chiếc đồng hồ đáng giá, chú Bob cho một lịch sử ngắn gọn về Scrum và về cơ bản nói Scrum không phải là một quá trình phát triển Agile vì Scrum đã phát triển theo thời gian để trở thành một quy trình quản lý . Những lý do đằng sau điều này dường như là vì đó là các nhà quản lý dự án chứ không phải các nhà phát triển đang tham gia các khóa học Scrum.

Những gì bạn đang mô tả là những gì chúng tôi, các Huấn luyện viên Scrum chuyên nghiệp, thấy rất nhiều trong các tổ chức đã "triển khai scrum". Thường thì họ cũng "Làm XP trong nhóm phát triển", nghĩa là có một vài bài kiểm tra Đơn vị đang chạy trên máy chủ xây dựng ở đâu đó. Đây không phải là scrum .

Có, Người quản lý dự án có thể sử dụng một hồ sơ tồn đọng của Sản phẩm, đặc biệt là một sản phẩm đã được số hóa, để lạm dụng các số liệu mà các hệ thống thu thập được. Nhưng Nhóm phát triển và Scrum Master không nên để anh ta. Quản lý dự án đang làm gì ở đó? Không nên là chủ sở hữu sản phẩm ?!

Giống như XP có thể được thực hiện kém và một số quy trình nghiêm ngặt hơn có thể cảm thấy rất trôi chảy (với việc tích hợp, triển khai liên tục, nhưng vẫn rất có kế hoạch), Scrum chỉ là một khung. Nó cần những người tốt, những người hiểu các giá trị và quy trình để thực hiện nó tốt. Phải học hỏi liên tục một cải tiến để đạt được điều đó.

Bạn có thể mong đợi rằng một, nhưng chỉ vì một số (nhiều người?) Lạm dụng Scrum theo cách không nhanh nhẹn không có nghĩa là Scrum không nhanh nhẹn.

Quản lý dự án : không có vai trò như vậy trong nhóm Scrum. Scrum Master không chịu trách nhiệm về ngân sách hoặc thời hạn đáp ứng. Anh ấy chịu trách nhiệm giúp đội ra và loại bỏ bất kỳ trở ngại nào đang trên đường đến mục tiêu mà họ cam kết. Từ những gì bạn mô tả, có vẻ như PM của bạn đã tấn công Scrum để tự mình nhận lấy các đặc quyền thường đi đến nhóm và Chủ sở hữu sản phẩm, duy trì thói quen kiểm soát và chỉ huy trước đó.

Thời gian theo dõi : Scrum khuyến cáo để theo dõi thời gian còn lại và tóm tắt để xác định tình trạng chạy nước rút, chứ không phải điểm vào thời điểm dành do các thành viên nhóm nghiên cứu cá nhân. Điều này có vẻ là một chi tiết nhưng làm cho tất cả sự khác biệt giữa một nền văn hóa định hướng đổ lỗi và một cách tiếp cận hướng mục tiêu.

Từ Hướng dẫn Scrum :

Theo dõi tiến độ của Sprint

Tại bất kỳ thời điểm nào trong một Sprint, tổng số công việc còn lại trong Sprint Backlog có thể được tổng kết. Nhóm Phát triển theo dõi tổng số công việc này còn lại ít nhất cho mỗi Scrum hàng ngày để dự đoán khả năng đạt được Mục tiêu Sprint . Bằng cách theo dõi công việc còn lại trong suốt Sprint, Nhóm phát triển có thể quản lý tiến trình của mình.

scrum là một phương pháp quản lý dự án

agile là một phương pháp phát triển phần mềm (-ish)

scrum + agile hoạt động rất tốt

scrum mà không nhanh nhẹn ... không quá nhiều