ホソカワです。すごい！上手さん、大変だったでしょう。「＃」を付けた箇所に対し
てコメントします。
on 2000/04/07 1:30 PM, Yutaka Kamite at y-kamite@....jp wrote:
> 上手＠データ通信システム です。
> 訳案をつくりました。コメントよろしくお願い致します。
> ＃●、◇が機種依存文字でしたら、次回修正で直します。
> ＃化けていたら教えて下さい
>
マックのアウトルックエクスプレスでは、問題なく表示されています。
> １０章 クイックオーバービュー
…
>
> 技術者は以下について決定する必要がある。
> ◇見積り
> −一つの機能を実装するのにどれだけかかるか
> ◇結果（＃重要性かもしれない）
結果でいいと思います。（いや、帰結かな？）
> −技術的な結果を知らされていないと戦略的なビジネス決定は出来ない。
> データベースの選択が良い例だ。スタートアップ（ベンチャー）企業の方が
> 巨大会社ビジネスはうまく行くかもしれない。しかし、生産性にの要素２
> （＃？）は余分なリスクとそれに相当する不満を引き起こすかもしれない。
「factor of 2」は、「２倍」のことです。「生産性が２倍に上がるのであれば、余
分なリスクや辛さは我慢できるでしょう。」と言っていると思います。
> そうではないとしても、開発は重要性を報告する必要がある。
> ◇プロセス
> −どのように業務とチームは組織されるのか？ チームは仕事をするた
> めの文化（カルチャー）をつくらないといけないが、今の文化に組み込ま
> れている非合理性を保つより、良いソフトウェアを書くべきだ。
> ＃今のカルチャーにとれわれず、ゼロからやりやすいものを考えよ。
> という意味かな？
>
そうですね。今のカルチャーにとらわれず、いいソフトウェアを書きましょう。
…
> ●テスティング
> 自動化されたテストの無いプログラム機能は存在しない。プログラマは、
> プログラムの動作についての自信がプログラムそれ自身の一部になる
> ことができるように、単体テストを書く。顧客も、プログラムの動作につい
> ての自信がプログラムの一部になることができるように、機能テストを書
> く。その結果、プログラムは時間が経過するにつれ、より満足のいくもの
> になる−変化をより多く、より少なくではない、受け入れることができるよ
> うになる。
> あなたの書いたそれぞれのメソッドについて、テストを書く必要は無い、
> 止まる可能性のある生産メソッドだけで良い。
> ＃以下、意味不明。何がいいたいのでしょうか？
> いつか、何かが可能か見つけたくなるだろう。３０分探す。可能だ。さあ
> コードを離れ、またテストを始めよう。
>
「時には、取り敢えず、試してみましょう。３０分ぐらい模索してはどうでしょうか？
試してみたら、うまく行きました。それじゃ、今書いたコードは捨てて、まず、テス
トから書きましょう。」期間の短いプロトタイピングでしょうか？
…
>
> ●集合的所有権
「Collective Ownership」は、「共同所有権」ではないでしょうか？「コードはみん
なのもの。」ということですよね？
…
> （ここまで）
> ---
> オリジナル http://www.xprogramming.com/
> Copyright (c) 1999, REJeffries et al. (ronjeffries@....org)
>
オリジナルはKent Beckですね！
--
Kaoru Hosokawa
khosokawa@....com