ユーザー機能駆動開発（FDD）

利用者にとって価値のある機能を単位として、短い周期で設計と実装を繰り返す開発手法。FDDともいう。

利用者にとって価値のある機能（フィーチャ）を単位として、短い期間で設計と構築を繰り返すアジャイル開発手法。全体モデルの作成、フィーチャリストの作成、フィーチャごとの計画・設計・構築の5つの活動で進め、比較的大規模なチームにも適用しやすい。

ドメイン駆動設計で、ソフトウェアによって課題を解決しようとする業務上の対象領域。例えば保険のシステムなら、契約、保険料、保険金の支払などの業務の知識とルールの範囲を指す。ドメインの知識を整理して表したものがドメインモデルで、大きなドメインは境界づけられたコンテキストに分けて扱う。関係モデルの定義域（ドメイン）とは別の意味である。

システム開発を要件定義、設計、実装、テスト、運用などの工程に分け、上流の工程から下流の工程へ順に進める開発モデル。各工程の成果物を確定させてから次の工程に進むので、進捗と品質を管理しやすいが、後の工程で要件の誤りや変更が分かると手戻りが大きい。要件が明確で変更の少ない開発に向く。

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

チームが外部から細かく指示されるのではなく、目標の達成に向けて作業の進め方や分担を自分たちで決めて進めること。アジャイルソフトウェア開発宣言の背後にある原則では、最良のアーキテクチャ、要求、設計は自己組織的なチームから生み出されるとされる。

アジャイル開発のプロジェクトの開始時に、目的、範囲、優先順位、リスク、体制などを「我々はなぜここにいるのか」などの10の問いに答える形で整理し、関係者の認識をそろえるための資料。プロジェクトの途中でも見直して、目的や前提のずれを確かめるのに使う。

良いユーザーストーリーが満たすべき6つの性質の頭文字。独立している（Independent）、交渉可能である（Negotiable）、価値がある（Valuable）、見積り可能である（Estimable）、小さい（Small）、テスト可能である（Testable）を指し、ストーリーの書き方や分割の目安にする。