XPとは
- ソフトウェア品質を向上させ、変化する顧客の要求への対応力を高めることを目的としたソフトウェア開発プロセス。
- スクラムと同じくアジャイル開発手法の一つである。ソフトウェア開発に重きを置いている。
XPにおける価値・プラクティス・原則
XPは価値・プラクティス・原則から構成される。
以下でそれぞれを説明する。
価値
自分たちにとって何が重要かという抽象的かつ普遍的な基準。
XPでは以下の価値を重要視している。
- コミュニケーション
- チーム感覚や協力関係を維持する
- フィードバック
- チームや個人に対するフィードバックに基づき、常に改善を行う
- リスペクト
- チームに対する個人の貢献をリスペクトする
- シンプリシティ
- 無駄を排除するに何ができるかを常に考える
- 勇気
- 上の価値を実践し、チームの一員として効果的に動く勇気
ただ、XPは上の価値を重要だと言いつつ、価値を取捨選択すること・その他の価値を置くことを認めている。
重要なのは、チームのふるまいをチームが重要視する価値に近づけることである。
プラクティス
価値を実現するための具体的な取り組み。状況に応じて必要なプラクティスは異なる。
プラクティス数は、12→24→19と変化している。
(出典:https://slide.meguro.ryuzee.com/slides/96)
ただ、19のプラクティスになった際のドキュメントは見つけられず。
本プレゼンは、24のプラクティスを定義している2nd Editionの区分に準拠する。
プラクティスには大きく分けて二つ存在する。
- 主要プラクティス
- すぐに導入できるもの
- 導出プラクティス
- 主要プラクティスの導入を前提とするもの
(引用:https://slide.meguro.ryuzee.com/slides/96)
原則
分野に特化した活動指針。
価値とプラクティスのギャップを埋める。XPではソフトウェア開発における14の原則を紹介している。
上の原則は以下の書籍に説明されているので、興味があれば読んでいただきたい。
理解のため、原則を一つだけ例示として説明する
- 相互利益
- あらゆる活動は、関係者全員の利益にならなければならない
- 例えば仕様書の作成は、将来の担当者の利益のために現在の担当者の負荷を強いるので、相互利益を破壊する
- そこで、XPでは将来とのコミュニケーションの問題を相互利益になるやり方で解決する
- 現時点で設計や実装がうまくできるような自動テストを書く。
- また、将来のプログラマーも使えるようテストを残す
開発プラクティスの説明
開発プラクティスのうち、主要プラクティスにあたる以下の4つについて説明する。
1. テストファーストプログラミング
コードを変更する前に失敗する自動テストを書くこと。
以下の課題を解決する
- スコープクリープの防止
- プログラミングに夢中になり、余計なコードを追加することを防ぐ
- テストしやすいコードの記載
- コードの意図を示す
2. ペアプログラミング
ペアプログラミングとは、2人でプログラミングとプログラムの改良を同時に行うやり取りのこと。
コードが常にレビューされることになり、コードの欠陥率の減少、コードサイズの減少などの効果が期待される。
以下のことを意識しながら行う。
- お互いのタスクに集中する
- システムの改良について意見を出し合う
- パートナーがはまったら主導権を握り、相手の絶望感を軽減する
- ペアのパートナーはこまめに入れ替える(数時間ごと)
具体的なやり方は以下のページを参考のこと
https://gist.github.com/j5ik2o/2970973
3. インクリメンタルな設計
現時点のシステムのニーズを満たすため必要なシステム設計を行う。
また、システム設計は常にリファクタリングを行い、ニーズの変化に対応する。
4. 継続的インテグレーション
数時間以内に変更箇所を含むソースコード全体をテストするできるにする。(テスト自動化、ビルド自動化)
システムのリリース(デプロイ)が大変にならないようにする効果がある。
【補足】スクラムとの比較
以下のページが参考になる。
http://agile.blog.jp/agile_scrum/14887069.html
【補足】他のAgile手法とXPの取り組みの対応関係
agileallianceでは路線図のような形で、各Agile手法のプラクティスを整理している
(引用:https://www.agilealliance.org/agile101/subway-map-to-agile-practices/)