アジャイルvsウォーターフォールの効率/有効性に関する研究はありますか[非公開]

先日の会議で、アジャイルは開発時の効率がウォーターフォールと比較してわずか60％であるという主張がなされました。私はこの主張を検証したり、反論したりするつもりはありません。2つの方法論を比較する研究があったかどうかを調べるのは興味深い。

2つを比較する研究はありますか？

本「ソフトウェアの作成：実際に機能するものと信じる理由」には、XP、スクラム、動的ソフトウェア開発、リーンなどのアジャイル手法に関する章があり、科学的な裏付けがあります。O'Reillyに期待されるように、高品質です。編集者の1人は、信頼できるコンピューターサイエンスの著者、編集者、プレゼンターである優れたグレッグウィルソンでした。

この本自体は、アジャイルに関する多くを含む複数の研究研究を要約しています。Dybå、T.による「2つのヘッドは1つより優れていますか？ペアプログラミングの有効性について」などの研究をまとめています。アリホルム、E .; Sjøberg、DIK; ハンニー、JE; Shull、F .; 「アジャイルソフトウェア開発の実証研究：体系的レビュー」ToreDybåおよびTorgeirDingsøyrによる。

一般的な感覚では、ほとんどのアジャイルプラクティスは有益ですが、ペアプログラミングとTDDおよびその他のアジャイルテナントの効果は、期待するほど強力ではありません。TDDが実際にはやみつきになる*という不安な脚注もあります。

この本は、行われた多くの研究へのアクセスを得るための素晴らしい方法です。この本をレビューするウェブ上のブログや他のサイトがいくつかあります。

*これは必ずしも私の意見ではありません！

タイトルが嫌いである限り、バランスのとれた敏ility性と規律：困惑する人のためのガイドには、あなたに関連する情報が含まれていると思います。2人のソフトウェアエンジニアリングプロセスとソフトウェアプロジェクト管理の専門家によるこの本-バリーベームとリチャードターナー。この本では、アジャイルおよびプラン駆動型の方法論のさまざまな側面を検討し、それらを比較および対比し、それらを統合して「両方の世界のベスト」状況を達成することについても説明します。

俊敏性と規律のバランスの付録Eには、さまざまなアジャイルおよび計画主導型の方法のコストと利点に関する豊富な経験的情報が含まれています。ただし、時間の有効性に関するデータはないようです。しかし、データを一見すると、これはどちらかまたは両方の選択肢ではないように思われます（一部のプロジェクトでは、アジャイルメソッドを適用する際の労力の削減、スケジュールの短縮、および欠陥の減少が発生しました。ただし、使用した他のプロジェクト。このセクションでは、さまざまな業界のさまざまなプロジェクト、使用したプロセスの種類、プロジェクトの過程で経験したことについて説明します。

このデータを提供する付録Eに引用されている多くのケーススタディがあります。多くの人が特定の業界や特定の組織に集中しているため、ランダムに名前を付け始めるにはあまりにも多すぎます。ケースを検討する場合は、チーム、プロジェクト、組織、および業界に本質的に類似するケースを見つけて、合理的に妥当な結論を導き出すことをお勧めします。

で迅速な開発：使いこなすワイルドソフトウェアのスケジュール、スティーブ・マコーネルは、ライフサイクルの方法論を選択する際に考慮すべき要因の数を識別します。要件、アーキテクチャの理解のレベル、希望、信頼性、リスク管理、スケジュールの制約の理解度、処理量オーバーヘッド、プロジェクト中の「コース修正」、顧客に可視性を提供する能力、管理者に可視性を提供する能力、および開発チームと管理の高度化。組織文化など、他にもあるので、おそらくどこにも網羅的なリストはありません。

まったく同じプロジェクトであっても、チームファクターがあります。計画駆動型のスパイラル手法を使用して一貫してソフトウェアを提供しているチームをスクラムに投入すると、生産性の低下、スラッシングの増加が発生し、新しいプロセスモデルを克服してからでなければなりません成功するまで。別の方法論がより適している場合でも、実際にソフトウェアを提供するビジネス上のニーズが常にあります。そのため、プロセス改善の取り組みはしばしば一晩ではなく長期的な取り組みです-大きな変化はチームに衝撃を与え、（方法論が紙上でより適している場合でも）生産性の低下を引き起こす可能性があります。

プロセスの効率性や有効性だけでなく、計画主導型環境とアジャイル環境で作業している同じチームのスナップショットを単に見ることはできません。意思決定を行う際には、産業的および組織的背景、プロジェクトの属性、チーム、顧客などを考慮する必要があります。

私が読んだ内容に基づいて、同僚の評価に反対する必要があります。アジャイルプロジェクトのパフォーマンスメトリックに関して、同様のプラン駆動型プロジェクトよりも60％効率が低いケーススタディを見つけることができると確信しています。ただし、アジャイルにより労力が80％削減され、時間は50％削減され、製品に対する顧客満足度が高くなることを示す研究もあります。

私は勉強していませんが、私の経験を伝えたいです。

上記の方法論の有効性は、アナリストに大きく依存します。

優れた製品所有者がいる場合、たとえばSCRUMは、仕様が悪いウォーターフォールアプローチよりも確実に高速です。

悪い製品所有者とのアジャイルは確かに、優れた仕様のウォーターフォールよりも遅いです。

ただし、多くの場合、正確な要件が十分に早い段階でわからないため、アジャイル手法ではフィードバックサイクルが速くなります。つまり、不確かな地形では、アジャイルが妥当なコストで高品質の製品を提供するためのより良い方法であることを意味します。他にも多くの利点があります。たとえば、アジャイルプロジェクトは、うまくいかないときにキャンセルしやすく、損失を最小限に抑えることができます。

アジャイルな方法論はリスクを軽減しますが、ウォーターフォールは時々より速くても、かなりの金銭の賭けになります。

アジャイルは開発時間の効率がわずか60％でした

本当です。

しかし、それは不完全な測定です。

アジャイルメソッドは通常、より早く真の価値をもたらします。

ウォーターフォールは、配信内容に関係なく単にスケジュールに準拠し、多くの場合、膨大な時間が経過するまで価値のないものを配信します。

さらに。

「開発およびテスト時間」とは別に「開発時間」を測定できます。

通常、アジャイルにはテストが含まれます。遅いようです。

ウォーターフォール開発は、テストから明確に分離できます。そのため、コードはすぐに「テストする準備ができました」。しかし、ずっと後まで「完了」していません。

そう。彼らはまったく正しい。彼らが測定したもの。