ユーザーストーリーをはじめよう

Transcript

1. 2025.2.24
2. はじめに これは絶対的な正解ではありません。 組織やチームにとっての最適な形を見つけて行くのが大切です。 しかし、汎用的なパターンは存在します。 そのパターンを試して取り入れていくことで巨人の肩に乗ること を狙いとした資料になります。
3. ユーザーストーリーを 知る
4. ユーザーストーリーは意図を短文で記述したものであり、システム がユーザーのために行わなければならないことを記述する。 アジャイルソフトウェア要求 より引用 ユーザーの価値ベースで 何をシステムで行いたいかを表現している 価値提供の単位とも言える 一言で
5. ユーザーストーリーのルーツ 😭実はスクラムガイドには記載はない ストーリーはXPプロジェクトにおける機能の単位。 ストーリーは、顧客に理解可能で、開発者がテスト可能 で、顧客にとって価値があり、プログラマーが1回の反復に 6つ程度作れるほど小さなものであるべきである。 ※スクラムガイドではプロダクトバックログアイテム 👉故に形式的に使われやすい ＼ワシじゃよ／
6. ストーリーは要件ではない。会社、顧客、ユーザーが抱える問題の 解決についての議論であり、何を作るかについての意見を一致に導 くものだ。 ユーザーストーリーマッピング より引用 ユーザーストーリーのねらい 誰(Who)に何(What)をなぜ(Why)届けるのか の共通理解を築く起点にする
7. 機能ではなく、誰となぜ Connextraでストーリーを書いたのは、ほとんどが営業や販売促進 の人々だった。彼らは、自分にとって必要な機能を書き出す傾向が あった。しかし、開発者たちが会話をするときには、本来のステー クホルダーを見つけだし、 「誰」と「なぜ」を含んだ、良い会話を 始めなければならない。機能の名前だけが書いてあっても、チーム が話をすべき適切な人々を見つけ出し、適切な議論を始めるために は役に立たない。 ユーザーストーリーマッピング より引用
8. よくあるテンプレート [ユーザータイプ]として、 私は[これこれの結果を得るために]、 [これこれを]したい。 ユーザーストーリーマッピング より引用 対話ファシリテーターとして 私はワークショップの幅を広げるために、 参加者が席を自由に移動できるようにしたい 👨‍💼価値を享受する人(Who) 誰に一番価値を届けたいのか、 誰のためのストーリーなのかを このユーザータイプで表現する 🎯なぜ必要か(Why) この後の振る舞いを提供することで どのような価値を享受することができるのか 🏃何をしたいのか(What) システムがユーザーの考えてることで どういう振る舞いをしてほしいのか
9. カード ソフトウェアに望むこ とを書く プロダクトバックログ のこと 会話 集まってどのようなソフトウェ アを作るかについて豊かな会話 を交わす 双方が理解している問題をもっ ともよく解決する方法に到達す るために共同作業をすること 確認 ソフトウェアが完成したこと をどのように確認するかにつ いて意見を統一する 受け入れ基準も確認の一環 構築 結果 カード ユーザーストーリーのプロセス(3C) 5Cはアジャイル開発のフロー
10. 要望 要求 要件 要望 要件 要望 要望 要望 価値? 価値 価値 価値 要求 要求 要求 要求 ユーザーストーリーと要求開発 従来型 ソリューションは定義者依存 顧客が求めているものと違う可能性 価値提供は大きく、遅い ユーザーストーリー 最適なソリューションをチームで考える 要望を裏にある真の答えを模索する 価値提供は小さく、早い 発見 発見 発見 発見 発見 発見 発見
11. 小さく価値提供することができる 誰に何をなぜやるのかを理解しやすい 共通理解を持つことができる "顧客が本当に求めていたもの"を作りやすい 誤解すると利点を帳消しにする 誤解するとわかりにくいだけのものになる 誤解すると共通理解を持てない 誤解すると会話を生み出さない ユーザーストーリーのメリデメ メリット デメリット ユーザーストーリーが「なぜ」この構成なのか 何を実現するためのものなのかを理解するのが重要になる 形骸化は危ないよ！
12. ユーザーストーリーを 作る
13. ユーザーストーリーの抽象度 ユーザーとして ふりかえりがしたい そうすれば プロセスの改善ができるからだ ファシリテーターとして 参加者が席を自由に移動できるようにしたい そうすればワークショップの幅が広がるからだ 抽象度 高 低 ☹️ 抽象度によって 扱いを変える必要がある
14. スクラムマスターとして、 私はよりユーザーストーリーが誤解されるのを避けるために ユーザーストーリーをカテゴライズしたい エピック?ユーザーストーリー?テーマ?フィーチャ? 🚨ここらへんは正直方言になっている ある所ではエピック ⊃ テーマ 他の所では テーマ ⊃ エピック 別のところでは エピック ⊃ フィーチャ 🙋一旦は用語は忘れる でっかい岩があって、それを小さな石に砕くイメージ ※後述で再度具象に落します。 ユーザーストーリーマッピングより引用 ユーザーストーリーマッピングより引用
15. ペイン (ナラティブ) ペイン (ナラティブ) ペイン (ナラティブ) 日頃の業務で感じる“小さな不便” 要望 要望 要望 “小さな不便”が積み重なって 「◦◦という機能がほしい!」 ユーザーストーリーを作る ユーザーストーリー 大なり小なり ユーザーストーリーになる
16. ペイン (ナラティブ) ペイン (ナラティブ) ペイン (ナラティブ) 日頃の業務で感じる“小さな不便” 要望 要望 要望 “小さな不便”が積み重なって 「◦◦という機能がほしい!」 ユーザーストーリー 大なり小なり ユーザーストーリーになる ここはHow ユーザーストーリーを作る こっちがWhy 顧客が抱える課題に本質解のヒントがある Who
17. ユーザーストーリーを 分割する
18. ユーザーストーリーのINVEST ndependent(独立している) I Negotiable(交渉できる) Valuable(価値がある) Estimable(見積もりができる) Small(小さい) Testable(テストできる) 📈INVESTという性質 🙅‍♂️よくある勘違い Bill Wake氏がよいユーザーストーリーの性質を説 明するためにINVESTという頭字語を考案した。 “すべての性質を含む”必要はない。 INVESTの中の性質は等価ではない。
19. ユーザーストーリーのINVEST ndependent(独立している) I Negotiable(交渉できる) Valuable(価値がある) Estimable(見積もりができる) Small(小さい) Testable(テストできる) 🎖️V > T > I > N = E = S 個人的意見として、Valuableが一番大切 時点でTestable、三番手でIndependentである これをベースに分割を考える 💳価値があってこそ 価値を届けないユーザーストーリーは本当に必要? ⛳終わりから始める どうなったら完了なのかを決めない限り 人は100%を目指し続けてしまう
20. イメージ 全体像を通してUX中心に考えられる 大きなストーリーを小さなストーリーの塊にできる 共通認識を大人数と持つことができる ストーリーの優先順位を考えられる ストーリーの詳細は煮詰めにくい ユーザーストーリーマッピング 💪強み 🤢弱み ユーザーストーリーマッピングより引用 共通理解を築く 🎯目的 ※諸説あります StoryMappingの見解(1) バックボーンを特定する 1. エピックに分解して、プロトタイプを作る 2. (2)をベースに特定ユーザーの一日のユーザーストーリーを考える 3. 追加のアクティビリティを発見する 4. 他のユーザーへマップを拡大する 5. プロフェッショナルプロダクトオーナーを参考 StoryMappingの見解(2) 主要な機能を付箋に書き、優先順位の高いものから左から右へ 1. トップレベルのエピックをステップまたはテーマに分解する 2. ステップまたはテーマをストーリーに分解し、付箋を記入する 3. More Effective Agile を参考 →バックボーンから小さなストーリーにしていき 優先順位を決めるのが責務っぽい
21. ストーリーの詳細を煮詰められる 具体例から考えて、共通認識を揃えられる 受入基準もここで決めやすい 単体では全体像を把握できない 具体例を考えるのが難しい 定式化までやりきったほうが効果的 イメージ 実例マッピング 💪強み 🤢弱み BDD THE BOOK Discoveryより引用 構造化された会話で ストーリーの詳細を発見する 🎯目的
22. イメージ ワークフローステップで分ける パターンで分割する feat. アジャイルソフトウェア要求 ビジネスルールのバリエーション 大半の労力 単純/複雑 データのバリエーション データ入力方法 システム品質を後回しにする 操作(CRUD) ユースケースシナリオ スパイクを始める
23. イメージ 複数のことが混じったストーリー を要素に分解する 複雑なストーリーを既知のことと 未知のことで分離する 未知のことをわかるまで繰り返す 受け入れ基準をもとに分割する 依存関係を最小にする 意図を1つにする ストーリーをテスト可能に保つ パターンで分割する feat. レガシーコードからの脱却
24. イメージ 工程面での分割 技術面 技術面での分割 分割のアンチパターン フロントエンドの実装をしたい バックエンドの実装をしたい 工程面 開発・テストしたい 設計したい
25. ユーザーストーリーを 見積もる
26. ストーリーポイントで見積もる 見積に時間がかからない ポイントをベースに中長期の見積ができる 計画が大きく外れにくい 💪強み 何日で終わるかは実績がないとわかりにくい 基準になるものが必要 チームで認識が揃うまで時間がかかる 🤢弱み イメージ 🎡ポイントが大きすぎる →ストーリーが大きすぎるので、分割する必要がある ❓ポイントが付けられない →不確定性が大きすぎるのでスパイクやリファインメントをする 🐜ポイントが小さすぎる →他の小さいストーリーと合体できる可能性がある 👀ストーリーポイントのミカタ どれくらいのサイズかを 相対的に見積る 🎯目的
27. リスクや不確実性を 取り除くためのストーリー 🎯目的 ✂️ 分割するためのスパイク →見積り可能な複数部分に分割するために分析する 💻 技術的リスク解消のためのスパイク →技術的なアプローチに自身を持つために調査やプロトタイピング 😵‍💫 システムがユーザーとのやり取りを明確にするスパイク →ストーリーの意図はわかるが、システムとのやり取りが不明確 スパイク 🔨スパイクを用いる時 技術的なスパイク 解領域の様々な技術的なアプローチを 調査するために用いられる 機能的なスパイク ユーザーがシステムとやり取りする方法が 著しく不確実である場合。 モックアップやワイヤーフレームなど使い フィードバックを得る。
28. ユーザーストーリーの 実践知
29. アジャイルソフトウェア要求式の体系化
30. インパクト マッピング ユーザーストーリー マッピング USMで セクション分けされた単位 実例マッピング スプリント プランニング アジャイルソフトウェア要求式の体系化
31. ストーリーとユーザーストーリー 📈ユーザーストーリー形式にこだわらない バックログはユーザーストーリーと他の開発項目からな ることが分かる。他の開発項目は、改良、結果、サポー トと保守、ツールやインフラに関する仕事を含む。 無理にユーザーストーリー形式にする必要はない。 ユーザーストーリーにおいて、 「プロジェクトマネージャーとして」 とか「プロダクトマネージャーとして」とか「開発者として」とか 「テスト技術者として」とか書いていないだろうか？ こうなってい るとそのソフトウェアの利用者を見失っているということになる。 プロジェクトマネージャーとかプロダクトマネージャーはソフトウ ェアの利用者ではないはずだ。 誰がソフトウェアを使うのかという 点について原点に立ち戻って考えて、利用者の視点でユーザースト ーリーを書いてほしい。 別の手としてはペルソナを用意するという 手もある。 いずれにせよ、常に利用者にフォーカスをあてること だ。 ユーザーストーリーをうまく使えていない5つの兆候 | Ryuzee.com https://www.ryuzee.com/contents/blog/4249より引用 プロダクトバックログをつくるのにユーザーストーリーを使うと決 めたのは素晴らしい。 だが、ユーザーストーリー形式に限らず好き な形式を利用できるということは知っておいてほしい。 ユーザース トーリーを使わなければいけないという決まりはScrumにはないの だ。 プロダクトバックログの全ての項目でこの形式を使うことを強 制されることはない。 多くの場合、例えば非機能要件を追加すると きに無理にユーザーストーリー形式に揃えることは道理にかなって いない。 代わりに、これらの非機能要件はユーザーストーリーの受 け入れ条件に記述するという手もある。 この非機能要件をを複数の ストーリーに適用しなければならない場合には、エピックを作りそ こに記述することも考えられる。 いずれにせよ、プロダクトバック ログの全ての項目をユーザーストーリー形式で書こうとはしないこ とだ。 ユーザーストーリーをうまく使えていない5つの兆候 | Ryuzee.com https://www.ryuzee.com/contents/blog/4249より引用
32. TD/BU方式の要求獲得 トップダウン方式では、要求プロセスは全体像から始まる。チ ームは、アクターフィーチャー、エピック、イニシアティブを 特定する。これらはトップレベルのビジネス目標、機能、能力 であり、続いてストーリーに分解される。トップダウン方式を 開始するよい方法は次のようなものである。 ストーリーマップを作成する プロダクトビジョンを定義する エレベーターピッチを作成する プレスリリースとFAQを記述する リーンキャンバスを作成する インパクトマップを設計する ペルソナを特定する これらの手法にはそれぞれリリースの全体的な方向を定義する という意図がある。どの手法も、実装を進めるのに十分な、よ り詳細なストーリーの生成を手助けすることを目指している。 ⬇️ トップダウン ボトムアップ方式では、要求プロセスは具体的な詳細(通常は ストーリー)から始まる。ボトムアップ方式を開始するよい方 法は次のようなものである。 ユーザーストーリー作成のワークショップを開く 典型的なユーザーによるフォーカスグループを実施する 要求獲得のヒアリングを行う ユーザーが仕事をしているところを観察する 現在のシステムでの問題報告を見直す 既存の要求を見直す 既存の拡張依頼を見直す 特定のストーリーが生成されたら、それらをテーマ、フィー チャー、エピックにまとめる。 ⬆️ ボトムアップ →プロダクトフェーズによって 使い分けていく必要がある More Effective Agileより引用 More Effective Agileより引用
33. スプリントのストーリーはどう選ぶ? スプリント
34. そしてスプリントゴール編へ... 待ってるよ
35. 参考資料 プロダクトバックログ Deep Dive | Ryuzee.com https://slide.meguro.ryuzee.com/slides ユーザーストーリーをうまく使えていない5つの兆候 | Ryuzee.com https://www.ryuzee.com/contents/blog/4249 プロフェッショナルプロダクトオーナー: プロダクトを効果的にマネジメントする方法 アジャイルソフトウェア要求 スプリントゴールで価値を駆動しよう ユーザーストーリーマッピング IMPACT MAPPING アジャイルエンタープライズ THE BDD BOOKS Discovery Japanese Edition THE BDD BOOKS Formulation ScrumGuide2020 More Effective Agile レガシーコードからの脱却 エッセンシャルスクラム