アジャイルに関連する神話や誤解は何ですか？
アジャイルに関連して、平均的な新参者が陥る可能性のある誤解がたくさんあります。アジャイルの世界における誤解とは何ですか？それが本当に誤解であることをどのように正当化しますか？
更新：アジャイル神話の要約
上記の神話の詳細とその他の神話については、次の回答をお読みください。
「包括的なドキュメントでソフトウェアを動作させる」とは、機能仕様を必要としないことを意味します。
間違い！！！これは、ユーザーと繰り返ししわを取り除くことができることを意味します-ベンダーとして言えば、QAおよびサインオフフェーズを支援するための優れたドキュメントが必要です...
「私たちはスクラムを行っているので、（ペアリング|リファクタリング|TDDを行う|...）する必要はありません」実際、スクラムの創設者であるケンとジェフは、生産性の高いすべてのスクラムチームがフルレンジを実装していると言っていますエクストリームプログラミングプラクティスの。
テスト駆動開発はすべてのバグを見つけることはできません/すべてに適用するのは簡単ではありません-したがって、私たちは試してみるつもりはありません！-TDDを学ぶことは「オール・オア・ナッシング」ではなく、何をテストし、どのように効率的に行うかを判断するのが上手になります。私はそれを10年間やっていますが、それを行うためのより良い方法と考慮すべき新しいことをまだ見つけています。
本からアジャイル手法を適用するために必要なすべてを学ぶことができます。-あなたは行うことによって学ぶ必要があり、それはしばしば助けてくれる他の人々を指導し、会うことを意味します。人々が本からそれを学ぼうとすると、多くのことがうまくいかなくなります。
ヒステリックな（そして非常に現実的な）「候補者はスクラムマスターから指示を受け、サポートする必要があります」（先週送られた仕事の仕様から...） -スクラムマスターは人々に何をすべきかを指示することは想定されていません。彼/彼女は促進するためにそこにいます-すなわち、チームが物事を自分で整理することを学ぶのを助けるために。これは大規模な障害モードです。人々に「命令」するスクラムマスターがいます。
「アジャイル手法」について話す-大きな無知の指標。まず、「アジャイル」については特定のことのように話しますが、それは多くの異なることを表す非常に漠然とした包括的な用語です。第二に、「アジャイル」手法の使用-それらはたくさんあり、それらの多くを行うためのさまざまな方法がたくさんあります！第三に、アジャイルコミュニティの多くの人々が、90年代の大きくて重いUMLを搭載した方法に対する反発でここにやって来ました。これらの人々は「方法論」という言葉を使う傾向がありません...
ソフトウェアをアジャイルな方法で開発するには、特に才能のある人が必要です。ジェフ・サザーランドは、銀行のチームを管理するために「チーフプログラマーチーム」モデルを使用することを検討したと述べていますが、十分な「チーフ」のようなものがないことに気づきました。スクラムは、適度に能力のある多くのプログラマーから最高の生産性を引き出すように設計されています。実際、他の人を助けたくない不釣り合いに生産的なチームメンバーを削除すると、平凡なチームメンバーの「ブロックを解除」し、生産性の高い元チームメンバーを補う以上の生産性を実現できます...それがジェフです。とにかく言う...
私が最近主導したオープンスペースワークショップで思いついたXP関連のものは他にもたくさんあります：http： //xpday-london.editme.com/WhereHasXpGone
神話：アジャイル開発手法を使用することは、ソフトウェアエンジニアリングの問題に対する特効薬の解決策です。
神話：テストファースト開発では、プロジェクトに適切な単体テストを強制します。
事実：多くの開発者は怠惰になり、コードの前に作成する単体テストはしばしば弱くて不十分です。
神話：ペアプログラミングは常により良いコードをもたらします。
事実：プログラマーはわずかに反社会的であり、互いに著しく異なる思考プロセスを持っている傾向があります。コードを作成するときに誰かが首から息を吸うのは非常に不快であり、その結果、コードの質と量の両方が低下する緊張した作業環境になることがよくあります。
神話：アジャイルはドキュメントがないことを意味します
事実：アジャイルは包括的なドキュメントよりも実用的なソフトウェアを重視していますが、これはドキュメントがまったくないことを意味するものではありません。ドキュメントは、ちょうど間に合うように、そして十分に書かれるべきです。いいえ、アジャイルは常にユーザーストーリーを使用する必要があるとは言いません。それらが適切である場合にのみ、それらを使用してください！
神話：アジャイルは計画がないことを意味する
Fact: Agile does not support development without planning. Agile uses continuous planning and estimating to maximize the ROI. Actually, Agile is about scope management.
Myth: Agile means no discipline
Fact: Agile developers must be more disciplined for success.
Myth: Agile only works for trivial projects
Fact: Agile (actually Scrum here) has been used for
Myth: Agile doesn't scale
Fact: Sutherland used Scrum in groups of 500+, Cohn used Scrum in groups of 100+
神話：「事前に大きなデザインがない」とは、デザインがないことを意味します。
Myth: Waterfall always fails.
Reality: Most of the software you're using on your agile project was developed with waterfall. Even BDUF waterfall, in many cases.
本当の神話はありませんが、極端なことは何でも間違っています。「進行中の設計」を期待してゼロ設計を行うアジャイルプロジェクトは、失敗する可能性があります。最後のセミコロンまですべてを設計するウォーターフォールプロジェクトは、予算、時間、またはユーザー要件の変更により失敗する可能性があります。
「アジャイル設計手法は拡張性がない」と繰り返し言われていますが、アジャイル開発は、適切に実装および検討されれば、あらゆるサイズに効果的に拡張できます。
神話：各スプリントを慎重に計画およびスケジュールする必要があります。
これにより、各スプリントを完全に計画できるように、多くの事前計画を行うことができます。
これにより、敏捷性を打ち負かし、「アジャイル」と呼ばれる滝を作成できます。
私が見た最大の神話は、他の開発プロセスよりも優れていると人々が考えているというものです。
これは、この業界で長年見られている通常の銀の弾丸のスネークオイルです。
https://stackoverflow.com/questions/301993/is-agile-development-dead/302060#302060
顧客に何を請求するかを知るのは簡単です。これは私たちにとって常に最大の問題です。プロジェクトの範囲がわからないため、お客様に固定価格を提供することはできず、ほとんどのお客様は固定価格を要求しています。
神話：他の選択肢と比較した場合、アジャイルは常に優れたオプションです。
事実：プロジェクトの規模、要件（特にそのような柔軟性）、外部スケジュール、および顧客の態度によっては、オーソドックスな方法論と比較して常に生産性が高いとは限りません。
Myth: Agile means XP and Scrum
Fact: There are other practices like OpenUP, AMDD, etc.
Great thread. While I offer nothing new in my related blog post, I do illustrate the top two reasons why Agile fails when it does fail. 1) Lack of upfront requirements (taking the 'begin coding with incomplete requirements' to an extreme) and 2) Lack of adequate unit tests (because CHANGE will happen - and unit tests are the quickest way of catching all the breaking points resulting from the CHANGE).
http://www.anujvarma.com/BlogEngine.net/post/2010/11/03/Agile-versus-Flat-Footed-development.aspx
Myth: Agile is anti-thetical to security.
Fact: This is only true, if you try to force a full-blown waterfall-style SDL (security development lifecycle) onto supposedly Agile teams. In fact, I have designed and implemented Agile-SDL variants in numerous organizations, and I can say that putting the Agile into the Security, can actually afford a higher, more robust level of security. it just takes a change of security mindset - from control to visibility and guidance.
アジャイルの周りには多くの神話があり、その中には外部からのものもあれば、内部からのものもあるというのは完全に正しいことです。これが私がリストに追加しようと思ったいくつかのことです：
「プロジェクトマネージャーやビジネスアナリストはもう必要ありません」
私たちはBDUFを行っておらず、チームは自主的ですが、物事が拡大するにつれて、何が起こっているのかを調整する仕事をしている人々が依然として必要です。また、非常に複雑なビジネスシナリオがある場合は、それを理解するのを手伝ってくれる人が必要になる可能性があります。IME、PMとBAを本当に必要とした多くのプロジェクトはまだそれらを必要としています（そして今それらを必要としないプロジェクトはおそらくそれらを必要としませんでした！）。しかし、もちろん、アジャイルの世界ではPMとBAの役割が異なる傾向があり、それが人々を不安にさせる可能性があります。
「アジャイルは固定価格プロジェクトには使用できません」
それは可能ですが、かなり難しいです。特に、「固定価格」は実際には「固定価格、範囲、時間」を意味することは誰もが知っているので...
「私たちはBDUFを行いません、私たちが進むにつれてすべてを行います」
作業する唯一の方法は、JEDUF（Just Enough Design Up Front）です。より多くが必要な場合もあれば、より少ないコストで解決できる場合もありますが、その時点で必要以上のことはしません。
If you don't show real value with agile, it will fail. And fail miserably as in bankrupt a company miserably. Going to agile just because it is 'agile' makes you look as silly as the CIO in this video:
http://www.youtube.com/watch?v=nvks70PD0Rs
John