|
XP（エクストリームプログラミング）の概要
エクストリームプログラミング（Extreme Programming＝略してXPとされる）とは、Kent Beck氏らが考案・提唱しているソフトウェア開発手法。
アジャイルソフトウェア開発手法と総称される一連の手法の先駆けとなったもの。
アジャイルソフトウェア開発の考え方、特徴としては以下のようなもの。
・ソフトウェア要求仕様の変更などの変化に対して機敏に対応する
・初期段階の設計よりもコーディングとテストを重視する
・ドキュメントよりもソースコードを重んじる
・各工程を段階的に進めていくより、常にフィードバックを行って修正・再設計していくプロセスを重視する
XP開発チームが共有すべき4つの価値
価値という言葉はわかりにくく、私個人は「意識して進める4つのポイント」という解釈をしています。
(1).顧客と開発者の、もしくは開発者間の円滑な「コミュニケーション」(communication)
(2).必要最小限の設計しか行わない「シンプルさ」(simplicity)
(3).頻繁なテストによる「フィードバック」(feedback)
(4).大胆な設計変更に立ち向かう「勇気」(courage)
XP開発チームが行うべきプラクティス（実践項目）
エクストリームプログラミングが話題になっていた当初は「12のプラクティス」とされていたが、数度の改定を得て変化。
対象者の立場ごとに4種類（共同・開発・管理者・顧客）に分類され以下のようになっている。
エクストリームプログラミングのプラクティス（実践項目）
| 対象者 |
プラクティス |
解説 |
共同 |
反復 |
開発を反復（設計・実装・テストを繰り返す小さなサイクル）から構成する。
全体の開発期間はイテレーションと呼ぶ1〜2週間の短い期間に区切り、イテレーションごとに部分的な設計・実装・テストを行い、半完成品システムのリリースを繰り返す。
またより小さな単位の単体機能の実装も、コード修正とテストの繰り返しによって進める。
このように反復によって、徐々に完全なシステムを構築していく手法を取る。
このことで、リスクを最小限に抑えつつ、イレギュラーな変更に対応した開発が可能になる。
|
| 共通の用語 |
用語集を作成し、チーム全員（開発者・管理者・顧客）の使用する用語とその概念の不一致を解消する。
|
| 開けた作業空間 |
会話しやすく、作業に打ち込める雰囲気を作る。
|
| 回顧（頻繁な振り返り） |
現在の状態を明確に把握しつつ、過去のフィードバックを迅速に反映させるよう心がけ、そのための環境・体制を構築しておく。
|
開発 |
テスト駆動開発 |
実装を行うより先に、自動化されたユニットテストないしは手順の明確化されたテストを作成する。
実装はそのテストをパスすることを目標に行う。
ユニットテストを先に作成することで、求める機能が明確化され、シンプルな設計が可能になる。
テストはユニットテスト（ホワイトボックステスト）と受け入れテスト（ブラックボックステスト）からなる。
受け入れテストも自動テストであることが推奨される。
自動化されたテストが、コードの共同所有・リファクタリング・頻繁な結合を可能にし、開発が進むにつれ変更コストが増大することを防ぐ一因となる。
|
| ペアプログラミング |
二人一組で実装を行い、一人が実際のコードを書き、もう一人はそれをチェックしながらナビゲートする。
この役割を随時交代しながら作業を進める。
これによって、細々した問題解決に要する時間が短くなる、常にコードレビューを行うことができる、集中力が持続する、コードの詳細を理解したメンバーが常に2人以上いることで後々のコード共有に役立つ、などの多彩な効果が得られる。
|
| リファクタリング |
完成済みのコードでも、随時、改善処置を行う。
この際、外部から見た動作は変更させずに、内部構造がより見通し良く優れたものになるようにする。
テストが作成されていることが前提になる。
|
| ソースコードの共同所有 |
誰が作ったソースコードであっても、開発チーム全員が断り無く修正を行うことができる。
ただし、全てのコードに対する責任を、全員が担う。
|
| 継続的インテグレーション |
単体テストをパスするコードが完成するたび、すぐに結合テストを行い、問題点や改善点を探す。
少なくとも一日に一回は、結合テストを行う。
また、全体のコンパイルおよび自動テストを行うための継続的インテグレーション用のコンピュータを準備することが推奨されている。
|
| YAGNI |
You Aren't Going to Need It（今必要なことだけ行う）。
先の事を考えて、前払い的に機能を増やし、実装を複雑化させる事は避ける。
むしろ無駄な機能があれば削りとり、今必要な機能だけのシンプルな実装に留めておく。
このことで後のイレギュラーな変更に対応しやすいようにする。
必要なコードは先回りして書くのではなく必要になったときに書くという意味である。
|
管理者 |
責任の受け入れ |
|
| 援護 |
|
| 四半期毎の見直し |
|
| ミラー |
今どういう状態かをチームに知らせる。
|
| 最適なペースの仕事 |
知的作業には週40時間の労働時間が最適である。
特にXPでは、集中力を高めて効果を生む事を重視しているため、心身ともに健全な状態を保つ必要があり、それ以上の労働は適さない。
そのため、計画的に開発スピードの調整を行う。
|
顧客 |
ストーリーの作成 |
求める機能のコンセプトを短い文章で記したストーリーカードを作成する。
そのカードをもとに、開発者・管理者を含めたチームとのミーティングを行い、詳細を決定する。
|
| リリース計画 |
どのストーリーをどのイテレーションの対象とするか、チームミーティングで主体となって提案し、合意の上で最終的な承認を行う。
|
| 受け入れテスト |
イテレーションごとに顧客の立場からテストを行い、ストーリーが実現できているか、望むシステムになっているか確認する。
もし満足できない場合は、それを指摘する。
|
| 短期リリース |
|
注意事項：
技術情報ページに記載している内容は、フェローシップ代表者がいろいろなメディアや誌面などから収集した情報を自分なりの解釈で整理したものとなっています。内容に誤りがないとも言えませんので、参考にされる方は自己責任でお願いします。
|
