『The Art of Crafting User Stories』は、ユーザストーリーの書き方に関する書籍です。結構な分量があるものの、多くの例が載っているわけではなく、べき論的な話がつらつらと書いてあって、これを読んだだけでは、必要なことは山ほどあることが分かるけれども、実践には結びつきにくい、と感じました。
ユーザストーリーの書き方
基本的に、以下のテンプレート形式で要求を記述します。
私が [ペルソナ] なら、[希望] を実行することで [目標] を達成したい
良いユーザストーリーは、以下の性質を満たすと良いとされます。頭文字をとってINVESTモデルと言われることもあります。
- 独立: ユーザストーリーは、他のユーザーストーリーに依存せず、自己完結していなければならない。
- 交渉可能: ユーザストーリーは交渉可能であるべきで、議論や変更が可能であるべきです。
- 価値あるもの: ユーザストーリーはユーザーに価値を提供する
- 見積もり可能: ユーザストーリーに必要な労力を見積もることができる
- 小さい: ユーザストーリーは、1回のイテレーションで完了するのに十分小さいべきである。
- テスト可能: ユーザストーリーは、それがユーザーのニーズを満たすことを確実にするために、テスト可能であるべきだ
ユーザストーリーからどう実装するのか?
ユーザストーリー自体の有用性は理解しつつも、そこからどう開発へ繋げていくのかは、言及されているものがあまり見つかりません。ユーザストーリーを元にGerkhinでAcceptance Test書こう、みたいな話はあるものの、モデリング → プログラミングのところは抜けている文献が多いし『The Art of Crafting User Stories』も同様でした。
ユーザストーリーと似たようなもの、ユーザストーリー + EventStormingといった手法にDomain Storytellingというものがあって、この１２章には、Domain Storytellingからドメインモデリングへ、の話が載っています。
が、残念ながらユーザストーリーから、唐突にクラスが抽出されているようにみえます。ただし、Domain Storytellingは、ダイアグラム中に型定義や振る舞いの定義に必要な情報が書かれるので、なんとかなるイメージです。
具体的にDomain Storytellingからコードに落としていく様は、以下のDDD EUのライブコーディングで見れます。
ということで、やはりユーザストーリーの記述テンプレートでは、実際にモデリングするには、情報、語彙が足らないので、そのギャップを埋める手法はどうやったって別途必要になるんじゃないか、という印象を受けました。