アジャイルvsウォーターフォールの効率/効果に関する研究はありますか
先日の会議で、アジャイルはウォーターフォールと比較した場合、開発時間の効率が60％だけであると主張されました。私はこの主張を検証または反論するつもりはありません。 2つの方法論を比較する研究があったかどうかを知るのは興味深いです。
この2つを比較した研究はありますか？
本 "ソフトウェアの作成：実際に機能するものとそれを信じる理由" は、XP、スクラム、動的ソフトウェア開発、リーンなどのアジャイルメソッドに関するいくつかの章があり、優れた科学的裏付けがあります。 O'Reillyに期待するとおり、高品質です。編集者の一人は優秀な Greg Wilson で、信頼できるコンピュータサイエンスの作者、編集者、発表者でした。
この本自体は、アジャイルに関する多くを含む複数の調査研究を要約しています。 1つのセクションは、 "2つの頭は1つよりも優れているか？ペアプログラミングの有効性について" を含む研究をまとめたものです。Dybå、T .;アリスホルム、E。 Sjøberg、D.I.K .; Hannay、J.E .;シュル、F。そして、 " アジャイルソフトウェア開発の実証的研究：系統的レビュー " ToreDybåとTorgeirDingsøyrによる。
一般的な意味では、ほとんどのアジャイルプラクティスは有益ですが、ペアプログラミングとTDDおよび他のアジャイルテナントの効果は、期待するほど強力ではありません。 TDDが実際にはやみつきになるかもしれないという不安な脚注さえあります*。
この本は、これまでに行われた多くの研究に1つのまとまりとしてアクセスするための優れた方法です。本をレビューするウェブ上にいくつかの blogs と他の sites があります。
*これは必ずしも私の意見ではありません！
タイトルが嫌いなのと同じくらい、私は 敏捷性と規律のバランス：困惑する人のためのガイド にあなたに関連するいくつかの情報が含まれていると思います。この本は、2人のソフトウェアエンジニアリングプロセスとソフトウェアプロジェクト管理のエキスパート、Barry BoehmとRichard Turnerによるものです。この本は、アジャイルおよび計画主導の方法論のさまざまな側面を検討し、それらを比較および対比し、それらを統合して「両方の世界のベスト」の状況を達成することについても説明します。
俊敏性と規律のバランスをとるの付録Eには、さまざまなアジャイルおよび計画主導の方法のコストと利点に関する豊富な経験的情報が含まれています。ただし、時間の有効性に関するデータはないようです。しかし、データをざっと見ると、これはどちらかまたは両方の選択肢ではないようです（一部のプロジェクトでは、アジャイルメソッドを適用すると、労力が減り、スケジュールが速くなり、欠陥が少なくなりました。ただし、使用した他のプロジェクト。このセクションでは、さまざまな業界のさまざまなプロジェクト、それらが使用したプロセスの種類、およびプロジェクトの過程で経験したことについて説明します。
付録Eで引用されているケーススタディはたくさんあり、このデータが得られます。多くは特定の業界または特定の組織内に集中しているため、ランダムに名前を付けるだけでは多すぎます。ケースを検討する場合は、チーム、プロジェクト、組織、業界に本質的に類似しているケースを見つけて、妥当な結論を導き出すことをお勧めします。
Rapid Development：Taming Wild Software Schedules では、Steve McConnellがライフサイクル方法論を選択するときに考慮すべき多くの要素を特定します。要件の理解度、アーキテクチャの理解度、望ましい信頼性、リスク管理、スケジュールの制約、プロセスのオーバーヘッドの量、プロジェクト中の「コース修正」、可視性を顧客に提供する能力、可視性を備えた管理を提供する能力、および開発チームと管理の高度化。組織の文化など、他にもあるので、おそらく完全なリストはどこにもありません。
まったく同じプロジェクトであっても、チームファクターがあります。計画主導のスパイラル手法を使用して一貫してソフトウェアを提供しているチームを取り、それらをスクラムに投入すると、彼らは生産性の低下、スラッシングの増加を経験し、新しいプロセスモデルを克服する必要があります。成功するまで。別の方法論の方が適している場合もありますが、ソフトウェアを実際に提供するビジネスのニーズは常にあります。そのため、プロセス改善の取り組みは、多くの場合、長期的な取り組みであり、一晩ではありません。大きな変更はチームに衝撃を与え、（たとえ方法論が紙に適しているとしても）生産性の低下を引き起こす可能性があります。
プロセスの効率性や有効性だけでなく、計画主導の環境とアジャイル環境で作業している同じチームのスナップショットを単に見ることはできません。意思決定を行う際には、産業および組織のコンテキスト、プロジェクトの属性、チーム、顧客などを考慮する必要があります。
私が読んだ内容に基づいて、私はあなたの同僚の評価に同意しなければなりません。アジャイルプロジェクトのパフォーマンスメトリックに関して、同様の計画主導型プロジェクトよりも60％効率が悪いケーススタディが見つかるはずです。ただし、アジャイルにより、80％少ない労力、50％少ない時間、そして製品に対する高い顧客満足度が得られることを示す研究もあります。
勉強はしていませんが、私の経験を伝えたいのですが。
前述の方法論の有効性は、アナリストに大きく依存します。
優れた製品所有者がいる場合、たとえばSCRUMは、スペックが悪いウォーターフォールアプローチよりも確かに高速です。
製品所有者が悪いアジャイルは、優れた仕様のウォーターフォールよりも確かに遅いです。
ただし、多くの場合、正確な要件を十分に早期に把握していないため、アジャイル手法ではフィードバックサイクルが速くなります。これは、不確実な地形では、アジャイルが妥当なコスト内で高品質の製品を提供するためのより良い方法であることを意味します。他にも多くの利点があります。たとえば、アジャイルプロジェクトは、うまくいかない場合にキャンセルするのが簡単なので、損失を最小限に抑えることができます。
アジャイル手法はリスクを低減すると言えるかもしれませんが、ウォーターフォールは、時にはより速くても、かなりの金銭的賭けとなる可能性があります。
アジャイルは開発時間の効率が60％しかなかった
そうだね。
しかし、それは不十分な測定です。
通常、アジャイルメソッドは、実際の価値をより早く提供します。
ウォーターフォールは、何が配信されるかに関係なく、単にスケジュールに固執し、多くの場合、非常に長い時間が経過するまで価値のないものを配信します。
さらに。
「開発・テスト時間」とは別に「開発時間」を計測できます。
アジャイルには通常、テストが含まれます。だから遅いようです。
ウォーターフォールの開発は、テストから明確に分離できます。したがって、コードはより早く「テストの準備ができています」。しかし、ずっと後でないと「完了」しません。
そう。彼らは完全に正しいです。彼らが測定したものについて。