agile - アジャイル開発手法の落とし穴は何ですか？

Question

アジャイル開発手法の落とし穴は何ですか？

score 8 · Accepted Answer

一般的な批判は次のとおりです。

構造と必要な文書の欠如
上級レベルの開発者とのみ連携します
不十分なソフトウェア設計を組み込んでいる
採用するには文化の変化が多すぎる
より困難な契約交渉につながる可能性があります
非常に非効率的である可能性があります。コードの1つの領域の要件がさまざまな反復によって変化する場合、同じプログラミングを数回繰り返す必要がある場合があります。一方、計画に従う必要がある場合は、コードの1つの領域を1回記述する必要があります。
プロジェクトの開始時に誰も全体の範囲/要件を知らないため、見積もりを提供するために必要な作業努力の現実的な見積もりを作成することは不可能です
詳細な要件文書がないため、スコープクリープのリスクが高まる可能性があります
アジャイルは機能駆動型であり、機能しない品質属性をユーザーストーリーとして配置するのは困難です

score 7 · Accepted Answer

計画、要件定義、および文書化に不十分な時間と労力を費やす言い訳としてアジャイルを使用する。

score 7 · Accepted Answer

@George Stockerの引用リストから、私の反論とともに...

構造と必要な文書の欠如
1. 多くのアジャイル手法は、本質的な実践を非常に規範的であり、構造を持っていますが、その多くは非公式です。
2. 必要なものを定義します。計画主導の方法で必要とされる多くの文書は使用されておらず、および/または絶望的に時代遅れになっています。敏捷性は、実際に必要な成果物の作成に重点を置いています。
上級レベルの開発者とのみ連携します
1. 独立して（またはペアで）作業できる開発者に最適です。
2. シニア/ジュニア開発者の組み合わせは問題なく機能します。
不十分なソフトウェア設計を組み込んでいる
1. 積極的なリファクタリングを伴うインクリメンタル設計は、設計の多くがアプリケーションをよりよく理解して行われるため、より良い設計につながる可能性があります。
2. 正当な批判は、アジャイル実装者が「アジャイル」ではないことを恐れて、事前に設計を行うことを恐れている可能性があるということかもしれません。方法論者の誰も、事前設計を完全にスキップすることを推奨しません。
採用するには文化の変化が多すぎる
1. 有効である可能性がありますが、私の意見ではそれは価値があります
より困難な契約交渉につながる可能性があります
1. 間違いなく。これは、より機敏な成功が達成されるにつれて変化するはずです。
非常に非効率的である可能性があります。コードの1つの領域の要件がさまざまな反復によって変化する場合、同じプログラミングを数回繰り返す必要がある場合があります。一方、計画に従う必要がある場合は、コードの1つの領域を1回記述する必要があります。
1. 計画が実際の望ましい行動を犠牲にして厳格に守られている場合にのみ、そうでない場合は同じ問題が発生します。
2. 変更が発生した場合、アジャイルメソッドはプラン主導のメソッドよりもこれをうまく処理します。
プロジェクトの開始時に誰も全体の範囲/要件を知らないため、見積もりを提供するために必要な作業努力の現実的な見積もりを作成することは不可能です
1. ほとんどのアジャイルメソッドは、速度を理解するための優れたツールを提供します。
2. すべての方法で計画を立てるのは困難です。これはアジャイルメソッドに固有のものではありません。
3. アジャイル手法は、ソフトウェアを顧客の手に渡すことで、厳密な事前計画よりも早く実際の要件を発見します。これは、顧客が実際に何を望んでいるかを、それを見るまでわからないためです。
詳細な要件文書がないため、スコープクリープのリスクが高まる可能性があります
1. アジャイルはこれとはまったく異なる見方をしています。固定時間を維持するためにスコープを制限するのではなく、スコープと時間のトレードオフに焦点を当てています。
2. 顧客はアジャイルのスコープと時間のトレードオフについて選択できるため、スコープを完全に制御できます。
アジャイルは機能駆動型であり、機能しない品質属性をユーザーストーリーとして配置するのは困難です
1. 必要に応じて、計画主導型のプラクティスからの従来の方法を含め、品質属性を追跡するために必要な任意の方法を使用できます。

score 6 · Accepted Answer

一番の落とし穴は、「アジャイル手法」とは、やりたいことができるかできないかということだと思います。アジャイルを使用するほとんどの人は、敏捷性につながるプラクティスを実装するのではなく、実際に「アドホック」を使用していると推測するのは危険です。敏捷性には、おそらく計画主導の開発よりも、仕事と規律が必要です。

