読者です 読者をやめる 読者になる 読者になる

アート・オブ・アジャイル デベロップメント 社内読書会#3−1

3章


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

XPを理解する

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

所感&補足

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

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

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

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