矢崎です。
Is Design Dead? の翻訳、とても楽しみにして
おります。がんばってください。
ono@....jpさん wrote:
>
> この訳はちょうど半分くらい終わりましたが、以下の部分、
>
> <H2>The Value of Simplicity</H2>...
>
> ... If I have to do any work that's only
> used for a feature that's needed tomorrow, that means I lose effort
> from features that need to be done for this iteration. The release
> plan says what needs to be worked on now, working on other things
> in the future is contrary to the developers agreement with the
> customer. There is a risk that this iteration's stories might not get
> ^^^^^^^^^^^^^^^^^^^
> done. Even if this iteration's stories are not at risk it's up to the
> customer to decide what extra work should be done - and that might
> still not involve multiplication.</P>
>
> this iteration's stories の訳で悩んでしまいました。普通に「階層」
> と訳すのか、それとも XP においてなにか特別のものを「ストーリー」
> と呼んでいたりするのでしょうか？
>
> ＃ ユースケースのことを指しているのであれば「シナリオ」と言うはずだし...
XPでは、ストーリーというのは、特別な意味を持っ
ています。Kent BeckのXPE本のGlossaryによれば、
~~~~~~~~~~~~~~~~~~~~~~~
Story
One thing the customer wants the system to do.
Stories should be estimable at between one to five
ideal programming weeks. Stories should be testable.
ストーリー Story（上手さん訳）
顧客がそのシステムにやって欲しい一つの事。ストーリー
は１〜５理想的プログラミン週で見積もれること。ストーリ
ーはテスト出来ること。
（訳注：通常、ストーリはタスクに分割して変換される）
(なお、上記訳は、上手さんが[XP-jp:00482]で、まとめられ
たものの転載です。上記メールには他の用語も日本語で
まとめられていますので、そちらもご参照ください）
~~~~~~~~~~~~~~~~~~~~~~~
プロジェクトが開発するシステムの機能はストーリ
（の集合）として定義されます。ストーリは、上記
のとおり、短期間で開発できる程度の大きさで、か
つテストが可能（なほど具体的？矢崎の解釈）でな
ければなりません。また、補足すると、ストーリは
ユーザがユーザの視点から書くものです。XPにお
いては、ストーリを書くのはユーザの責任となって
います。
通常、開発対象のシステムには複数のストーリが定義
されます。ユーザから見て、これから作るシステムは、
これと、これと、この機能が必要だなあ。ということです。
抽象的に、「顧客管理システムを作ってほしい」ではなく
て、「年月日と顧客コードを指定すると、その時点の顧
客情報を見れるようにしてほしい」とか、「地域を指定す
ると、その地域に住んでいる顧客の一覧を表示してほ
しい」とか、そういったレベルまで具体化されているもの
がストーリです。
ストーリは、イテレーションでの開発の単位になり
ます。各イテレーションの最初には、このイテレーション
でどのストーリを開発するかを決めます。今回のイテレ
ーションでは、Story１と５と８を開発しよう。７と２は次回、
１０と１は、その次という具合です。
*****
さて、ではユースケースとストーリの関係は？
上の説明だけだと、２つは同じように見えます（よね）。
実はユースケースとストーリが同じものかどうかに
ついては本家のほうでもいろいろ議論があるようです。
ただ、おしなべて言えることは、ユースケースとの違い
として、XPer達は以下の点を主張しているようです。
・ストーリはユースケースほど厳密に書くことを要求
しない。
・ストーリを書くのはユーザが行う
・ストーリはカードに書くべし
そして、上記の違いは、ユースケースとストーリを書く
ときのねらいの微妙な違い、心構えの違いを反映して
いるのだと思います。
ユースケースは事前条件、事後条件、ステップを書いた
り、ExtendやIncludeがあったりして、それなりに書き方
も（きちんとやろうとすれば）複雑かつ形が決まったりし
ているます。また、ユースケースはドキュメントとして、
何か *きちんとした紙（物理的OR電子的）* に書くことが
普通ですし、ユースケースを書くのはユーザではなく、
開発者（ユーザにインタビューをして、開発者が書く）という
のが普通ではないでしょうか？
ストーリは、厳密に書くことは要求されません。というより、
むしろ厳密に書かないほうがよい、とされているようです。
事前、事後条件とかステップとか書くのではなく、１か２つ
の文で簡単に書く。そういうもののようです。
また、ストーリを書くのはユーザ自身です。開発者がヒア
リングして代書するのも、できるだけなし です。またスト
ーリは、何か正式なドキュメントして作成されるのではなく、
インデックスカードのようなものに手書きでさらさらっと書く
、、
さて、そうした違いを、単に瑣末なものとして捉えるか、
手段の違いだよね、程度でいえるのか、だから、ストーリ
とユースケースは同じものだよ、と言っていいのか悪いのか
は、いろいろ意見があると思いますが、私としては、根本
的なところに要件を定義するときの心構えの違いがある
ような気がします。
例えば、私見ですが、
ユースケースは、
「ユーザ要件あるいは外部仕様は、工程の最初のほうで決
まるので、それをあますところなく文章で表現し、文書でコミ
ュニケーションし、それを後生大事に保管しておくことは、意
味がある。」という考えが、根底にあるのではないでしょうか。
対してストーリは
「ユーザ要件は、工程の最初で決まることはないし、はっきり
していなかったり、途中で変わることもある。したがって、文章
ですべてを詳細に書けないし、書くことで心理的にそれを変更
しにくくすることもある。だから、要件を定義するということは、
どこかの時点で、それを凍結し文書として正確に書くということ
ではなく（それができれば最高かもしれませんが）、むしろ、ユ
ーザに、それを自分の問題として認識してもらう、というように
目的をシフトしたほうがよい。だから、ニーズを細かく書くという
ことは必要ではないし、そのために、ユーザが書きたがらなく
なるとか、要件の変更がしにくくなる、というマイナスもでてくる。
しかし、では細かい要件をどうやって把握するかというと、ＸＰ
では、それを会話で補うのだ。」
というような心構えの違いがある、と考えているのですが
どうでしょう？
--
矢崎 博英 <firo@....jp>