概要
アジャイル開発のうちXP（エクストリームプログラミング）に関して非常に具体的に記載されているリファレンス的な書籍です。自分は「エッセンシャルスクラム」をスクラムのリファレンス的な書籍として手元に置いて活用しているのですが、そのXP版という印象を受けました。
自分は業務ではスクラムのプラクティスを中心に運用していたことが多かったのですが、時々XPのプラクティスを取り入れたり議論したりすることがあったため、一度XPに関してもきちんと学んでおこうと感じて手に取ったのが経緯です。
XPとスクラムの相違点
基本的にXPでもスクラムと同じプラクティスや概念が出てきます。
例えば
- （XP）ふりかえり・・・（スクラム）スプリントレトロスペクティブ
- （XP）スタンドアップミーティング・・・（スクラム）デイリースクラム
- （XP）イテレーションデモ・・・（スクラム）スプリントレビュー
などです。
一方で、XPで特徴的なのが、
- ペアプログラミング
- リファクタリング
- 継続的インテグレーション
などの技術的なプラクティスだと思います。
エンジニアにとっては、スクラムよりXPの方が導入しやすいと感じることが多いそうなのですが、これが理由なのかもしれません。
スクラムはスプリント計画やスプリントレビューなどの「セレモニー」を重視する一方で、このような技術的なプラクティスはあまり提唱されていません。個人的には、プロセスのスクラム、技術的プラクティスのXP、という印象を持っています。
なお、本書ではどの章でも最後に「質問」という形でQ&A形式でよくある質問と回答が記載されています。これがかなり便利でした。
継続的インテグレーション
スクラムを実践していて不思議だったのが、Devは開発したプロダクトをスプリント中にPOに確認してもらうこと、POはプロダクトバックログのクライテリアを達成している事を常に確認すること、というものです。
何が不思議かというと、POはプログラムのエキスパートではありません。そのため、もしPOがDevからデモを受けずにプロダクトを確認するとしたら、POは実行環境を持っていなくてはならない、ということです。そんな環境をPOが準備できるのでしょうか？
答えは簡単で、継続的インテグレーション（CI）および継続的デプロイ（CD）環境をあらかじめ構築しておくことでした。本書には、この継続的インテグレーションがXPのプラクティスとして記載されています。また、この前提として
- バージョン管理システム
- 10分ビルド
が必要だと述べられています。10分ビルドは文字通り自動的にビルドできる環境構築のことです。
ちなみに本書ではバージョン管理システムとしてTortoiseSVNとSubversionが記載されているのですが、自分がEclipseでJavaプログラムを書いていた時はまさにこの構成でした（今ならGitでよいと思います）。
また、10分ビルドとしてJavaならAntと紹介されていたが、これも自分が利用していたため、なじみがありました（利用していた時はこれがXPのプラクティスの神髄だなんて思いもしませんでした）。
CI/CD環境の構築は、機能開発のように直接的なメリットを生み出すものではないため、優先順位が下げられがちだと思います。ですが、このような環境構築が出来ていないと後になって手戻りが発生したり、上述のようにPOがプロダクトを確認できないということが発生しがちであるため、出来ればスプリント開始前に準備しておきたいところです。
コメント