開発者がスクラムをどの程度好きか嫌いかについての調査はありますか？[閉まっている]

背景：カンファレンス中に、アナリストはツイートで開発者がスクラムを嫌うと指摘しました。

私と他の人はこれはそうではないと答え、開発者がスクラムを嫌う理由についてのさまざまなシナリオについて議論し始めました。

その怠惰な開発者がスクラムプロジェクトに隠れることができないシナリオの1つ。彼らは常にチームから貢献を求められます。

この議論の結果、ブログ投稿とビデオ http://elsewhat.com/2010/05/20/lazy-developers-hate-agile-and%C2%A0scrum/

私は中立的な方法で答えようとした3つのコメントを受け取りましたが、それらのコメントは、スクラムを嫌う人がいることを指摘しています（そして、私は常に怠惰な開発者ではないと確信しています）。

質問

開発者の間で、開発者がスクラムをどの程度好きまたは嫌いかについて調査したことがありますか？

スクラムは非常に厳しいです...

..特にそれが経営者によって倒錯しているとき。

したがって、多くの開発者がスクラムを嫌うのは間違いない。

大企業で私が見たスクラムを倒錯させる1つの方法は、開発者によって速度を分割することでした。そしてもちろん、毎日のスタンドアップでそれを非常に目立たせます。短期的に何が起こったと思いますか？

私は、スクラムは通常一部の組織、特に上場企業や政府には適していないことを発見しました。

5年間の集中的なスクラムの実践、教育、コーチングを経て、大企業と非常に小さな企業の両方で、スクラムはJavaがC＃とは別の言語であるのと同じように、もう1つの手法であるという結論に達しました。技術そのものではなく、それを使用する個人。

メタコメント：プログラマーにアンケートの質問をするのは素晴らしいことです。

スクラムはチームや組織によって大きく異なるため、この質問に答えることは非常に困難です。スクラムは、チームに優れたソフトウェアを提供できるようにすることであり、開発者はそれを好むはずです。

どこがいけないの？ 答えは上記の私の声明にあります。チームに権限が与えられていないか、優れたソフトウェアが提供されていません。

非常に多くの失敗モードがあり、ここにいくつかあります：

• 製品の所有者が顧客やビジネスを理解していない。
• チームは顧客やビジネスを理解していません。
• 組織の問題は、チームが目標を達成するのを妨げています。
• スクラムは日々のマイクロ管理に変わります。

それらは、スクラムバットと呼ばれることもあります。

IMOスクラムは、次の場合に高く評価/成功する可能性が高くなります。

• チームは、製品/プロジェクトに適していると感じたため、スクラムを採用することを決定しました。
• 製品の所有者を通じて、お客様から強い/継続的なフィードバックがあります。
• すべてのスプリントの後に発送します。
• チームには自律性があり、自己組織化し、組織からの完全な信頼/サポートを受けています。
• バックログのアイテムの大部分はチームからのものです。

もう1つのコメントは、スクラムでは「怠惰な」プログラマーはチームに対してのみ説明責任を負うため、上司に対して説明責任を果たすことを好む可能性があるということです。とにかく、これは要因ではないと思います。

私がスクラムで見る問題は、鶏と卵の問題です。すでにアジャイルであれば、スクラムは必要ないかもしれません。本質的に俊敏でないスクラムはおそらくそれを変更しないでしょう、それは表面に敏捷性をもたらし、反敏捷性の力がそれを押しつぶすことができるほど目に見えるようにするので、事態をさらに悪化させるかもしれません:-)

非アジャイル組織はアジャイルになるだけですか？知りません。スクラムはそうしたいと思っていますが、それが可能かどうかはわかりません。

私の経験では、開発者/アーキテクトはスクラムを非常に嫌っています。以下の理由が考えられます

1. 多くの製品組織は、主にビジネスデリバリーを主要な目標と考えており、すべてのスプリントストーリーをビジネスニーズに結び付けています。したがって、彼らは、アーキテクチャ、プラットフォーム、クリーンなデザイン、コード品質の動機をいくつかの場面で乗っ取り/妥協しています。時々彼らは開発者の叫びを考慮しません。これは、怠惰ではないプロの開発者が感じていることです。

2. アジャイル/スクラムは、要件に関する完全な詳細を提供しないことに主導権を与え、寛大な製品所有者/製品マネージャーは、開発者が開発を進める必要性を想像/想定することを期待します。これにより、実装に違いが生じ、多くの欠陥が発生し、深夜の石油を何度も燃焼させることにより、開発者に多大な苦痛を与えます。

3. 多くの場合、製品の所有者はビジネス要件で技術的要件を妥協し、開発者を無視し、製品に関するアーキテクトの意見を述べ、アーキテクチャの長期的な目標を達成し、短期間の解決策で終わります。これはどの製品にとっても適切な選択ではありません。

4. 最終的には、欠陥、設計上の欠陥、ロールバックのビルド、ユーザーからの不満評価、パフォーマンスの問題、開発者がさらに触れなければならない恐ろしいコードベースを持つ製品になってしまいます。

多くの場合、私はスクラム/アジャイルをより良い方法論とは考えていません。

私はそれが嫌いです。そして、私が知っているほとんどの開発者もそれを嫌っています。

顕微鏡下でソフトウェア開発のような脳の創造的な仕事をすることはかなり難しいです。