Kush's Wiki

Book/

ユーザーストーリーマッピング

Authors

Jeff Patton 監訳: 川口 恭伸, 訳: 長尾 高弘

#Agile #Product Management

ユーザーストーリーマッピング

ユーザーストーリーマッピング - O'Reilly Japan

0章 まず最初に読んでください

0.1 伝言ゲーム

0.2 共通理解の構築は驚くほどシンプルな話だ

0.3 良いドキュメントはバケーションの写真のようなものだ

0.4 記憶を助けるためのドキュメント

0.5 正しいことについて話そう

0.6 現在と将来

0.7 大切なのはソフトウェアではない

0.8 大切なのは人だけではない

0.9 作るものを減らそう

0.10 恐ろしい「要」で始まる言葉についてさらに

0.11 要するにこれだけだ

1章 全体像

1.1 「ア」で始まる言葉

1.2 書くのではなくストーリーを語る

1.3 全体像を話す

1.4 ゲイリーとフラットバックログの悲劇

1.5 話して記録

1.6 アイデアの枠組みを作る

1.7 顧客とユーザーのイメージを描く

1.8 ユーザーのストーリーを話す

1つのストーリーを掘り下げる前に、全体としてどのようなストーリーがあるのかを明らかにしよう

1.9 詳細部分と代替案を探索する

2章 作るものを減らすためのプラン

2.1 マッピングは大規模なグループが共通理解を築く上で役立つ

2.2 マッピングはストーリーの穴を見つけるのに役立つ

2.3 いつでも仕事は多すぎる

2.4 MVPリリースを切り出す

2.5 リリースロードマップを切り出す

2.6 機能ではなく成果で優先順位を付けよう

2.7 本当に魔法のようだ

2.8 私たちはなぜたびたびMVPを話題にするのか

MVPとは、望まれる成果を実現できる最小の製品のリリースである。

MVSとは、望まれる成果を実現できる最小のソリューションリリースである。

2.9 新しいMVP定義は製品ではない

MVPは、仮説を証明または反証するために作れる、あるいは実行できる最小のものである。

3章 より早く学ぶためのプラン

3.1 オポチュニティを議論するところから始めよう

3.2 問題の正しさをチェックする

3.3 学びのためのプロトタイプ

3.4 人々が何をほしいと言うかに注意しよう

3.5 学びのために作る

3.6 Viableになるまで繰り返す

3.7 間違った方法

3.8 検証された学習

3.9 実験の規模を最小限に抑える

3.10 復習しよう

4章 時間どおりに終わらせるためのプラン

4.1 チームにプランのことを話す

4.2 良い見積もりのための秘訣

4.3 少しずつ構築するためのプラン

4.4 スライスをいちいちリリースしない

4.5 良い見積もりのためのもうひとつの秘訣

4.6 予算を管理する

4.7 ダビンチならどうする?

4.8 イテレーティブにしてインクリメンタル

4.9 序盤、中盤、終盤の戦略

4.10 マップをスライスして開発戦略を生み出す

4.11 すべてはリスク対策

4.12 次は何?

5章 あなたはもうやり方を知っている

5.1 1度に1ステップずつストーリーを書き出そう

5.1.1 タスクは私たちがしていること

5.1.2 私のタスクはあなたのタスクとは違う

5.1.3 私はちょっと人より細かいだけで

5.2 ストーリーを整理する

5.2.1 見落とした細部を埋める

5.3 別のストーリーを探る

5.3.1 フローを整理し直す

5.4 マップからバックボーンを抽出する

5.5 特定の目標を実現しやすいようにタスクをスライスする

5.6 以上! あなたはすべての重要なコンセプトを学んだ

5.7 家で、または職場で本当に試そう

5.8 これは将来マップではなく現在マップだ

5.9 実際の仕事でやってみよう

5.10 ソフトウェアがからむと難しくなる

5.11 マップは手始めにすぎない

6章 ストーリーについての本当のストーリー

6.1 ケントのとてつもなくシンプルなアイデア

6.2 シンプルは簡単ではない

6.3 ロン・ジェフリーズの3つのC

6.4 言葉と写真

