平鍋です．
ごめんなさい，先のメールは，
以下を読む前に返答してしまいました．
On Wed, 16 Aug 2000 15:28:51 +0900,
firo <firo@....jp> said:
> 私もわかりませんが、とりあえず考えを述べますと
> Iteration planning meetingにおいては、その時のIterationで
> 開発するストーリについては、統合的に考えてクラスを切り
> 出すのではないでしょうか？
> しかし、将来のIterationで開発するストーリについては、
> まったく考慮しないのではないでしょうか？
> だから、逆にいえば、ストーリの開発順のようなものが
> 重要になるのかもしれません。確かFirst Iterationでは、
> システムの骨格を形成するストーリを選ぶとか、そんな
> 指針がどこかにありませんでしたっけ？
> ＃以上、あくまでも個人的考えです。
いえ，確か EC 本に記述があった筈です．そのものずばりではない
ですが，[XP-jp:00144]の上手さんの10章まとめから，「計画ゲー
ム」と「メタファー」について，再度復習しておきましょう．
=============================================================
●計画ゲーム
ビジネスの考慮も技術的な考慮も大きすぎてはいけない。ソフトウェア開
発は常に出来ることと望ましいことの間の長い時間をかけた対話だ。対
話は、出来そうに見えることと、望ましそうに見えることの間で変化する。
ビジネスマンは以下について決定する必要がある。
◇スコープ
−システムが生産に役立つためには、どれだけの問題を解決する必要
があるか。ビジネスマンはどれだけが不足で、どれだけが過剰かわかる
立場に居る。
◇優先度
−最初はＡかＢしか持てないとしたらどちらにするか。ビジネスマンはこ
れをプログラマよりもよりよく決定できる立場に居る。
◇（段階的）リリースの構成
−そのソフトウェアをリリースする時に、どれだけ多く、またはどれだけ少
なく作業をすればビジネスがうまく回るか。この質問に対するプログラマ
の直感はひどく外れる。
◇リリース予定日
−その日にソフトウェア（やその一部）があると大きな差がでるという、
重要な日付はいつといつか。
ビジネスはこれらを真空の中から決定することは出来ない。開発は技術
的な決定をし、それをビジネスの決定のための材料として提供する必要
がある。
技術者は以下について決定する必要がある。
◇見積り
−一つの機能を実装するのにどれだけかかるか
◇結果（＃重要性かもしれない）
−技術的な結果を知らされていないと戦略的なビジネス決定は出来ない。
データベースの選択が良い例だ。スタートアップ（ベンチャー）企業の方が
巨大会社ビジネスはうまく行くかもしれない。しかし、生産性にの要素２
（＃？）は余分なリスクとそれに相当する不満を引き起こすかもしれない。
そうではないとしても、開発は重要性を報告する必要がある。
◇プロセス
−どのように業務とチームは組織されるのか？ チームは仕事をするた
めの文化（カルチャー）をつくらないといけないが、今の文化に組み込ま
れている非合理性を保つより、良いソフトウェアを書くべきだ。
＃今のカルチャーにとれわれず、ゼロからやりやすいものを考えよ。
という意味かな？
◇詳細スケジュール
−リリースの中間では、どのようなストーリーを最初に行うか？ プロジェ
クトの全体的なリスクを軽減するために、プログラマには開発の最もリス
クの高い部分を最初にスケジュールする自由が必要だ。この制約の中
でも彼らは、重要なストーリーをあるリリースの最後になって落とさざるを
得なくなることを減らすために、ビジネス上の優先度の高いものをプロセス
の前の方に持って行こうとする。
●メタファー（例）
それぞれのXPソフトウェアプロジェクトは頭上の輝くアーチとなるメタファー
（例）によって導かれる。例は時にはうまく機能しないこともある、例えば
契約、顧客、契約違反などの専門用語で語られる契約管理システムが
そうだ。また例は時にはちょっと説明を要する場合もある、例えばコンピュ
ータはデスクトップのように見えるとかとか、年金計算はスプレッドシート
のようなものだと言ったりする。実際に”そのシステムはプレッドシートだ”
とは言っていないのだから、これらは全て例だ。例は、プロジェクトの全員
が基本的な要素とその相互関係を理解するのに役立つ。
技術的なエンティティを識別するのに使われる用語には、いつも例を選ん
でこれを使うべきだ。開発が進行するにつれて例がこなれて（成熟して）
くると、チームの全員が例を使うことに新しいインスピレーションを見いだ
すようになる。
XPにおける例は他の人たちが”アーキテクチャ”と呼ぶもののほとんどを
置き換える。10000ｍにも見える（？）システムのアーキテクチャに当たる
際の問題点は、アーキテクチャが必ずしもシステムをわかりやすく見せて
くれないことだ。アーキテクチャはととも大きな箱と関係の集合だ。
”駄目なのはアーキテクチャが駄目だからだ”という声が聞こえるが、我々
は、自然でわかりやすいストーリー、その中で仕事をし、ビジネスマンも技
術者もたやすく共に担えるストーリー、を全ての人に与えつというアーキテ
クチャのゴールを強調しておきたい。例を求めることにより、我々は伝える
のも追加するするのも容易なアーキテクチャを得られそうだ
=================================================================
以上