上手＠データ通信システムです。
第22章 の要約です。
コメントお願いいたします。
意訳してあります。
/* 内容的には、あまり新味はありません。この章は冗長です。
ちょっとラフなので、指摘いただければ詳しくします。
ホソカワさんに背中（お尻？）を押されたので、押す側に回りました
*/
-----------------------------
XP Chapter22
Roles for People
人々の役割
重要な警告がある。以下は以前のプロジェクトではうまく機能した役割だ。もし
役割に合わない人がいたら、役割（自身）を変えること。人を替えてはいけない
（もちろんそんなに沢山は）。問題が無いように振る舞ってもいけない。
過去どんなにうまく割り当てが機能していたとしても、もしトラブルが起きたな
ら、（プログラマと顧客のような）重複ロールは問題の原因となりやすいことを
コーチは気づいていないといけない。
＜プログラマ＞
XPプログラマは他のプログラマと表面的には同じに見えるが、実際は全く違う。
・知識の共有
プログラムが動いたらテストを書く
ペアプログラミング
・単純性の習慣
デザインパターンに熟達していても駄目、ツールをいっぱい持っていても駄目。
・技術的なスキル
リファクタリング
単体テスト
・ソースの共同所有権
・自分の怖れを認識すること
誰もが怖れる
ごみの山を見ること
全く役に立たないもの
陳腐化すること
十分良くはない
勇気なしにはXPは機能しない。失敗しないことに時間を使うのではなく、チーム
の助けを受けて怖れを認識する。素晴らしいソフトウェアを書くことに喜びを見
出すチームに属し、ビジネスとうまくやっていこう。
＃この辺りがXPの良いところですね！
＜顧客＞
プロジェクトに影響する、しかしコントロールはできない
意志決定をする
＃冗長ですが、面白かったので。
顧客は、約束したことの半分しか納入されず、納入された残りも半分は駄目とい
うITに慣れていた。どっちにしろ失望するんだから、ITに一インチも譲らないよ
うになった。XPはこういう顧客にはうまく機能しない。
ストーリーを書く
最初は難しく感じるが、ちょっと書いてみればチームがフィードバックをくれる
ので、何をストーリーに含め、何を除くかすぐ判るようになる。
機能テストを書く
ゴールはこう言えるテストを書くこと。「これが走れば、システムは走ると思う
よ」
勇気を示す
＜テスター＞
顧客が機能テストを書くのを助ける
機能テストが統合スーツにはいっておらず自動化されていなければ、定期的に走
らせ、結果をしかるべき場所にポストする。
XPのテスターはシステムをブレイクさせ、プログラマに恥をかかせるための専門
の、別の人ではない。しかし、誰かが全てのテストを定期的に走らせ、結果を皆
に伝え、テストツールがうまく動くようにしなければならない。
＜トラッカー＞
トラッカーはチームの良心である。
見積もりのフィードバックのループを閉じる。例えばこう言う。
「前回の見積もりの2/3は、最低50％高すぎた」
「君のタスク見積もりは高すぎるか低すぎるかのどちらかだ」
全体的な進捗も監視していて、チームに報告する必要がある。
チームの歴史家でもある。
・機能テストのスコアのログ
・報告された欠陥について
ログ
誰が欠陥に対する責任を了承したか
各欠陥に対してどのテストケースが追加されたか
必要とされるスキルは、全プロセスを必要以上に妨げず、必要とする情報を収集
する能力だ。
＜コーチ＞
プロセス全般に責任を持つ。
最も難しいのは、間接的に働くことが、一番効果があるということ。直接指示を
出さず、自分で解決するように持っていく。
コーチに必要なスキル
・シンプルデザイン
・リファクタリング
・テスト
しかし、チームがこの能力を持っているなら、必ずしも必要ではない。
また、チームが成熟するに連れ、コーチの役割は小さくなる。
＜コンサルタント＞
XPではペアプログラミングにより、一人か二人しかシステムを理解していないと
いうブラックホールが発生する機会はまず無い。
しかしこれは同時に弱点でもあり、時としてチームが深い技術的知識を必要とす
ることもある。
この時がコンサルタントの出番だ。
彼らに問題の解き方を教え、実際に解いてみる。
しかし、問題が解けると、彼らは教えを放り投げてしまうが。
＜ビッグボス＞
チームがあなたに求めているもの。
・勇気
・自信
・「やると言ったことしか出来ないんだ」と時々主張すること
＃やると言わないことは出来ない、という意味か？
彼らのすることを見ていて、何かおかしいことがあれば質問する。答がおかしけ
れば、止めさせる。必要な時に的確に動き、必要でない時は口を出さない。
（以上）