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