Index: [Article Count Order] [Thread]

Date:  Wed, 12 Apr 2000 10:08:57 +0900
From:  Yutaka Kamite <y-kamite@....jp>
Subject:  [XP-jp:00187] Re: XP 10章: A Quick  Overview 訳案
To:  extremeprogramming-jp@....jp (extremeprogramming-jp ML)
Message-Id:  <4.0.2-J.20000412094456.02b7b620@....jp>
In-Reply-To:  <38F2F7F2.8B7B8B3F@....jp>
References:  <4.0.2-J.20000407132206.02cd9ed0@....jp>
Posted:  Wed, 12 Apr 2000 10:11:40 +0900
X-Mail-Count: 00187

上手です。

At 19:01 00/04/11 +0900, you wrote:
> 
> 佃@原書発注中です。
> 
> 質問とコメントを書きます。
> 
> 
> メタファーとアーキテクチャの関係がよくわかりませんでした。
> メタファーそのものも、よくわかってません。
> メタファーとは具体例で説明することでしょうか?
> メタファーはアーキテクチャに代わるのもでしょうか?

メタファーについては、実は私もよくわかりません。
実際のアーキテクチャのわかりやすくするような例えだと思うのですが・・・
具体例を見つけたら、報告します。

とりあえず11章から関連情報を引用します。

-------------------
◇メタファー(例)
・プラクティスの中でmataphorが効いているか実コード、実テストで実際にフィ
ーバックされる。
・顧客は、metaphorの用語で会話するのを好む。
・metaphorの意味の理解をリファクターする。

◇ペアプログラミング
・metaphorがあるので、ネーミングやbasic designで勝手なことをしない。
-------------------

> 
> 
> > 
> > ●テスティング
> > 自動化されたテストの無いプログラム機能は存在しない。プログラマは、
> > プログラムの動作についての自信がプログラムそれ自身の一部になる
> > ことができるように、単体テストを書く。顧客も、プログラムの動作につい
> > ての自信がプログラムの一部になることができるように、機能テストを書
> > く。その結果、プログラムは時間が経過するにつれ、より満足のいくもの
> > になる−変化をより多く、より少なくではない、受け入れることができるよ
> > うになる。
> > あなたの書いたそれぞれのメソッドについて、テストを書く必要は無い、
> > 止まる可能性のある生産メソッドだけで良い。
> 
> テストは誰が書くのでしょうか?
> XPでは、メソッドを追加したときに開発者が単体テストのコード
> も書くと思っています。
> これは、メソッドの内部ロジックを変更した場合の話でしょうか?

単体テストは、開発者がコーディングの前に書き、プロジェクト内にいる顧客
が機能テストを書くようです。 

> > 
> > ●リファクタリング
> 
> 開発者は、常によりよい構造にしておけば、修正が楽になることは
> わかっているんですよね。
> でも、ついつい目先の内部リリースなどの納期の圧力に屈してしま
> う。
> この部分だけ取り入れようとしても、強力なプロジェクト管理者が
> いないと、なかなか実現しない。
> ペアプログラミングなどの他のプラクティスも導入する必要があり
> ますね。

まとめていてつくづく思うんですが、XPは思想ですね。ですから全ルールを
採用するか何も採用しないかの選択になりそうです。
合理的な判断にもとづいて運営ルールをガラッと変えられる組織なら採用
できそうですね。
アメリカでは生命保険会社などの大企業での採用が始まっているようです
が、すごいですね。

> 
> > 
> > ●ペアプログラミング
> > 全ての生産コードは二人で、一つのマシン、一つのキーボード、一つの
> > マウスを使って書かれる。
> > それぞれのペアには二つの役割がある。パートナーの一人、キーボード
> > とマウスを使っている人はこのメソッドを実装する最も良い方法を考える。
> > 別のバートナーはより戦略的に考える:
> 
> この方法、採用してみたい。
> 実装で熱くなっている側に、冷静に検討している人がいれば、熱く
> なっている人の暴走を止めることが出来る。
> ペアプログラミングは一見無駄なようだが、たくさん利点がありそ
> う。無駄のように見える部分のコストと利点により削減できるコス
> トを比較した資料ってないのかなあ。
> 

これでコーディングしていたら集中が激しくて、夕方になったら疲れ切っていて
残業なんかとてもできないかもしれないですね。

(では)

> > 
> > ●継続的インテグレーション
> > 2、3時間から最大でも1日の開発の後、コードは統合されテストされる。
> 
> 最大で一日でしたか。すごい。
> 
> > 
> > ●週40時間
> > 私は毎朝フレッシュで意欲に満ち、毎晩疲れていて満足していたい。金
> > 曜日には、疲れていてたっぷり満足していたい、土日の2日間を仕事以
> > 外のことについて考えられるように。そして月曜日には火の玉(fire)と沢
> > 山のアイデアに満ちて戻って来たい。
> 
> 残業、休日出勤で疲れた人間が集中して仕事できる分けがないのだ
> から、是非ともこうしたいものです。
> しかし、現実のプロジェクトマネージャは「残業、休日出勤なし」
> などと口が裂けても言えない、、、、
> いつもでなくてもいいから、たまには宣言してほしい。
> 
> #ちなみに私は過酷な労働はしていません。
> 
> -- 
>   佃 軍治  tsukuda@....jp
>   日立製作所システム開発研究所第2部
>