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

読書

３章


長い章ので数日に分けて追記していきます。

XPを理解する

  • XPには要件・設計・テストという段階的なフェーズがない。　※１
  • チームのオンサイト顧客がプロジェクトの方向性を管理する。
  • 設計とコーディングはTDDで行う。　※２
  • ペアプロを行う。　※３
  • バージョン管理システム、自動ビルド＆テストツールを導入する。
  • 各イテレーションの終わりにソフトウェアを導入（リリース）する。

所感＆補足

※１　たとえばプロジェクトの納期が１年だとするとウォーターフォールは１年全体に計画・分析・設計・開発・テスト・導入を割り当てる。XPでは１〜３ヶ月の短いイテレーションの中でそれら全てをほぼ同時に行い、繰り返す。大事なのはXPが要件・設計・テストを軽視しているわけではないということ。大事だという認識があるから常に行う。（それは要件を把握している顧客がチームにいるから可能になる？）

※２　TDDで書くテストと品質テストは別物。チームにはコーダーとは別にテスターがいて、テスターが品質の観点で調査する。

※３　ペアプロは問題を発見しやすくなる、問題を複数人で共有できる、誰でもコードを修正しやすくなるなどの利点がある。

ここまで読んでXPの壁のひとつに「会社でXPを行うための環境構築」が大変なこととして挙げられるのではないかと思いました。
チーム編成については人事を動かす権限がある方（部長など）がXPに対して好意的に理解している必要があると思います。
開発者の中にもTDDや自動テスト、もちろんXP自体に精通した開発者が１人は必ず必要だと思います。
技術的な環境構築は簡単に出来ても、人間的な環境構築はそう簡単にはできなそうです。