6.5 これですべて

7章 より良いストーリーテリングのために

7.1 Connextraの優れたテンプレート

7.2 テンプレートゾンビとプルークボーゲン

7.3 リアルに迫るために何を話すべきかについてのチェックリスト

7.4 「バケーションの写真」を作ろう

7.5 心配しなければならないことはたくさんある

8章 カードに書かれていることがすべてではない

8.1 異なる人、異なる言い分

8.2 もっと大きなカードが必要だ

8.3 ラジエターとアイスボックス

8.4 ここはツールを使うべきときではない

9章 カードは始まりにすぎない

9.1 頭のなかに明確な見取り図を入れてソフトウェアを作る

9.2 ストーリーを語り継げるようにする

9.3 仕事の結果を点検する

9.4 これはあなたのためのものではない

9.5 学ぶために作る

9.6 ソフトウェアばかりとは限らない

9.7 学ぶためにプランを立て、プランを立てるために学ぶ

10章 ケーキのようにストーリーを焼く

10.1 レシピを作る

10.2 大きなケーキの分解

11章 岩を砕いていく

11.1 規模はいつも重要だ

11.2 ストーリーは岩に似ている

11.3 エピックは巨大な岩で、ときどき人にぶつけるために使われる

11.4 テーマがストーリーのグループを整理する

11.5 用語のことなど忘れてストーリーテリングに集中しよう

11.6 オポチュニティから始まる

11.7 MVSを見つける

11.8 デリバリーでは個々のストーリーの細部を詰めていく

11.9 作る間も会話を続ける

11.10 個々の部品を評価する

11.11 ユーザーおよび顧客とともに評価する

11.12 ビジネスステークホルダーとともに評価する

11.13 リリースして評価を続ける

12章 岩を砕く人

12.1 価値があって、使いやすく、実現可能な

12.2 ディスカバリーチームが成功するためには多くの他人が必要

12.3 スリーアミーゴス

12.4 プロデューサーとしてのプロダクトオーナー

12.5 これは込み入っている

13章 オポチュニティから始める

13.1 オポチュニティについての会話

13.2 深く掘り下げるか、ボツにするか、再考するか

13.3 オポチュニティという言葉は文字通りの意味でなければならない

13.4 ストーリーマッピングとオポチュニティ

13.5 選り好みをしよう

14章 ディスカバリーを介して共通理解を築く

14.1 ディスカバリーはソフトウェアの構築ではない

14.2 ディスカバリーの4つの基本ステップ

14.3 ディスカバリーの活動、議論、作成物

15章 ディスカバリーによる検証された学習(Validated Learning)

15.1 私たちはほとんどの場合間違っている

15.2 古き悪しき時代

15.3 共感、絞り込み、アイデア創出、プロトタイプ、テスト

15.4 良いものをめちゃくちゃにする方法

15.5 検証された学習の短いループ

15.6 リーンスタートアップ思考は製品設計をどのように変えるか

15.7 リスクの高い仮定に名前を付ける

15.8 ソリューションと仮説を考え直す

15.9 ストーリーとストーリーマップは?

16章 リファイン、定義、構築

16.1 カード、会話、さらにカード、さらに会話

16.2 切って磨く

16.3 ストーリーワークショップを行う

16.4 スプリント、イテレーションのプランニング?

16.5 烏合の衆はコラボレーションしない

16.6 分割とスリム化

16.7 デリバリーでストーリーマップを活用する

16.8 マップを使って進行状況を可視化する

16.9 ストーリーワークショップではシンプルなマップを使う

17章 ストーリーは実際にはアステロイドに似ている

17.1 砕いた岩を組み立て直す

17.2 マッピングをやりすぎないように

17.3 小さなものに無駄な労力を使わない

18章 構築するすべてのものから学ぶ

18.1 チームとしてのレビュー

18.2 社内の他の人々とのレビュー

18.3 十分とは何か

18.4 ユーザーから学ぶ

18.5 ユーザーに対するリリースから学ぶ

18.6 期限が来たときの成果

18.7 マップを使ってリリースの準備ができているかどうかを評価する

19章 終わり? それとも

書籍