変更が発生する可能性があり、やり直さなければならないため、アジャイルは効率が悪いと言う人からは笑い声が聞こえます。現実には、変更が発生し、方法に関係なく、何かをやり直す必要があります（または不幸な顧客になってしまいます）。アジャイルメソッドは、これが発生することを受け入れ、最も混乱の少ない方法で発生することを可能にするメソッドを使用しようとします。効率を上げるには、許可する変更について規律を保つ必要があります。アジャイルを使用すると、「はい」と言っても時間どおりに完了できる可能性が高くなります。

score 6 · Accepted Answer

ここでの答えの多くは落とし穴ではなく、批判です。私の考えでは、「落とし穴」は注意すべき潜在的な問題であり、アジャイルを避ける理由ではありません。

以下は、エクストリームプログラミングの一部です。

ペアプログラミングでは、個人の衛生状態、性的な快適さ、親密な社会的スキルが突然重要になります
リファクタリングに夢中になり、重要でないコードをリファクタリングしたり、高度なパターンを些細なルーチンに適用したり、締め切り直前にリファクタリングしたりするのは簡単です。
プラクティスは、重要な方法で互いにサポートします。どちらかを捨てれば、別のトラブルに巻き込まれます。たとえば、TDD をやめると、リファクタリングが難しくなり、リスクが高くなります。
慣習に従っていると思うからといって、それが正しく行われているとは限りません。XP がどのように機能するかを理解し、それを正しく実行するには、才能のある人材が本当に必要です。
それでも失敗することがあります。全員がアジャイルだからといって、プロジェクトを完成させたり、顧客が望む優れたソフトウェアになるとは限りません。

score 5 · Accepted Answer

アジャイルは「フライがズボンの座になる」開発を行うための言い訳だと考えています。

score 4 · Accepted Answer

これは非常に哲学的な質問です。ここに1つの落とし穴があります。アジャイル開発が2週間ごとに180度回転することを許すことができると考える経営陣。もう1つの落とし穴は、間違って実行すると、チームメンバー間で作業負荷のバランスが取れないことです。

score 2 · Accepted Answer

私の感覚では、アジャイル手法の最大のリスクは「柔軟」であるという評判です。つまり、開発者がアジャイル手法の独自の定義を入力し始めるリスクがあります。これが発生した場合、基本的に方法論がまったくなくなることになります。

score 2 · Accepted Answer

「アジャイル」と考えるPHBは、「より少ない人数で物事を成し遂げる」ことを意味します;）

score 2 · Accepted Answer

最大の落とし穴は、人々が慣行を見て、1つのことを見逃していることです。

検査と適応

チームとして、常に自分の慣行を評価し、何がうまくいくか、何がうまくいかないか、何を微調整する必要があるか、何を適応させる必要があるかを見つけていなければ、失敗する可能性があります。

score 2 · Accepted Answer

アジャイルは、少なくとも 1 つのスプリントの要件がある場合にのみ成功します。
クライアントのほとんどは、適切な要件を持っていない傾向があるか、スプリントの途中で頻繁に変更されるため、再計画してスプリントを再開することになります。
アプリケーションがすでに本番環境にあり、開発者が各スプリントでアプリケーションに機能を追加するだけのメンテナンスモードの場合、アジャイルはより成功する可能性があります。
管理職には 1 つの利点があります。彼らは、職場で (毎日のスプリントミーティングで) 開発者/QA の日常生活に忍び込むことができます。
適切な計画が整っていない場合、予算をかなり早く使い果たす可能性があります (ほとんどの場合、これは採用する必要がある変更が原因で発生します)。
ドキュメントが少ない/まったくないため、誤解されたり誤解されたりした機能について、1 人の担当者に責任を負わせることはできません。
この説明責任の欠如は、故意にチーム内で自分の役割を果たさないというより多くの問題につながる可能性があります.
開発者は、絶えず変化する要件と関連するやり直しに不満を感じるかもしれません。(5 つのスプリントで同じ機能を微調整することを想像してください。これは、適切に分析された要件を使用して 1 つのスプリントで完了することができます)。
ビジネス/クライアントの代表者は、適切な要件を与える責任を負わない傾向があります。

私は 3 年前からアジャイルプロセスに取り組んでいます。それ以前は、ウォーターフォール方式を採用する CMM レベル 5 の会社で働いていました。

score 1 · Accepted Answer

私は、「より困難な契約交渉につながる可能性がある」ことを除いて、一般的な批判のすべてに同意しません。顧客が開発プロセスとは何の関係も持ちたくない場合、これを回避することは困難です。

他の項目は、単体テストや継続的インテグレーション、バージョン管理を行わないなど、開発プロセスが他の方法で壊れている場合にのみ当てはまります。

主な落とし穴は、すべての人がアジャイルマニフェストを読んだり、主題の行動について研究したりすることなく、「一種のアジャイル」アプローチを行おうとすることです。

agile - アジャイル開発手法の落とし穴は何ですか？

12 に答える 12

Related

Reference