ホソカワです。
なるべく、訳さないように解説をします。
Management Strategy
===================
プロジェクト管理を、マネージャー、一人に任せるのは良くないし、かといって、ひ
とりひとり好きなことをやってもうまくいきません。この章では、XPのプロジェクト
マネージャーはどのように行動すれば良いかが書かれています。
まず、Principles から導かれるマネージャ像を説明しています。
・Accepted responsibility − マネージャーは、仕事の割り当てを行わずに、プロ
グラマ自ら手を上げて仕事を請け負ってもらう。
・Quality work − 質の高い仕事をするには、マネージャーはプログラマーを信じる
こと。「もっといい仕事をさせるにはどうすればいいのだろう。」と考える。
・Incremental change − 定期的に指示を小出しします。
・Local adaptation − ローカルな環境（文化）に馴染ませようとします。
・Travel light − プログラマーの重荷になるようなことは避けます。例えば、長い
全体会議とか。
・Honest measurement − 現実的な評価をします。（秒針のない時計で秒単位のデー
タをとっても無駄です。）
Metrics
-------
メトリックは、マネージメントの基本です。例えば、見積もった開発期間と実際にか
かった開発期間の比率は Planning Game の基本です。このようなメトリックは、大
きな目立つチャートで定期的に掲示します。だれも読まないメールはだめです。メト
リックはたくさんあってもだめです。３、４個が適当です。メトリックが100%達成に
近付いてきたら、それを捨てて、新しい尺度から評価しましょう。
ただ、「数字だけで管理できる。」といっているわけではありません。
Coaching
--------
一般的に「コーチ」というと lead programmer とか system architect を採用しま
すが、XPのコーチは違います。XPでのコーチの役割は、
・開発パートナーになること。特に新人の相手になること。
・長期的な refactoring goal に向かって、短期的な refactoring を促進すること。
・プログラマーのスキルの向上を手伝うこと。
・上層部にプロセスの理解を求めること。
一番大切な役割は、チームにおもちゃやおかし（食べ物）を与えることです。クライ
スラーの C3 プロジェクトで、実際にキッチンタイマーを使用したわけではありませ
んが、その存在だけでミーティングの時間厳守ができました。同じ釜の飯を食べたも
の同士には、何か秘めたパワーがあるようです。食べながら話すと、まったく違った
議論ができます。
Tracking
--------
現状を把握して、見積もりの評価をしましょう。データを集める時は、プログラマー
に負担がかからないように心掛けましょう。
Intervention
------------
このまま進んでも解決できない問題が発覚したときなど、マネージャーは、時には干
渉することも必要です。例えば、プログラマーをチームからはずす時、プロジェクト
の方向性を変える時や、プロジェクトを集結する時などです。
[コメント：
いままで、ソフトウェア開発でコーチという言葉を耳にしませんでした。通常、lead
programmerとかですよね？
現在のプロジェクトマネージャーは、XPをマスターすれば、XPのプロジェクトマネー
ジャーになれそうですね。ただ、XPをマスターするのが大変なのかも。
]
--
Kaoru Hosokawa
khosokawa@....com