共同のプラクティス

エクストリームプログラミングで、開発チーム全体が共通して実践する事項。反復、共通の用語、オープンな作業空間などが含まれる。

エクストリームプログラミングで、開発チーム全体が共通して実践する事項。反復（イテレーション）、共通の用語、開けた作業空間、ふりかえりなどが含まれる。

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

エクストリームプログラミング（XP）のプラクティスのうち、管理者が担う事項。チームの成果に責任を持つ（責任の受入れ）、外部の干渉からチームを守る（援護）、四半期ごとの見直し、チームの状況を映し出して伝える（ミラー）、持続可能なペースの維持などが含まれる。

エクストリームプログラミング（XP）のプラクティスの一つで、ソースコードを特定の担当者のものとせず、チームの誰もがどの部分でも修正できるようにすること。特定の人への依存をなくし、改善を素早く行える。

「今必要でない機能は作らない」という、エクストリームプログラミング（XP）の考え方。将来使うかもしれないという予測で機能や仕組みを先に作り込まず、必要になった時点で実装することで、無駄な作業と複雑さを避ける。

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

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