ユーザーストーリーマッピング 7章から12章を読んで
上記の本を読んでいて、7章から12章まで各章ごとに印象に残ったことをメモりました。
7章 より良いストーリーテリングのために
- 以下のようなシンプルなテンプレートを使って会話を始めよう(以下のテンプレートでストーリーに書かれている内容の理解が十分なわけではない)
[ユーザータイプとして]、私は[これこれの結果を得る]ために、[これこれを]したい。
- バックエンドやセキュリティ問題についてのストーリーは難しいものになることがあったり、ストーリーのテンプレートに収めるのに難しいアイディアもある
- そういうときはストーリーのテンプレートに従わなくてもいい
- 誰が、なぜ、何を、どのくらいの期間で、など詳細についてもきちんと話をしよう
- 話すべきことはたくさんあるので、話を思い出すのに役立つものを必ず記録しておこう
8章 カードに書かれていることがすべてではない
- すべてのストーリーについて、様々な人の間で様々な種類の会話が行われる
- ストーリーは図書館のカード目録のようなもので、ストーリーのカードの他にどこかにどんどん増え続けている情報があることがわかっている
- ストーリーに本当に書かれているものは何か
- 短いタイトル
- 簡単な説明
- ストーリー番号
- 見積り、規模、または予算
- 価値
- メトリクス
- 依存関係
- 状況
- 日付
- ストーリーに本当に書かれているものは何か
- 共通理解を築くのにホワイトボードの前でポストイットという武器を持って頭を突き合わせて話をする以上の方法はない。リモートでもカメラやウェブカメラを利用したりそれ用のツールを使おう
- 計画した仕事の進行状況の順位付け、追跡、分析にはツールを使おう
9章 カードは始まりに過ぎない
- アジャイル開発サイクルのモデル ... 5つのC
- Card
- Conversation
- Confirmation ... ここまでがカードの3C
- Construction(構築) ... 議論の場で記録したメモや写真を見て細部を思い出しながらチームはソフトウェアを作る
- Consequences(結果) ... 作ったものを最初はチームとして次にビジネスステークホルダーとともに評価し最後に顧客、ユーザーとのテストで評価する
- 構築時に議論の中でできた同じ見取り図を構築のメンバーが頭の中に持っている必要がある
- ストーリーの詳細を誰かに渡してソフトウェアを作ってもらおうとしてもうまく行かないししてはならない
- ストーリーを理解している人とストーリーを語るために集めた情報があればストーリーを共有するのにかかる時間は大幅に短くできる
- ストーリーを形にするための効率的な議論や意思決定のために全員は必要ない
- ソフトウェアが完成したら品質について話し合う
- ユーザーエクスペリエンスの質/機能の品質/コードの品質
- 自分たちが作り上げたものに変更を加えなければならない点を見つけてしまった場合
- 私たちは合意した通りのものを作ったか?
- 合意した通りのものを作ったとしてそれを見た結果何か変更を加えるべきか?
- ユーザーの横に座ってユーザーがあなたの製品を使っているところを見た方がいい
- 学ぶことを計算に入れてプランを立てる必要がある
10章 ケーキのようにストーリーを焼く
- ストーリー(デリバリー可能で、評価可能なものを表現したストーリー)を開発チームに持っていくとデリバリータスク(ストリーの実現に必要な作業を表現する)ができる
- デリバリータスクの詳細を話すのではなく、誰がなぜそれを使うのかを話題にする
- ストーリーが表しているソリューションがコストのかかりすぎるものなら目標達成に近づく別のソリューションを検討しよう
- ストーリーが大規模な場合、早いうちに進行状況を評価、確認できる小さなプランのものに分割しよう
11章 岩を砕いていく
- 立場によって適切なサイズのストーリーの規模は変わる
- ユーザーの視点から見た適切なサイズのストーリーは、ニーズを満たすストーリーだ
- 開発チームの視点から見た適切なサイズのストーリーとは、ビルド、テストに数日しかかからないストーリー
- ビジネスの視点から見た適切なサイズのストーリーは、会社が業績を上げるのに役に立つストーリー
- エピックは(開発者から見て)分解することが必要だとわかっている大きなストーリーだが、ビジネス、顧客、ユーザーから見て適切なサイズのストーリーである
- 分解したストーリーをテーマというかたまりを使ってまとめよう
- ストーリーの岩を砕いていくサイクル
- 新機能、新製品、既存機能の改良などのアイデア(オポチュニティ)に名前をつけて、オポチュニティバックログに入れる
- 誰が何をなぜを深く議論してそれぞれのアイデアについてボツにするか先に進むか決める
- 前進するアイデアを深く掘り下げて、できる限り小さく価値のあるものを作ることを追求する(ディスカバリー段階)
- ソフトウェアをビルドするために、細部を開発チームと話をしてストーリーをさらに分割する
- 構築中も細部を埋め、作成中のものにフィードバックするために会話を利用する
- 作られた部品をスプリントレビュー(スプリントレトロスペクティブ)で最初の評価をする
- 意味のある量の動くソフトウェアを顧客、ユーザーとともにテストして学習する
- ビジネスステークホルダーとともに評価を行い、進捗状況を見える化しておく
- 測定とユーザーとの面談を通じて、目標としてきた結果が得られたかどうかを正確に把握する
- 新機能、新製品、既存機能の改良などのアイデア(オポチュニティ)に名前をつけて、オポチュニティバックログに入れる
12章 岩を砕く人
- 優れたプロダクトオーナーは、自分が良い判断をするために必要な人々を周りに集めているが、決定はプロダクトオーナーが行う
- プロダクトオーナーが率いる小規模な組織横断チームがプロダクトディスカバリーの仕事を取り仕切る
- プロダクトリーダーがいない場でもストーリーをめぐって無数の会話が交わされても構わない
- ストーリーワークショップ(何を作るかについて具体的に決定を下す最後で最良の会話)には、テスター、製品ディスカバリチームのメンバー、開発者の一人が必要だ
- プロダクトオーナーは簡単な仕事ではないので、ビジネスピープルに押し付けるのではなく、ビジネスピープルを手助けするプロデューサーを見るけることをお勧めする
- ストーリーマッピングは、大きなストーリーを小さなストーリに分解するために役立つ方法の一つ
- 「製品を使う人々」と「何があれば彼らに成功をもたらすことができるのか」を会話の中心に置きながら進めることができる
