アジャイルソフトウェアの12の原則

アジャイルソフトウェア開発宣言の背後にある12の原則。顧客満足を最優先して価値あるソフトウェアを早く継続的に届けること、要求の変更を歓迎すること、動くソフトウェアを短い間隔でリリースすること、自己組織的なチームなどを掲げる。

アジャイルソフトウェア開発宣言を補足する12項目の原則。顧客満足を最優先すること、短い間隔で動くソフトウェアを届けることなどを定める。

ユーザーの活動の流れを横軸に並べ、その下に各活動を実現するユーザーストーリーを優先度の高い順に縦に並べて、プロダクトの全体像を2次元の図で表す手法。ジェフ・パットンが提唱し、横に区切ってリリースの範囲を決めることで、MVPの範囲を検討できる。

チームが外部から細かな指示を受けずに、目標の達成に向けて作業の進め方や役割分担を自分たちで決めて動くこと。アジャイルソフトウェアの12の原則で、最良のアーキテクチャ・要求・設計は自己組織的なチームから生まれるとされる。スクラムガイド2020では自己管理型（self-managing）という表現に改められた。

ケント・ベックらが提唱したアジャイル開発手法。コミュニケーション、シンプル、フィードバック、勇気、尊重の価値に基づき、テスト駆動開発、ペアプログラミング、リファクタリング、継続的インテグレーションなどの具体的なプラクティスを定める。プラクティスは共同、開発、管理者、顧客の4つに分類される。

アジャイル開発で、計画、設計、実装、テストを一通り行う、1〜4週間程度の固定した短い開発期間。イテレーションごとに動くソフトウェアを作って評価を受け、その結果を次の計画に反映する。スクラムではスプリントと呼ぶ。

要件定義、設計、実装、テスト、運用の各工程を上流から下流へ順に進め、原則として前の工程に戻らない開発モデル。工程ごとに成果物を確定させるため進捗を管理しやすいが、要件の変更や後工程で見つかった問題への対応が難しい。要件が明確な大規模開発に向く。

2001年に17人のソフトウェア開発者がまとめた、アジャイル開発の価値観を示す宣言。プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を価値とする。