アジャイルソフトウェア開発(agile software development)は、迅速かつ適応的にソフトウェアを開発する軽量な開発手法群の総称である。
XPはその中の一つ。
XPには、開発チームが行うべきいくつかのプラクティス(習慣、実践)が定められている。これらのプラクティスを実行することが、XPを実行することと言える。
初期では12のプラクティスがあったが、数度の改定を得て数が増え、対象者の立場ごとに4種類に分類されるようになった。しかし本質的には変化することなく、その内容をより理解しやすくするための改定となっている。
■■■共同のプラクティス■■■
[反復]
開発を反復から構成する(⇒反復型開発)。全体の開発期間はイテレーションと呼ぶ1~2週間の短い期間に区切り、イテレーションごとに部分的な設計・実装・テストを行い、半完成品システムのリリースを繰り返す。またより小さな単位の単体機能の実装も、コード修正とテストの繰り返しによって進める。このように反復によって、徐々に完全なシステムを構築していく手法を取る。このことで、リスクを最小限に抑えつつ、イレギュラーな変更に対応した開発が可能になる。
[共通の用語]
用語集を作成し、チーム全員(開発者・管理者・顧客)の使用する用語とその概念の不一致を解消する。
[開けた作業空間]
会話しやすく、作業に打ち込める雰囲気を作る。
[回顧(頻繁な振り返り) ]
現在の状態を明確に把握しつつ、過去のフィードバックを迅速に反映させるよう心がけ、そのための環境、体制を構築しておく。
■■■開発のプラクティス■■■
[テスト駆動開発 ]
実装を行うより先に、自動化されたテストないしは手順の明確化されたテストを作成する。実装はそのテストをパスすることを目標に行う。テストを先に作成することで、求める機能が明確化され、シンプルな設計が可能になる。
[ペアプログラミング ]
二人一組で実装を行い、一人が実際のコードを書き、もう一人はそれをチェックしながらナビゲートする。この役割を随時交代しながら作業を進める。これによって、細々した問題解決に要する時間が短かくなる、常にコードレビューを行うことができる、集中力が持続する、コードの詳細を理解したメンバーが常に2人以上いることで後々のコード共有に役立つ、などの多彩な効果が得られる。
[リファクタリング]
完成済みのコードでも、随時、改善処置を行う。この際、外部から見た動作は変更させずに、内部構造がより見通し良く優れたものになるようにする。テストが作成されていることが前提になる。
[ソースコードの共同所有]
誰が作ったソースコードであっても、開発チーム全員が断り無く修正を行うことができる。ただし、全てのコードに対する責任を、全員が担う。
[継続した結合]
単体テストをパスするコードが完成するたび、すぐに結合テストを行い、問題点や改善点を探す。少なくとも一日に一回は、結合テストを行う。
[YAGNI]
You Aren't Going to Need It(今必要なことだけ行う)。先の事を考えて、前払い的に機能を増やし、実装を複雑化させる事は避ける。むしろ無駄な機能があれば削りとり、今必要な機能だけのシンプルな実装に留めておく。このことで後のイレギュラーな変更に対応しやすいようにする。
■■■管理者のプラクティス ■■■
[責任の受け入れ]
[援護]
[四半期毎の見直し]
[ミラー]
[今どういう状態かをチームに知らせる。]
[最適なペースの仕事 ]
知的作業には週40時間の労働時間が最適である。特にXPでは、集中力を高めて効果を生む事を重視しているため、心身ともに健全な状態を保つ必要があり、それ以上の労働は適さない。そのため、計画的に開発スピードの調整を行う。
■■■顧客のプラクティス■■■
[ストーリーの作成 ]
求める機能のコンセプトを短い文章で記したストーリーカードを作成する。そのカードをもとに、開発者・管理者を含めたチームとのミーティングを行い、詳細を決定する。
[リリース計画 ]
どのストーリーをどのイテレーションの対象とするか、チームミーティングで主体となって提案し、合意の上で最終的な承認を行う。
[受け入れテスト ]
イテレーションごとに顧客の立場からテストを行い、ストーリーが実現できているか、望むシステムになっているか確認する。もし満足できない場合は、それを指摘する。
[短期リリース]
これらの個々のプラクティスが、お互いを補いあい補強しあう事で、XPという一つの方法論を成り立たせている。
しかし、ソフトウェア業界の現状においては、この全てのプラクティスを同時に実行することは非常に困難であるため、テスト駆動開発やリファクタリングなど、単独でもある程度有効なプラクティスだけが、一部導入されているケースが多い。