ホソカワです。
コメントしますが、外しているかもしれません。
on 2000/08/03 12:50 PM, firo at firo@....jp wrote:
> 矢崎です。
>
> Kaoru Hosokawaさん wrote:
>
>>>
>>> 私はよくわからないのですが、ユーザストーリからタスクに
>>> 変換するときには、何かコツとか戦略のようなものはある
>>> のでしょうか。
>>>
>>
>> EC本を見直しましたが、特に記述されていないと思います。
>>
>
> そう、ＥＣ本に限らず、案外タスクの説明って少ないと
> 思いませんか？
>
> 今私が現場でタスクという言葉を使うときには、次のよ
> うな意味で使っています。
>
> ＸＸプログラムの担当をだれだれにして、、、
> ・概要設計
> ・詳細設計
> ・コーディング
> ・単体テスト
> ・結合テスト
>
> 概要設計に何日、詳細設計に何日、という具合ですね。
> またもう少し細かいレベルにいけばテストをするためには
> テストデータを揃えなければならない、、なんていうサブ
> タスクが必要になったりします。
>
> しかしＸＰでいうところのタスクって、上のような視点の
> ものではないですよね。多分。このあたりの整理が自分の
> 中でつけばいいのですが。。。まだ、はっきりしていませ
> ん。
>
>
>>
私は、XPのタスクをこのように理解しています。
ストーリー は、要求
タスク は、要求を満たすための（プログラミング）作業
矢崎さんのタスクは、（XPで言っている）タスクの洗い出しではなく、タスクの実装
をするためのプロセスではないでしょうか？
>>> ３日以内に終わるもの、とかいう指針はわかるのですが、
>>> 特に内容的な面についてはどうなのでしょう？
>>>
>>
>> 一つの iteration のアウトプット（内容）はビジネスと開発で決めることだと思い
>> ますが、「内容的な面」とは？
>>
>
> タスクについての基準として、確か、１つのタスクは２，３日で終わる
> 程度の大きさでなければならない、、、というような大きさの面での
> ガイドはあったと思うのですが、１つのタスクで実現すべきものは
> どういう内容のものでなければならないのか、、の、指針がないの
> かな？、、という疑問です。
>
そうですね。明確な指針は出ていませんね。
タスクの内容は、どんなものでもいいのではないでしょうか？そのタスクが２、3日
で完成する内容で、かつ、ストーリーの一部である事が大事なのではないでしょうか？
> つまり、タスクが出たら、次はその単位でCRCをし、テストを書き、
> Paiｒ Programmingしていくのだと思いますが、そうなると、タスクを切
> り出すとは、ユーザストーリ（要件）を仕様にし、そしてさらにそれを
> 開発しやすい単位に分割していることになると思います（まちがって
> いたらご指摘お願いします）。しかしそれにしては、EC本等では、なん
> か、あっさりしているというか軽くあつかわれているというか、もう少
> しその、なんかいろいろノウハウがあってもいいような気がするので
> すが、どうでしょう。もう、ここは開発者のセンスとスキルにおまかせ！
> ってことでしょうか？あるいはベックは、ここんところはあんまり関心
> がない？
>
そうですね。でも、要求からデザインを導く方法は、XPと関係がないのかもしれませ
ん。開発者が一番いいと思う手法で作業をすすめればいいと思います。ただ、Big
Design Upfront にならないように注意することです。
> 以下は私見です（ちょっと長いです。）
>
> タスクについて、、、、
> １つ私が参考にしているのが、UML DistilledのChapter
> 11（今手元に英語本の2ndしかないので、その点ごめんな
> さい）で、Fowlerはその章で、Use Case-->Scenario-->
> Responsibilityというように、要件からシステムの機能
> へと展開していっています。
>
> 英語本１４５ページ
> Various health care professionals make observations
> about patients.This simple system will allow someone
> to get information about those observations and
> to add additional observations.
> (略）
> This is such a simple example that it has but a
> single use case,named "review and add patient
> observations." We can elaborate on that with a few
> scenarios.
> * Ask for the latest heart rate of a patient.
> * Ask for the blood type of a patient.
> * Update a patient's level of consciousness.
> * Update a patient's heart rate.The system marks
> the rate as slow,normal,or fast,according to the
> system's built-in ranges.
>
> 英語本１５０ページ
> The first scenario asks for the latest heart rate
> of the patient.The first question is: Whose
> responsibility is it to handle this request?
> (略 そして１５１ページ)
> A similar responsibility exists for Phenomenon:
> Find the latest Category Observation that has a
> Phenomenon for the given Phenomenon Type.
>
> Figure 11-5 shows operations that I've added to
> Patient to reflect my thinking.
>
> となって、２つのresponsibility--latestAmountOf(
> PhenomenonType):QuantityとphenomenonOf(PhenomenonType
> ):PhenomenonをクラスPatientのResponsibilityとして
> 図に表しています。
>
> そして、その後はコードに展開していきます。コードを書き
> すすめる上で、上のResponsibilityは、複数のクラス間のコラボレ
> ーションに展開していきます（FowlerはこれをRefactoringでや
> ることが多いと書いています）。本をお持ちでしたら、そちらに
> あたっていただければ幸いです。
>
> さて、私としては、上記のuse caseにユーザストーリが対応し、
> responsibilityにタスクが対応するのではないかと、考えています。
> 完全対応ではないかもしれませんが。
>
> しかし、上記が仮に正しいとして、だからといって、タスクを切り出す
> ときの疑問が解決するわけではありません。例えば次のような疑問
> もわいてきます。。。（今回は関係ないかもしれませんが、）GUI系の
> ものであれば、タスクを切り出すところでクラスが明示的に与えられ
> ていないとしても、MVCを意識したタスク切り出しをするのでしょうか
> ？RUPでいうところのコントール系とエンティティ系のResponsibilityを
> 分けてタスクに落としていくべきでしょうか？少なくとも
> First Iterationではクラスはまだ出ていないと思うのですが、そうす
> るとMVCとかコントロール、エンティティといった切り分けも具体的
> にはなされていないはずで、このあたりを考えて行うべきかどうか
> も？？です。もしかしたらメタファーでその当たりをある程度、先に
> 決めているのかもしれませんが。。
もし、MVCがそのシステムに適していると思われるのなら、ERで分析する必要はない
と思います。MVCを使うだけです。「これって、MVCがいいよね。みなさん、どうおも
います？」のような感じでタスクの洗いだしを行っているミーティングを思い浮かべ
ています。このミーティングでは、ER分析する人もいれば、もうCRC始めているひと
もいると思います。なんでもありなのではないでしょうか？ただ、時間をあまりかけ
ずに、パッと決めることが大事なんでしょう。（要求は明日かわるから…）
--
Kaoru Hosokawa
khosokawa@....com