アート・オブ・アジャイルデベロップメント　社内読書会＃４−２

「４章 XPを導入する」の続き

エクストリームショッピング

仕事場の必需品がずらっと書いてあります。
以下は、普段のアジャイル開発でヘヴィに使っている、個人的に特に重要と思うものです。

・ビルド専用マシン
・ホワイトボード
・インデックスカード（付箋
・マグネット
・xUnit

ホワイトボードに関してはid:Yamashiro0217さんが「消せる紙」というのを用意してくれていてすごく便利です。
消せる紙 → http://www.obun.co.jp/keserushi/

変化への備え

著者はXPは部分的に、段階的に導入するより全てを一気に導入することを推奨しています。
その方が混乱と不安の時間が短くなるからです。

読書会で出た疑問。
Q.
　まとめて導入することによって難易度が上がらないか。
A.
　まとめて導入しないと効果が薄かったり、段階的に導入していくことで余計に大きくなる混乱もあるだろうからまとめての方が良さそう。
　例：イテレーションだけ導入してふりかえりを行わないのでは効果が薄い。

新規プロジェクトにXPを適用する

最初に顧客はビジョン・リリース計画を立てて、プログラマは技術的基盤を確率する。
技術的基盤＝バージョン管理、自動ビルドツールの導入など。
大部分の時間はチーム作業にあてるべき。

既存プロジェクトにXPを適用する

技術的な負債を支払う大量の時間を取ることが最大の課題。
大変だが最初に負債を支払ってしまう方が長期的に見ればプロダクトの欠陥率・保守性の面で良い。
また、バックログを整理して本物のバグを洗う。

フェーズベースの組織でXPを適用する

ウォーターフォールのような計画-分析-設計-開発-テスト-導入それぞれのフェーズでXPを行う。
長いので詳しくは本で。

断片的にXPを適用する

所感

XPの利点として、オンサイト顧客・プログラマ・テスターが順番に分担して作業するのではなく、
お互いに協調しながら仕事を行うことができるということが大きいということがわかってきました。

例えば、
顧客ｘプログラマ→プログラマの見積もり精度・技術的な観点で顧客は色々な計画を練ることができる。
プログラマｘテスター→プログラマがTDDで開発を行うことによりテスターの負担が減る。品質の高いコードを書く手助けをテスターがプログラマに行うことができる。
顧客ｘテスター→要件漏れがないようにテストケースを考えることができる。品質の高いプロダクトになる。

XPのチーム編成は非常に強力な気がしてきました。
ただやはりチームの大きさはある程度限られてしまうでしょうね。

合わせて読みたい

InfoQ:アジャイルにおけるプロジェクトマネジャーの役割
http://www.infoq.com/jp/articles/project-manager-role;jsessionid=1EDE14DE10E4C6DE2603B38431964185