上手さん、ホソカワさん、リプライありがとうございます。
矢崎です。
Kaoru Hosokawa さんwrote:
>
> 私は、XPのタスクをこのように理解しています。
>
> ストーリー は、要求
> タスク は、要求を満たすための（プログラミング）作業
>
> 矢崎さんのタスクは、（XPで言っている）タスクの洗い出しではなく、タスクの実装
> をするためのプロセスではないでしょうか？
>
その通りです。
>
> >>> ３日以内に終わるもの、とかいう指針はわかるのですが、
> >>> 特に内容的な面についてはどうなのでしょう？
> >>>
> >>
> >> 一つの iteration のアウトプット（内容）はビジネスと開発で決めることだと思い
> >> ますが、「内容的な面」とは？
> >>
> >
> > タスクについての基準として、確か、１つのタスクは２，３日で終わる
> > 程度の大きさでなければならない、、、というような大きさの面での
> > ガイドはあったと思うのですが、１つのタスクで実現すべきものは
> > どういう内容のものでなければならないのか、、の、指針がないの
> > かな？、、という疑問です。
> >
>
> そうですね。明確な指針は出ていませんね。
>
> タスクの内容は、どんなものでもいいのではないでしょうか？そのタスクが２、3日
> で完成する内容で、かつ、ストーリーの一部である事が大事なのではないでしょうか？
>
XPではタスクそのものについて、厳密にこういうものである、、、
という定義はしていない、する必要がないということかもし
れませんね。むしろ大きさこそ大事（正確に測定できる大きさ、３
日以内に確実に終わる大きさ）なのかもしれません。
>
> > つまり、タスクが出たら、次はその単位でCRCをし、テストを書き、
> > Paiｒ Programmingしていくのだと思いますが、そうなると、タスクを切
> > り出すとは、ユーザストーリ（要件）を仕様にし、そしてさらにそれを
> > 開発しやすい単位に分割していることになると思います（まちがって
> > いたらご指摘お願いします）。しかしそれにしては、EC本等では、なん
> > か、あっさりしているというか軽くあつかわれているというか、もう少
> > しその、なんかいろいろノウハウがあってもいいような気がするので
> > すが、どうでしょう。もう、ここは開発者のセンスとスキルにおまかせ！
> > ってことでしょうか？あるいはベックは、ここんところはあんまり関心
> > がない？
> >
>
> そうですね。でも、要求からデザインを導く方法は、XPと関係がないのかもしれませ
> ん。開発者が一番いいと思う手法で作業をすすめればいいと思います。ただ、Big
> Design Upfront にならないように注意することです。
>
会話で導き出してもよし、Activity図を書いてもよし、手段は問
わないということかもしれませんね。
例えば、「このユーザストーリーを実現するために、どんな
処理の流れになるか、ちょっとわかんないな。Activity図を描いて
ちょっと、議論してみない？」こんな場合あるかもしれないし、
「このユーザ・ストーリなら、これと、これと、これだね。」みたいに
すぐ、決まってしまうような場合もあるかもしれませんね。
それとも、前者の場合だと、「ちょっと、このユーザストーリは抽象
的すぎるな。ユーザに頼んで、ユーザストーリを具体的にしてもら
おう。」といって、ユーザストーリの分割に向かうのかしらん？
> もし、MVCがそのシステムに適していると思われるのなら、ERで分析する必要はない
> と思います。MVCを使うだけです。「これって、MVCがいいよね。みなさん、どうおも
> います？」のような感じでタスクの洗いだしを行っているミーティングを思い浮かべ
> ています。このミーティングでは、ER分析する人もいれば、もうCRC始めているひと
> もいると思います。なんでもありなのではないでしょうか？ただ、時間をあまりかけ
> ずに、パッと決めることが大事なんでしょう。（要求は明日かわるから…）
いずれにしろ、Beck達が、どうやってタスクを決めているのか、
（１例でもいいので）覗いてみたい気がします。上手さんご紹介
のChessの例は、結構興味深いですね（結構スレッドが長いので
今読んでいる最中です）。
--
矢崎博英 firo@....jp