こんにちはmofmofでエンジニアをしているshwldです。
アジャイルな開発でよく用いられる、ユーザーストーリーについてあらためて考えました。
より良いユーザーストーリーを作るための原則をBill Wakeという方が提唱している「INVEST」という指標があるのでこれをみながらやっていることや思ったことを書いていきます。
I – Independent
N – Negotiable
V – Valuable
E – Estimable
S – Small
T – Testable
Independent（独立している）
ユーザーストーリーはそれぞれ独立して重複しないようにします。重複するとスケジュールが任意に立てられないためです。
いきなり難題です。これ改めて考えるととても重要なことのように思えます。
例えば、
- 「利用者は、タスク一覧を表示できる」
- 「利用者は、タスク詳細画面からタスクの期限を延長できる」
という2つのストーリーがあったとします。
これは一見、一覧画面がないと2.の実装がはじめられず、独立していないように見えます。
でも、
- 「利用者はタスクを一覧したい。期限が迫っているタスクを知りたいからだ」
- 「利用者はタスクの期限を延ばしたい。期限今日だけどやっぱり明日やりたいからね」
はストーリーとして別物で、重複もしていません。
ここで言ってる独立や重複しないは、実装の話ではなくストーリーが与える価値のことなのだという意識を持つことが大事そうです。
というのは完全に深読みおじさんです。
Bill Wakeさんは
ストーリーは、独立している場合に最も簡単に操作できます。つまり、概念的に重複しないようにし、任意の順序でスケジュールして実装できるようにしたいと考えています。
私たちは常にこれを達成することはできません。たまに「最初のレポートは3ポイント、他のレポートは1ポイント」などと言うことがあります。
みたいに言っています。
あー、そっちねー。そういうこともあるよ。
ここにはじゃあどうすれば良い。は書いてありません。
こういう場合はどうすればいいのか...
- 「レポートを生成する共通処理を構築する」をストーリー(chore)として登録する。
- ストーリーの依存関係を明示する（PivotalTrackerにBlockerという機能があります）
自分は重複許容して依存関係明示したらいいと思っており、そうやっています。
Negotiable（交渉可能である）
ユーザーストーリーは機能を明示的に約束するものではありません。詳細は開発中にオーナーとプログラマによって共同作成されます。よって、交渉可能なものでなければいけません。
ストーリー自体は見積もりの際に詳細化され、実装へつながる。
詳細化の際にどのようなやり取りを行うかは自由だが、プロダクトオーナーとプログラマで会話可能になっていなければいけない。
プログラマが実装のことをわかりやすい言葉に直すということは意識しやすいが、忘れやすそうなのは、プロダクトオーナー側も言葉選びにこだわってほしいというところです。
- そのプロジェクト、そのストーリーにおいて適切な言葉を選ぶ（ユビキタス言語）
- 可能なら英単語にする場合にどんな単語を選ぶのかも話したい（実装にも反映される）
のようなところを注意すると、より良さそうです。
ストーリーの状況を共有する
交渉可能であるためには、まず前提となる課題をプロダクトオーナーとプログラマが認識する必要があります。
状況を思い浮かべるといいと思っています。
「誰が、何のために、どう困っているのか」
もしくは
「誰が、何のために、どうするのか」
なるべく具体的に、「〇〇さんがあの機能を触っていたときに、こんなことを言っていた。」のような情報をチームで共有すると良いと思います。
プロダクトオーナーがすでにソリューションを決定している場合もあると思います。
そういう場合もソリューションの出発点となる上記の状況を知っているかどうかで、課題への理解が変わってくるので意識しています。
ストーリーを詳細にする
状況が思い浮かび、ソリューションもある程度イメージできたら、さらに詳細にしていきましょう。
本当にそのソリューションでいけるのか、成果物を全員でイメージして極限まで具体的にします。
画面デザイン
自分の周りでは一番採られている方法です。
- ストーリーの解が伝わりやすい
- 画面を作る労力が高いので、非同期になりがち
- 技術的難易度が高い実装になる可能性が高くなりがち
- プログラマサイドからの意見を画面デザインへ反映するコストがある
ライブ手描きワイヤーフレーム
以前は結構やっていました。
- その場でプログラマとプロダクトオーナーの認識合わせができる
- 細かいところまで考えるので、結構な時間がかかる
- デザイナーがいてもいなくてもできる
改めて考えるとよいなぁ
ドメインモデル図
やったことないです。
- 顧客が本当に欲しかったものと、実装が近くなる可能性が上がりそう
- プロダクトオーナーが多少システムのことを理解できる
- 概念やデータの関連性の共通認識を全員で持てる
- 結構難易度高そう。そもそもこれが簡単じゃないからユーザーストーリーなのでは感もある
ユースケース図
これもやったことないですが、会話の中では結構にたことを話したりしている。
- ユーザーのアクションでシステムがどのように動作するのか。
- 様々な場合を考慮し、ぬけもれを減らせる
- 顧客が本当に欲しかったものと、実装が近くなる可能性が上がりそう
- プロダクトオーナーが多少システムのことを理解できる
ドメインモデル図と同じような効果が期待できそう?
ありかもなぁ
Valuable（価値がある）
ユーザーストーリーは、顧客にとって価値があるものが書かれている必要があります。
これな。油断するとすぐ機能になるので注意が必要（自戒...）
もともとの課題があって、ストーリーになるわけなんだけど、ストーリー登録の際にソリューションを書きがち。プロダクトオーナー的には納得していることも多いが、プログラマに伝えるためにも価値であるべきである。
加えて言うと、詳細化の際には検証方法まで見えているべきである。
これを実現するとユーザーはどう嬉しいのか！
嬉しかったかどうかはどうやってわかるんだろう？
というか検証しないと価値があるかわからないはずなんですよね。検証しないとユーザーストーリーとして成立しないのだ。
難しければ実際のユーザーで検証しなくてもいい。少なくともプロダクトオーナーが触って、この機能はいいぞ！価値があるはずだ！ってならないといけないですよね。
Estimable（見積もりができる）
正確な見積もりは必要ありませんが、顧客がストーリーを順位付けすることができれば、スケジューリングがしやすくなります。
詳細化前の見積もりと、詳細化後の見積もり、どちらにも意義がある。
大局的に見るためにざっくりと見積もり、直近の作業の完了日を細かく見積もることで、少し先の未来の予定を確かなものにしていく。
Small（小さい）
ユーザーストーリーは最大で数人から数週間の作業に相当するのが望ましいです。ストーリーが大きくなると、正確な見積もりが得られないため分割します。
俯瞰して見たときにわかりやすいストーリーになっていることが大事。
見積もりが大きくなってしまったときに、ユーザー価値をどうやって分割するのかが難しいポイントだけど、この場合の小さくしたいは「スプリント内に1つもストーリーが完了しなかった場合にどのくらいの作業が終わったのか可視化したい」なので、プロダクトオーナーが進捗を追うことを優先して良いと思います。
もちろん価値定義や検証を小さくできるならわけたい。
Testable（テストできる）
ユーザーストーリーが達成できているのか
どうやって検証するのかを定義します。
受け入れ基準として定義することが多いでしょう。
- ユーザーはログインして、〇〇画面へいく
- 右上のメニューを開いて、〇〇をエクスポートを押す
- ダイアログがでて、OKを押す
- CSVファイルがエクスポートされる
- CSVファイルに、登録されたユーザーのEmailがちゃんと書き込まれている
- 登録ユーザーが居ない場合はエラー「ユーザーが存在しません」が表示される
というような感じで、具体的にイメージできるように書くと全員の認識が合います。
そして、追加で
「このCSVファイルを持って、問い合わせに解答できそうだ！」
まで意識できると更に良いですねー。
Discussion