XP Extreme Programming
エクストリーム・プログラミング 比較的少人数の開発にもっとも適用しやすく、19個から なる具体的なプラクティス（習慣・実践）が定義されてい る。 ユーザー要求や使用の変更リスクを軽減するために、 顧客の開発者間のコミュニケーションを重視し、コー ディングとテスト、リファクタリング（コードの書き直し）に 重点を置いて、短期間のリリースを繰り返して開発を進 めていくソフトウェア開発方法論である。 デコーディング テスト 完成 少数人数で 迅速に 顧客 開発者 １～２週間 リファクタリング
原理となる４つの価値 ⅰ.顧客と開発者の、または開発者間の「コミュニケー ション」 ⅱ.必要最小限の設計しか行わない「シンプルさ」 ⅲ.頻繁なテストによる「フィードバック」 ⅳ.大胆な設計変更に立ち向かう「勇気」である。
19個のプラクティス [共同プラクティス] [開発プラクティス] [管理者のプラクティス] [顧客のプラクティス] 反復 共通の用語 反復から開発構成 共通の用語 顧客・開発者・管理者に共通 開けた作業空間 会話しやすく、作業に打ち込める雰囲気を作る。 回顧 現状把握と、過去のフィードバックを迅速に反映できる環境。体制の構築 テスト駆動開発 先にテストすることにより、求める機能が明確化されシンプルな設計が可能になる。 ペアプログラミング 2人1組で実装を行い、一人がコードを書き、もう一人はチェックしながらナビゲートする リファクタリング 完成済みのコードでも、随時、改善処置を行う。テストが作成されていることが前提になる。 YAGNI You Aren't Going to Need It （今必要なことだけ行う） 継続した結合 テストをパスするコードが完成する度、すぐに結合テストを行い、問題点や改善点を探す ソースコードの共同所有 誰が作ったソースコードであっても、開発チーム全員が断り無く修正を行うことができる。 責任の受け入れ 援護 四半期毎の見直し ミラー 今どういう状態かをチームに知らせる。 最適なペースの仕事 週40時間の労働時間。 ストーリーの作成 求める機能のコンセプトを短い文章で記したストーリーカードを作成する。 リリース計画 どのストーリーをいつ行うか、チームミーティングで提案し、最終的な承認を行う。 受け入れテスト 顧客の立場からテストを行い、ストーリーが実現できているか、望むシステムになっているか確認する。 短期リリース リリース計画のもと、短期で実行していく。