Có cuộc khảo sát nào về việc các nhà phát triển mức độ thích hay ghét scrum không? [đóng cửa]

Bối cảnh: Trong một cuộc hội thảo, một nhà phân tích đã chỉ ra trong một tweet rằng các nhà phát triển ghét scrum.

Chính tôi và một người khác đã trả lời rằng đây không phải là trường hợp và bắt đầu thảo luận về các kịch bản khác nhau về lý do tại sao các nhà phát triển sẽ không thích scrum.

Một trong những tình huống mà các nhà phát triển lười biếng không thể ẩn trong một dự án scrum. Họ liên tục được thử thách bởi đội để đóng góp.

Cuộc thảo luận này đã dẫn đến một bài đăng trên blog và video http://elsewhat.com/2010/05/20/lazy-developers-hate-agile-and%C2%A0scrum/

Tôi đã nhận được ba ý kiến ​​mà tôi đã cố gắng trả lời theo cách trung lập, nhưng họ nhận xét rằng có một số người ghê tởm scrum (và tôi luôn chắc chắn 100% họ không phải là nhà phát triển lười biếng).

Câu hỏi

Đã bao giờ có một cuộc khảo sát giữa các nhà phát triển về việc các nhà phát triển mức độ thích hay ghét scrum chưa?

Scrum rất khắt khe ...

.. đặc biệt là khi nó bị biến thái bởi quản lý.

Do đó, tôi không nghi ngờ gì nhiều nhà phát triển ghét Scrum.

Một cách để biến Scrum mà tôi thấy trong một tập đoàn lớn là phân chia vận tốc cho các nhà phát triển. Và tất nhiên làm cho nó rất rõ ràng trong standup hàng ngày. Đoán xem điều gì đã xảy ra ngắn hạn?

Tôi đã thấy rằng Scrum thường không phù hợp trong một số tổ chức, đặc biệt là các công ty đại chúng và chính phủ.

Sau 5 năm đào tạo, giảng dạy và huấn luyện Scrum chuyên sâu, trong cả tập đoàn lớn và công ty rất nhỏ, tôi đã đi đến kết luận rằng Scrum chỉ là một kỹ thuật khác giống như Java là ngôn ngữ khác so với C # và điều làm nên sự khác biệt là cá nhân sử dụng nó, không phải là kỹ thuật chính nó.

Nhận xét meta: Sẽ rất tuyệt nếu có câu hỏi khảo sát về Lập trình viên.

Vì Scrum thay đổi rất nhiều giữa các nhóm khác nhau và các tổ chức khác nhau, nên câu hỏi này sẽ rất khó trả lời. Scrum nên là về việc trao quyền cho nhóm để cung cấp phần mềm tuyệt vời và các nhà phát triển nên như thế.

Nó đi sai ở đâu? Câu trả lời là trong tuyên bố của tôi ở trên. Nhóm không được trao quyền hoặc phần mềm tuyệt vời không được cung cấp.

Có rất nhiều chế độ thất bại, đây là một số:

• Chủ sở hữu sản phẩm không hiểu khách hàng hoặc doanh nghiệp.
• Nhóm không hiểu khách hàng hoặc doanh nghiệp.
• Các vấn đề tổ chức cản trở việc nhóm hoàn thành mục tiêu của họ.
• Scrum biến thành một quản lý vi mô hàng ngày.

Những người đôi khi được gọi là scrum-buts .

IMO Scrum có nhiều khả năng được yêu thích / thành công nếu:

• Nhóm đã đưa ra quyết định áp dụng Scrum vì cảm thấy nó phù hợp với sản phẩm / dự án.
• Có phản hồi mạnh mẽ / liên tục từ khách hàng thông qua chủ sở hữu sản phẩm.
• Tàu sau mỗi lần chạy nước rút.
• Nhóm có quyền tự chủ, tự tổ chức và tin tưởng / hỗ trợ đầy đủ từ tổ chức.
• Một tỷ lệ lớn các mặt hàng trong hồ sơ tồn đọng đến từ nhóm.

Một nhận xét khác là trong các lập trình viên "lười biếng" trong Scrum chỉ chịu trách nhiệm trước nhóm nên họ có thể thích điều đó hơn với trách nhiệm của mình với sếp. Ở mức nào, tôi không nghĩ đây là một yếu tố.

Một vấn đề tôi thấy với Scrum là vấn đề gà và trứng. Nếu bạn đã nhanh nhẹn, bạn có thể không cần Scrum. Nếu bạn vốn dĩ không nhanh nhẹn Scrum có thể sẽ không thay đổi nó, nó thậm chí có thể làm mọi thứ tồi tệ hơn vì nó sẽ mang lại bất kỳ sự nhanh nhẹn nào trên bề mặt và làm cho nó rõ ràng đến mức các lực chống nhanh nhẹn có thể đè bẹp nó :-)

Một tổ chức không nhanh nhẹn có thể biến nhanh nhẹn không? Tôi không biết. Tôi nghĩ Scrum muốn làm điều đó nhưng tôi không chắc nó có thể.

Theo kinh nghiệm của tôi, Nhà phát triển / kiến ​​trúc sư ghét scrum rất nhiều. Có thể vì những lý do dưới đây

1. Nhiều tổ chức sản phẩm chủ yếu coi giao hàng kinh doanh là mục tiêu chính và gắn kết mọi câu chuyện nước rút với nhu cầu kinh doanh. Do đó, họ chiếm quyền điều khiển / thỏa hiệp các động cơ của kiến ​​trúc, nền tảng, thiết kế sạch sẽ, chất lượng mã trong nhiều trường hợp. Đôi khi, họ không xem xét tiếng khóc của các nhà phát triển. Đây là những gì cảm thấy bởi các nhà phát triển chuyên nghiệp, những người không lười biếng.

2. Agile / scrum mang lại sự thống trị, chủ sở hữu sản phẩm / người quản lý sản phẩm khoan hồng rất nhiều về việc không cung cấp chi tiết đầy đủ về yêu cầu và hướng nội mà họ mong đợi các nhà phát triển tưởng tượng / cho rằng cần phải tiến hành phát triển. Điều này dẫn đến sự khác biệt trong việc thực hiện, quá nhiều khiếm khuyết, nỗi đau lớn cho các nhà phát triển bằng cách đốt dầu nửa đêm của họ trong nhiều lần.

3. Trong nhiều trường hợp, chủ sở hữu sản phẩm thỏa hiệp các yêu cầu kỹ thuật với mục tiêu kinh doanh thường bỏ qua các nhà phát triển, ý kiến ​​của kiến ​​trúc sư về sản phẩm, hình thức, mục tiêu dài hạn của kiến ​​trúc và họ kết thúc chúng tôi bằng các giải pháp ngắn hạn để không phải là lựa chọn đúng đắn cho bất kỳ sản phẩm nào

4. Cuối cùng, bạn sẽ kết thúc với một sản phẩm có lỗi, lỗi thiết kế, đôi khi xây dựng các nhược điểm, xếp hạng không hài lòng từ người dùng, các vấn đề về hiệu suất, cơ sở mã hóa khủng khiếp để nhà phát triển tiếp tục.

Tôi thực sự không coi scrum / agile là phương pháp tốt hơn trong nhiều trường hợp.

Tôi ghét nó. Và hầu hết các nhà phát triển tôi biết cũng ghét nó.

Thật khó để thực hiện công việc sáng tạo, não bộ như phát triển phần mềm dưới kính hiển vi.