佃さん、上手＠データ通信システムです。
ちょっとコメントさせて下さい。
On Thu, 18 May 2000 09:33:46 +0900
佃 軍治 <tsukuda@....jp> wrote:
>
> 佃です。
>
> ２５章の抄訳を送付します。
> 意訳している箇所がかなりあります。
> 間違いの指摘、コメントなど、お願いします。
>
> Chapter 25 When You Shouldn't Try XP
>
> ＜私の思い込みによるまとめ＞
> XPを行うべきでない場面を説明している。
> ・ 企業風土 軌道修正を認めない 大量の仕様書を望む 残業に
> よる企業への忠誠心
> ・ 規模 ２０人以上ではだめ。１０人なら可能。
> ・ 技術 simplestを実施できない技術
> ・ 開発環境（マシン） １日数回のインテグレーションができない
> 環境、重要なテストが１日で終了しない環境
> ・ 開発環境（部屋） ペアプログラミングをする２人が快適に過ご
> せることができない空間
>
> 最後から２番目の段落の意図が今ひとつわかっていません。（英
> 語がちゃんとわかっていない）
> 大規模システムを開発する場合には、XPは適用できないものなの
> でしょうか？ コンポーネント分割までは少数精鋭チームで実地
> し、各コンポーネントのインタフェースをきっちり決めておき、分
> 割後はコンポーネント毎にチームを構成し、その中でXPを実践すれ
> ば、うまくいくのでしょうか？
> ２０人以上ではだめ、と真っ向から否定されると困ってしまう。
> XPと大規模システム開発について記述している資料があるのであれ
> ば、誰か教えて下さい。
>
> ＜タイトル直下の要約部分の全訳＞
> XPの正確な制約はクリアではない。しかしＸＰの動作を妨げる明
limit は制約？ 限界では？
> 白なショーストッパは存在する。それは大きなチーム、信用しない
distrustful は私は＊疑い深い＊と訳します。好みの問題ですが・・
> 顧客、礼儀をわきまえた変更(graceful change)を支援しない技術
> である。
gracefulはどういう意味なんですかね？ 優雅？
Smalltalkの開発環境のバージョン管理、変更管理機能を言っていると
思うんですが。
>
> ＜本文抄訳＞
> ＸＰプロジェクトを失敗に導く、時間、場所、人、顧客が存在す
> る。それらのプロジェクトにＸＰを使用しないことが重要である。
> ＸＰプロジェクトの成功への一番大きな障壁はカルチャーであ
> る。国のカルチャーは影響を与えるが、もっと問題なのはビジネス
> （企業？）のカルチャーである。最初に決めた通りに実施するよう
> に試みようとする(trying to pointing the car in the right
> directionの意訳)プロジェクトを実行しているビジネスは、度重な
> る軌道修正(steering)を主張するチームともめるでしょう。
> 「最初にきめた通りに実施(pointing the car)」の変形は、大量
> の仕様書である。顧客やマネージャがプログラミングを開始する前
> に完全な仕様書や分析、設計を主張すれば、チームのカルチャーと
> 顧客、マネージャーのカルチャーとの間に摩擦が生じるようになる
> であろう。
> 私は大量の紙を愛する銀行の顧客と働いたことがある。彼らはプ
> ロジェクトの間中、システムを文書化しなければならないと主張し
> た。我々は、機能が少なくなって紙がさらに多くなることを望むの
> であれば喜んで従う、と彼らに言い続けた。我々は一ヶ月の間、
for months ですので、＊何ヶ月も＊だと思います。
> 「文書化」について聞きつづけた。プロジェクトが進行し、テスト
> がシステムの安定化とオブジェクトの意図された使用方法のコミュ
> ニケーションにどれだけ価値があるかが明確になってきたときに、
> 文書化についての意見がだんだん静かになった。最後の方では、開
> 発マネージャの要求は、システムの主要オブジェクトについての４
> ページのイントロダクションだけだった。
> ＸＰにとって有害な別のカルチャーは、「会社への責務」を証明
commitment to the company は、 ＜私の思い込みによるまとめ＞の
通り、「会社への忠誠」とした法が日本語としてはわかり易いと思い
ます。英語だと、約束をしてそれを必ず実現する、というニュアンス
の様ですが・・
> するために、長時間勤務を要求されることである。ＸＰプロジェク
> トにおいて２週間連続の残業はプロセスがうまく機能していない確
> かなサインであり、プロセスを修正すべきである。
> 賢いプログラマは情報の共有（close communicationをこんな風
> に意訳して見ました）と継続的な革新のために「正しく想像する」
> ゲーム("Guess Right" game)というつまらない時間を過ごさなけれ
> ばならない。
この部分は受け取り方が違います。こんな感じに読みました。
自信はありません。
本当にスマートなプログラマでも時々はＸＰでハードな時間を持つ。
時にはスマートな人達も”言い当てゲーム”を密接な情報交換（＃こ
んな訳もありそう）と継続的な改良に交換して、最も厳しい時間を持
つ。
"Guess Right" game というのは、”言い当てゲーム”だそうです。
trade A for B 交換する、と訳しました。
つまり、「”言い当てゲーム”のような込み入った仕事を、close
communication と continuou evolution で乗り切る」意味では
ないでしょうか。
> サイズは大きな問題である。ＸＰプロジェクトは１００人のプロ
> グラムでは運営できない。５０人でもだめである。２０人でもたぶ
> んだめ。１０人であれば確実に可能でしょう。３，４人であれば、
> イテレーション計画ゲームのようなプログラマの調整に関係したい
> くつかのプラクティスを省略できる。開発する機能の量とその開発
> 者の人数は単純なリニアの関係ではない。おおきなプロジェクトで
> は、どのくらいのスピードで開発できるかを調べるため、小さなチ
> ームで一ヶ月ほどＸＰを経験しなければならない。
> スケールに関するおおきなボトルネックは、シングルスレッドの
> インテグレーションプロセスである。シングルインテグレーション
> マシンによって単純に適用するのではなく、どうにかしてこれをよ
> り多くのコードストリームを扱うように拡張しなければならない。
ここは以下に読みました。意味は変わりません。
シングルスレッド インテグレーションはシングルインテグレーション
マシンによって簡単に実現できるが、これを何とかして複数のコード
ストリームを扱うように拡張しなければならない。
> 本質的に指数コストカーブである技術を用いる場合には、ＸＰを
> 用いるべきではない。例えば、Ｎ世代において同じＤＢを用いてメ
> インフレームシステムを開発する場合、将来のある時点でデータベ
> ーススキーマが変更しようと思っても、それまでに開発したプログ
ここは違うように読みました。
データベーススキーマが現在もそして将来もあなたの必要とするその
もの (exactly)であるのが絶対に確実でないのなら、XPを使うべきで
はない。XPはコードをクリーンかつシンプルに保つことに依存する。
もしあなたが200の現存するアプリケーションの修正を避けるために、
コードを複雑なままにしておくなら、XPが最初にもたらした柔軟性は
すぐに損なわれてしまうだろう。
つまり、「沢山APがぶら下がっているのにスキーマ変更が発生するよ
うなシステムではXPを使うな」という内容だと思います。
＃言っていることは同じですね。「スキーマの変更」がある、とだけ
コメントしていると理解して下さい。
> ラムのための変更できないのであれば、ＸＰを使うべきではない。
> ＸＰではコードを常に単純に保つことが重要であるので。
>
> フィードバックに時間がかかる環境もだめ。コンパイルとリンク
> に２４時間かかるのであれば、統合、ビルド、テストを一日に数回
> することが困難になる。重要なテストが一日以下で実行できない環
> 境はだめ。そのような環境では、ソフトウェアの設計を進化させる
> 気がしない。
> 仕切り板がほとんどない大きな部屋で、中央のテーブルにパワフ
cubby は辞典によると「こじんまりした気持ちのいい場所；狭苦しい
場所；潜伏所；押入；引き出し」となっています。
13章 79ページの真ん中に記述がありますが、スペースの外側の方に配
置した、私物や電話（やメール用のパソコン）を置く、個人用スペー
スです。
[XP-jp:00172] XP Chapter 13 Facilities Strategy の解説 を参考
にして下さい。
＃なお、この中の私の以下の記述は cube から連想した誤訳です。
＃周りには、私物や電話を置く＊四角いコーナ＊を置く。
> ルなマシンがある環境は、私が知っているベストの環境である。
> 個々の部屋に仕切られていても、１つの部屋で２人が快適に過ごせ
> るのであれば、その環境でもよい。
> ２つのフロアにプログラマを抱えるのであれば、それを忘れなさ
> い。１つの部屋で広範囲に分離されたプログラマを抱えるのであれ
> ば、それを忘れなさい。制限されたインタラクションのみで関係す
> るプロジェクトで働く２つのチームを抱えるのであれば、それも可
>能でしょう。私なら、最初のリリースでは１つのチームで実施し、
ここには、「地理的に分かれている」、という表現が抜けてますけど。
（では）
> それからアプリケーションの自然なラインに沿ってチームを分割
> し、各部分を成長させるでしょう。
> 最後に、赤ちゃんが叫んでいるような部屋でXPは絶対にうまく機
> 能しません。これについては私を信じなさい。
>
>
>
> --
> 佃 軍治 tsukuda@....jp
> 日立製作所システム開発研究所第２部
>