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