[論文レビュー] To Agile, or not to Agile: A Comparison of Software Development Methodologies

Ruslan Shaydulin, Justin Sybrandt|arXiv (Cornell University)|Apr 24, 2017

Software Engineering Techniques and Practices参考文献 22被引用数 13

ひとこと要約

この論文は、製品品質とアジャイル適合性の基準に基づき、ウォーターフォール、AUP、スクラム、TDD、RAD、JAD、FDDの7つのソフトウェア開発手法を評価し、アジャイル手法が大規模システムにおいて完全に技術的負債を管理できず、スケーラビリティにも欠けることが判明した。研究は、アジャイル手法が小規模でチームベースのプロジェクトに最も適していると結論づけ、一方でウォーターフォールは複雑で大規模な環境において信頼性があるため、依然として使用されている。

ABSTRACT

Since the Agile Manifesto, many organizations have explored agile development methods to replace traditional waterfall development. Interestingly, waterfall remains the most widely used practice, suggesting that there is something missing from the many "flavors" of agile methodologies. We explore seven of the most common practices to explore this, and evaluate each against a series of criteria centered around product quality and adherence to agile practices. We find that no methodology entirely replaces waterfall and summarize the strengths and weaknesses of each. From this, we conclude that agile methods are, as a whole, unable to cope with the realities of technical debt and large scale systems. Ultimately, no one methodology fits all projects.

研究の動機と目的

• アジャイル手法の普及にもかかわらず、ウォーターフォール手法が広く使用されている理由を調査すること。
• 製品品質、コスト見積もり、技術的負債管理などの主要基準において、7つの代表的なソフトウェア開発手法（ウォーターフォール、AUP、スクラム、TDD、RAD、JAD、FDD）の強みと弱みを評価すること。
• アジャイル手法が大規模または複雑なソフトウェアプロジェクトにおいてウォーターフォール手法に効果的に置き換え可能かどうかを特定すること。
• 実際の開発環境におけるアジャイル手法のスケーラビリティと実用的適用可能性を評価すること。
• アジャイル手法に欠落している点を特定し、それが大規模システムでの採用が限定的でウォーターフォール手法に依存が続く理由を説明すること。

提案手法

• 研究は、要件の柔軟性、コスト見積もり、検証、技術的負債管理などを含む12の基準に基づく構造化されたフレームワークを用いて、ウォーターフォール、AUP、スクラム、TDD、RAD、JAD、FDDの7つの手法を評価した。
• 各手法がアジャイル原則（顧客フィードバック、反復的開発、最小限の文書化、最小限の十分なアーキテクチャ）をどの程度サポートできるかを評価した。
• 理論的分析と実世界の適用可能性の両方を含み、各手法が動的要件やシステム複雑性に対処する方法に焦点を当てた。
• 各特徴について、手法がその機能をサポートするか否かに基づいてスコアを付与し、重大な欠落を特定することに注力した。
• 全手法の結果を要約するための比較表（表1）を用いて分析を行い、各手法における欠落した能力を強調した。
• 集計評価に基づき結論を導き出し、大規模システムにおいては単一のアジャイル手法がウォーターフォールを完全に代替できないことを強調した。

実験結果

リサーチクエスチョン

• RQ1 アジャイル手法の台頭にもかかわらず、なぜウォーターフォール手法が最も広く使用されているのか。
• RQ2 スクラム、TDD、FDDなどの代表的なアジャイル手法が、技術的負債管理やコスト見積もりといった核心的懸念事項をどの程度満たしているか。
• RQ3 アジャイル手法は大規模で複雑なソフトウェアシステムに効果的にスケーリング可能か、それとも技術的負債やアーキテクチャの複雑さの圧力に耐えられず失敗するか。
• RQ4 アジャイル手法の主な制限とは何か。それらが大規模プロジェクトにおいてウォーターフォール手法を完全に置き換えられない理由を説明できるか。
• RQ5 ウォーターフォールによる計画とスクラムによる実行を組み合わせたハイブリッドアプローチは、個々の手法の弱みをどのように緩和できるか。

主な発見

• どのアジャイル手法も技術的負債管理を完全に満たしておらず、これは大規模ソフトウェアシステムにおいて重要な要因である。
• ほとんどのアジャイル手法は顧客フィードバックと反復的開発をサポートしているが、コスト見積もりと精錬を信頼できる形で提供するのは、スクラムやAUPの一部に限られる。
• FDDとRADは技術的負債管理をサポートせず、長期的なアーキテクチャ的整合性を保つメカニズムも欠如している。
• ウォーターフォールは、予測可能なコスト見積もり、文書化、リスク管理といった特徴を提供するため、信頼性があるとして依然として広く使われている。これらは大多数のアジャイル手法に欠けている。
• スクラムやTDDといったアジャイル手法は検証と顧客参加を強くサポートしているが、非機能要件やシステム全体の品質管理においては不足している。
• 本研究は、計画にウォーターフォールを、実行にアジャイル手法を組み合わせたハイブリッドアプローチが、単一の手法に依存するよりも優れた成果をもたらすことを確認した。