上手＠データ通信システムです。
第20章 Retrofitting XP の要約です。
やまの さんの指摘を反映して修正しました。
コメントお願いいたします。
新しいことはほとんど出ていませんので、テストと設計だけ詳しく紹介しました。
-----------------------------
Chapter 20 Retrofitting XP
ＸＰへ模様替えする
この章では、生産している（＃ in production の訳がいまだに不明。実使用さ
れているかな？）ソフトウェアを開発している既存のチームでどうやってＸＰを
採用するかを、各分野について述べています。
＜テスト＞(Testing)
既存コードからＸＰにシフトする時、テストが一番いらいらする分野だろう。
ＸＰのテストを持つ前のコードは恐ろしい。自分がどこにいるのかもわからない。
この変更が安全かどうかも判らない。しかしテストを書きだせば状況はすぐ変わ
る。新しいコードは信頼できる。変更を嫌がらなくなる。実際、それは面白い。
古いコードと新しいコードの間をシフトすることは夜と昼のようだ。自分が古い
コードを避けていることに気づくだろう。この傾向を抑えなければいけない。こ
の状況の中でコントロールを得る唯一の方法は、全部のコードを明るいところに
出すことだけだ。とにかく、醜いものは暗闇で成長する。大きさのわからないリ
スクを抱えることになる。
この状況だと、前に戻り既存の全てのコードについてテストを書きたくなる。し
かし、これをやってはいけない。代わりに、必要によりテストを書く。
・テストされていないコードに機能を追加する時に、現在ある機能についてのテ
ストを先に書く。
・バグをフィックスする必要がある時に、テストを一つ先に書く。
・リファクタが必要な時に、テストを先に書く。
最初は開発が遅くなったと思うだろう。通常のＸＰと比べてより多くの時間をテ
ストを書くのに費やすので、新しい機能を開発するのも前より遅くなったように
感じる。しかし、システムのいつも使う機能、注意が必要な機能や新しい機能は
すぐに徹底的にテストされる。まもなく、システムの良く使われる部分はＸＰで
書かれているかのように感じるようになる。
＜設計＞(Design)
ＸＰへの設計の移行はＸＰへのテストの移行とよく似ている。新しいコードが古
いコードとは全く違っていると気づくだろう。一度に全部フィックスしたくなる
だろう。でも、駄目。一度に少しだけ。新しい機能を追加する時に、先にリファ
クタしよう。ＸＰ開発の実装ではいつもリファクタを先にする準備が出来ている
ものだが、ＸＰの移行に際しては、これをより頻繁に行わなければならない。
プロセスの最初に、チームに大規模なリファクタリングのゴールを認識させよう。
特に絡み合った継承関係があるかもしれない、統一したい機能のかけらがシステ
ム中に散らばって居るかも知れない。ゴールをセットして、それをカードに書き、
沢山掲示しよう。大リファクタリングが終わったと言える時（それには、少しず
つやって何ヶ月か一年かかかるが）は、大パーティを開こう。儀式風にカードを
焼こう。大いに飲み喰いしよう。
この後、「この戦略はテストとほとんど同じだ」という記述があります。内容は
繰り返しなので省略します。
＜計画＞(Planning)
既存の要求情報はストーリーカードに変換しなければならない。顧客にはゲーム
のルールを教育しなければならない。顧客は次回のリリースの内容を決めなけれ
ばならない。
ＸＰ計画にスイッチすることの最も大きな挑戦（であり機会）は顧客に、チーム
からどれだけより多くを引き出せるかを教えることだ。彼らはたぶん今まで要件
変更を歓迎する開発チームなんてお目にかかったことが無いだろう。（だから）
顧客が実際にチームからもっと沢山引き出せるようになるには、少し時間がかか
る。
＜管理＞(Management)
最も難しい移行のひとつはＸＰの管理に慣れることだ。ＸＰの管理は、間接的で
影響を与えるというゲームだ。あなたがマネージャーなら、自分で意志決定はし
ない。しかるべき人に、意志決定をし、その決定を伝えてくれと頼む。
移行の仮定の説明はテスト、設計とほとんど同じで「最初はうまくいかないが段
々・・そして最後はうまく行く」なので、ポイントだけ紹介します。
・ＸＰをやっていなかった時の状況が発生したら、ステップバックして、チーム
にルール、価値、基準を思い出させ、それから何をすべきか決める。
・ＸＰに高速でシフトするためには、チームメンバを消耗（疲れ切る）させない
ことだ。
＜開発＞(Development)
この部分は他の章の繰り返しで新味はありません。ポイントだけ。
・最初にすることは机をちゃんとセットする事だ。二人が横に並べるように。
・ペアプログラミングを厳密に実行すること。
・テストと設計をきちんとこなすこと。コーディング規約に従うこと。
＜トラブル中？＞（in Trouble？)
この部分では、トラブルを抱えてソフトウェアが使われるまで至っていないプロ
ジェクトを、ＸＰに移行することで打開しようとしても成算は無いから止めるよ
うに、と繰り返し述べています。
最後の部分だけ紹介します。
現在のコードベースを慎重に評価しなさい。それが無くてもやっていけますか？
もしそうなら、それを消しちゃいましょう。全部。大きなたき火でテープを燃や
そう。一週間休暇を取ろう。フレッシュでやり直そう。
（以上）