Index: [Article Count Order] [Thread]

Date:  Wed, 22 Nov 2000 12:38:42 +0900
From:  Toru TAKAHASHI <tooru6.takahashi@....jp>
Subject:  [XP-jp:01175] IEEE Software 2000	年 7/8 月号の XP 記事
To:  extremeprogramming-jp@....jp (extremeprogramming-jp ML)
Message-Id:  <200011220335.MAA19288@....jp>
Posted:  Wed, 22 Nov 2000 12:35:53 +0900
X-Mail-Count: 01175

高橋です。

ちょっと古いですが、IEEE SOFTWARE July/August 2000に
"eXtreme Programming Development through Dialog" Robart C. Martin
という2ページの短い記事が載っています。
Dialogは「対話」ですね。

読んでて興味を持った個所を簡単に紹介します。
・XPは文書ではなく人に焦点を当てる方法論。人はプロジェクトの最大の
 potent element
・カスタマはプログラマの見積りに対して疑念を抱いたり異議を唱えたり、
 その見積りを反映していない第三者(third parties)に委託してはいけない。
・結局プログラマの見積りを単純に受け入れるカスタマはいないし、カスタマ
 の要求するフィーチャだけを実装するプログラマもいない。この本質的な
 不信を単純な概念「フィードバック」で打ち破る。
 まず2週間信じてやってみよう。2週間後も不信が拭えなくても失うものは
 わずか。信用できると思ったらもう2週間信用できるよね。
・カスタマとプログラマがお互いに信用し合うことを学んだ結果、新しい
 ストーリの追加にあたって大量の要求仕様文書に書き留める必要を感じない。
 イテレーション間でプロジェクトのペースを見ているので、プログラマの
 見積りに非常に詳細な計画を要求することなく満足する。
 絶え間ないリファクタリングによって大袈裟な分析・設計モデルがなくても
 コードが腐ることはない。
・この何十年の間、ソフトウェア産業の問題を解決するために、ソフトウェア
製品に先立って、ますます複雑で不可解な加工物(artifact)を生み出す巨大な
工程(process)を作ってきた。実際に必要としていることは、お互いに話し合う
ことを習得することだけである。

訳はぐちゃぐちゃですみません(昼休みの半分でかいたので)。
2ページの文章のなかにいろいろエッセンスが詰っていておもしろい記事だと
思いました。


======------======------======
Toru Takahashi,  TOSHIBA Corps. KOMUKAI Works
(office)tooru6.takahashi@....jp
(private)torutk@....jp