-
Notifications
You must be signed in to change notification settings - Fork 47
Readingagilesamuraiinesm20110831
Kakutani Shintaro edited this page Sep 1, 2011
·
1 revision
←Readingagilesamuraiinesm20110824
第6章: ユーザーストーリーを集める
「ユーザーストーリー」は計画の単位であるからプロジェクトの中心ではある。"User Stories Applied"にも、ユーザーストーリーは要求と計画と受入テストと会話を兼ねるから良いのだという話が展開されているよ[要出典]。
だからといって、ストーリーを書けばソフトウェアをつくれるわけじゃない。ストーリーのあとに、ストーリーの分析のステップがあるよ。最初のリリース計画までにある程度の開発補助ドキュメント(開発チームが見積もれるようになるための情報)は用意したほうがいいと思う。
Valuableの解説が無いけど、Valuableであることが大事だというのは、ここまででも解説してるし、この本のテーマだから個別には解説してないんじゃね。
- 画面の仕様とか遷移とか、事前に詳細に決めすぎるとしんどくなることが多いね。
- ドキュメントが詳細すぎるとその引力が強くなる。
短い名前と、3幕記述の合わせ技がいいんじゃないかなあ。
違うねえ。ユースケースシナリオは書くのたいへんだよ(ユースケース図の話をしてるんじゃないよ)。
ユースケースシナリオは、ステークホルダーが複数いる場合に合意を形成していくのにはべんり。 バスの運転手となる「顧客」がいるならストーリーのほうが手軽だよね。
- 「10~40ぐらい」という理想は目指したい。最初はもっとエピックが多くていいのかも。詳細はあとで話そう！！
- ストーリー収集や分析と計画づくりは別のアクティビティだからね。混ぜるな危険
ちょう大事
- 今回は若手の参加が少なかったので、オッサンたちの体験談や知見を持ち寄るのが中心だった。こういうのは定期的にやっていかんとなー。