TL;DR
2001 年に 17 人の実践者がまとめたアジャイルソフトウェア開発宣言の価値と原則に基づく、ソフトウェア開発のやり方の総称。仕事を小さく分け、短い反復ごとに動くソフトウェアを届ける。
なぜ必要か
宣言はプロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を重んじる。要件が変わりやすい複雑なプロジェクトでは、最初に大きな仕様を作っても無駄が多くなる。要件が安定しているプロジェクトには、計画駆動の手法が向く。
仕組み
仕事を小さな単位に分け、イテレーションやスプリントと呼ぶ 1〜4 週間ほどの期間で区切って進める。イテレーションごとに動くプロダクトを作り、利害関係者に見せて、すぐに方向を変えられるようにする。ウォーターフォールでは作った後にテストするが、アジャイル開発では各イテレーションの中でテストし、要件と設計は時間をかけて形になっていく。
代表的なフレームワークに Scrum、エクストリームプログラミング（XP）、カンバンがある。テスト駆動開発、継続的インテグレーション、ペアプログラミング、バックログ、振り返りもよく使われる。Scrum（1995 年）や XP（1996 年）は宣言より前からあった。
注意点
設計に注意を払わないと、最初は速く進んでも後で行き詰まる。進行中のイテレーションにストーリーを追加すると、作業の流れを乱す。アジャイルの効果を示す根拠は限られており、導入がうまくいかない主な原因に教育の不足が挙げられている。
関連
- アジャイルソフトウェア開発宣言
- BDUF: アジャイル開発ではアンチパターンとみなされる