佃です。
２５章の改訂版を送付します。
上手さん、吉田さん、コメントありがとうございました。
-------------------
Chapter 25 When You Shouldn't Try XP
＜私の思い込みによるまとめ＞
XPを行うべきでない場面を説明している。
・ 企業風土 軌道修正を認めない 大量の仕様書を望む 残業に
よる企業への忠誠心
・ 規模 ２０人以上ではだめ。１０人なら可能。
・ 技術 simplestを実施できない技術
・ 開発環境（マシン） １日数回のインテグレーションができない
環境、重要なテストが１日で終了しない環境
・ 開発環境（部屋） ペアプログラミングをする２人が快適に過ご
すことができない空間
＜タイトル直下の要約部分の全訳＞
XPを実施する上での正確な限界は明確でない。しかしＸＰの動作
を妨げる明白なショーストッパは存在する。それは大きなチーム、
疑い深い顧客、礼儀をわきまえた変更(graceful change)を支援し
ない技術である。
＜本文抄訳＞
ＸＰプロジェクトを失敗に導く、時間、場所、人、顧客が存在す
る。それらのプロジェクトにＸＰを使用しないことが重要である。
ＸＰプロジェクトの成功への一番大きな障壁はカルチャーであ
る。国のカルチャーは影響を与えるが、もっと問題なのはビジネス
（企業？）のカルチャーである。最初に決めた通りに実施するよう
に試みようとする(trying to pointing the car in the right
directionの意訳)プロジェクトを実行しているビジネスは、度重な
る軌道修正(steering)を主張するチームともめるでしょう。
「最初にきめた通りに実施(pointing the car)」の変形は、大量
の仕様書である。顧客やマネージャがプログラミングを開始する前
に完全な仕様書や分析、設計を主張すれば、チームのカルチャーと
顧客、マネージャーのカルチャーとの間に摩擦が生じるようになる
であろう。
私は大量の紙を愛する銀行の顧客と働いたことがある。彼らはプ
ロジェクトの間中、システムを文書化しなければならないと主張し
た。我々は、機能が少なくなって紙がさらに多くなることを望むの
であれば喜んで従う、と彼らに言い続けた。我々は数ヶ月の間、
「文書化」について聞かせれ続けた。プロジェクトが進行し、テス
トがシステムの安定化とオブジェクトの意図された使用方法のコミ
ュニケーションにどれだけ価値があるかが明確になってきたとき
に、文書化についての意見がだんだん静かになった。最後の方で
は、開発マネージャの要求は、システムの主要オブジェクトについ
ての４ページのイントロダクションだけだった。
ＸＰにとって有害な別のカルチャーは、「会社への忠誠」を証明
するために、長時間勤務を要求されることである。ＸＰプロジェク
トにおいて２週間連続の残業はプロセスがうまく機能していない確
かなサインであり、プロセスを修正すべきである。
「正しく想像する」ゲーム("Guess Right" game)の代わりに、情
報の共有と継続的な革新を行うので、賢いプログラマにとって、た
まにＸＰは大変になる。
＃賢いプログラマは普段将来を予測しながらプログラミングしてい
るが、ＸＰではその方法を取らず、普段通りにプログラミングでき
ない、という状況を説明している。
サイズは大きな問題である。ＸＰプロジェクトは１００人のプロ
グラムでは運営できない。５０人でもだめである。２０人でもたぶ
んだめ。１０人であれば確実に可能でしょう。３，４人であれば、
イテレーション計画ゲームのようなプログラマの調整に関係したい
くつかのプラクティスを省略できる。開発する機能の量とその開発
者の人数は単純なリニアの関係ではない。大きなプロジェクトで
は、どのくらいのスピードで開発できるかを調べるため、小さなチ
ームで一ヶ月ほどＸＰを経験しなければならない。
スケールに関する大きなボトルネックは、シングルスレッドのイ
ンテグレーションプロセスである。シングルスレッドのインテグレ
ーションプロセスは、シングルインテグレーションマシンによって
簡単に実現できるが、どうにかしてこれをより多くのコードストリ
ームを扱うように拡張しなければならない。
本質的に指数コストカーブである技術を用いる場合には、ＸＰを
用いるべきではない。例えば、Ｎ世代にお
いて同じＤＢを用いてメインフレームシステムを開発する場合に、
将来においてデータベーススキーマを変更する必要がないと確信で
きないのであれば、ＸＰを使うべきではない。ＸＰではコードを常
に単純に保つことが重要である。もし既存の２００プログラムの修
正を避けるためにコードを複雑にするのであれば、フレキシビリテ
ィがすぐに失われることになる。
フィードバックに時間がかかる環境もだめ。コンパイルとリンク
に２４時間かかるのであれば、統合、ビルド、テストを一日に数回
することが困難になる。重要なテストが一日以下で実行できない環
境はだめ。そのような環境では、ソフトウェアの設計を進化させる
気がしない。
大きな部屋と部屋内の外側に２，３の心地よい場所(cubby)があ
り、中央のテーブルにパワフルなマシンがある環境は、私が知って
いるベストの環境である。個々の部屋に仕切られていても、１つの
部屋で２人が快適に過ごせるのであれば、その環境でもよい。
２つのフロアにプログラマを抱えるのであれば、それを忘れなさ
い。１つの部屋で広範囲に分離されたプログラマを抱えるのであれ
ば、それを忘れなさい。地理的に離れている場合、２つのプロジェ
クトが制限されたインタラクションのみで関係しているのであれ
ば、その環境でもＸＰの適用は可能でしょう。私なら、最初のリリ
ースでは１つのチームで実施し、それからアプリケーションの自然
なラインに沿ってチームを分割し、各部分を成長させるでしょう。
最後に、赤ちゃんが叫んでいるような部屋でXPは絶対にうまく機
能しません。これについては私を信じなさい。
--
Gunji Tsukuda (tsukuda@....jp)
Systems Development Laboratory, Hitachi, Ltd.