矢崎です。
Kaoru Hosokawaさん wrote:
> >
> > 私はよくわからないのですが、ユーザストーリからタスクに
> > 変換するときには、何かコツとか戦略のようなものはある
> > のでしょうか。
> >
>
> EC本を見直しましたが、特に記述されていないと思います。
>
そう、ＥＣ本に限らず、案外タスクの説明って少ないと
思いませんか？
今私が現場でタスクという言葉を使うときには、次のよ
うな意味で使っています。
ＸＸプログラムの担当をだれだれにして、、、
・概要設計
・詳細設計
・コーディング
・単体テスト
・結合テスト
概要設計に何日、詳細設計に何日、という具合ですね。
またもう少し細かいレベルにいけばテストをするためには
テストデータを揃えなければならない、、なんていうサブ
タスクが必要になったりします。
しかしＸＰでいうところのタスクって、上のような視点の
ものではないですよね。多分。このあたりの整理が自分の
中でつけばいいのですが。。。まだ、はっきりしていませ
ん。
>
> > ３日以内に終わるもの、とかいう指針はわかるのですが、
> > 特に内容的な面についてはどうなのでしょう？
> >
>
> 一つの iteration のアウトプット（内容）はビジネスと開発で決めることだと思い
> ますが、「内容的な面」とは？
>
タスクについての基準として、確か、１つのタスクは２，３日で終わる
程度の大きさでなければならない、、、というような大きさの面での
ガイドはあったと思うのですが、１つのタスクで実現すべきものは
どういう内容のものでなければならないのか、、の、指針がないの
かな？、、という疑問です。
つまり、タスクが出たら、次はその単位でCRCをし、テストを書き、
Paiｒ Programmingしていくのだと思いますが、そうなると、タスクを切
り出すとは、ユーザストーリ（要件）を仕様にし、そしてさらにそれを
開発しやすい単位に分割していることになると思います（まちがって
いたらご指摘お願いします）。しかしそれにしては、EC本等では、なん
か、あっさりしているというか軽くあつかわれているというか、もう少
しその、なんかいろいろノウハウがあってもいいような気がするので
すが、どうでしょう。もう、ここは開発者のセンスとスキルにおまかせ！
ってことでしょうか？あるいはベックは、ここんところはあんまり関心
がない？
以下は私見です（ちょっと長いです。）
タスクについて、、、、
１つ私が参考にしているのが、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とかコントロール、エンティティといった切り分けも具体的
にはなされていないはずで、このあたりを考えて行うべきかどうか
も？？です。もしかしたらメタファーでその当たりをある程度、先に
決めているのかもしれませんが。。
--
矢崎博英 firo@....jp