1. ユーザーストーリーとは http://www.flickr.com/photos/cannedtuna/4674434821/
2. 吉⽻羽⿓龍龍太郎郎 (@Ryuzee) アジャイルコーチ 認定スクラムプロフェショナル(CSP) 認定スクラムマスター(CSM) 認定スクラムプロダクトオーナー(CSPO) http://www.ryuzee.com/ 野村総合研究所等を経てベンチャーのCTO http://www.flickr.com/photos/adforce1/2539903964/
3. プロダクトオーナー 製品に対して責任をもち機能 に優先順位を付ける スクラムマスター スクラムプロセスがうまく いくようにする。 外部からチームを守る ステークホルダー チーム (7±2⼈人) 製品の利利⽤用者、出資者、管理理職 などの利利害関係者。鶏と称す プロダクトの開発を⾏行行う。 製品の成功に向けて最⼤大限 の努⼒力力をコミットする デイリースクラム プロダクトバックログ 製品の機能をストーリー形式で記載 プロダクトオーナーが優先順位を付け、プラ ンニングポーカーで相対⾒見見積もり。 項⽬目の追加はいつでも⾃自由だが実施有無や優 先順位はPOが決める。 毎⽇日チームが以下の３つの質問に答える ・昨⽇日やったこと ・今⽇日やること ・困っていること バーンダウンチャート Doneの定義 スプリントタスクの「推定残り時間」を 更更新してグラフにプロットする 何をもって「完了了」とするかを 定義したリスト スプリント計画会議 スプリント プロダクトバックログを再度度分析・評価し、 そのスプリントで開発するプロダクトバック ログアイテムを選択する。また選択した項⽬目 をタスクにばらす 最⼤大4週間までのタイムボックス 各スプリントの⻑⾧長さは同⼀一。この間は外部 からの変更更を受け⼊入れない タスク 時間で⾒見見 積もり 毎⽇日の繰り返し スプリントバックログ そのスプリント期間中に⾏行行う タスクのリスト スプリントレビュー スプリント中の成果である 動作するソフトウェアをデモ する ふりかえり スプリントの中での改善事項 を話合い次に繋げる 出荷可能な 製品の増分 複 数 回 ス プ リ ン ト を 繰 り 返 す
4. ユーザーストーリーとは？ 要求仕様を⾃自然⾔言語で簡潔に記述したもの • ＜役割＞として • ＜機能や性能＞が出来る • それは＜ビジネス価値＞のためだ http://www.flickr.com/photos/koalazymonkey/3343007130/
5. ユーザーストーリーとは？ • 顧客との会話に役⽴立立つ • 計画づくりに役⽴立立つ • 無駄な詳細化から解放される
6. 何故ユーザーストーリー？ ユーザストーリーの最も重要な側⾯面は、ユーザ ストーリーが要件（機能）の「スケジュール可 能な」ユニットであり、スケジュールは他に依 存していないということです。ユーザストー リーの「他に依存せずスケジュール可能な」特 徴を実現する鍵となるのが、「ユーザ」がどう 使うかという⽬目線に⽴立立ってユーザストーリーを 表現することです。そうすればユーザが実際に インタラクトできるエンドツーエンド（UIから バックエンド）に実装された機能性のユニット が⼿手に⼊入ります。 InfoQ：ユースケース、それともユーザストーリー？ http://www.infoq.com/jp/news/2008/08/use-‐‑‒case-‐‑‒or-‐‑‒user-‐‑‒story
7. Ron Jeffriesの3C • Card – ストーリーはカードに書き、⾒見見積もりやメモ 等も⼀一緒に書く • Conversation – ストーリーの背後にある詳細事項はPOとの会 話から引き出される • Confirmation – 受け⼊入れテストによってストーリーが正しく 実装されているか確認する
9. 分割の⽅方向 • 技術的レイヤー単位で分割しない – このやり⽅方だと、全てが揃わないとリリース できないリスクがある。 • 動作する機能単位で分割する – エンドツーエンドで動作する単位で分割する。 – リリース可能な単位が⼩小さくなる – 早くリリースできることはビジネス価値につ ながる
10. #1 リマインダ 飲み会の幹事として 飲み会の直前に参加者にリマインドするこ とが出来る それによって参加予定者のドタキャンを防 ⽌止する ⾒見見積もり ８ 優先順位 20
11. ユーザーストーリーのINVEST Independent Negotiable Valuable Estimable Sized right (Small) Testable http://www.flickr.com/photos/wonderwebby/2723279741/
12. Independent • 互いに独⽴立立していること • 依存関係や前後関係はなるべく排除 • 依存関係が⾼高いと⾒見見積もりが難しくなる http://www.flickr.com/photos/infinitejeff/6143582/
13. Negotiable • 交渉可能 • 会話のための道具 • ⼀一度度決めたことが絶対なわけではない http://www.flickr.com/photos/netzkobold/2574295816/
14. Valuable • 価値がある – ステークホルダーにとって – ビジネスにとって – チームにとって http://www.flickr.com/photos/trp0/126774766/
15. Estimable • ⾒見見積もり可能 • ⾒見見積もりできるくらいのストーリーの粒粒度度 http://www.flickr.com/photos/42931449@N07/5336414318/
16. Sized Right • 適切切な⼤大きさ • ⼗十分にストーリーが分割されている http://www.flickr.com/photos/openeye/4905602656/
17. Testable • テスト可能 • 受け⼊入れテストを記述できる http://www.flickr.com/photos/alancleaver/4439276478/
18. システムの利利⽤用者に焦点をあてる • ストーリーの記述ではユーザーロールを意識識す る
19. ユーザーストーリーをもとに議論論 • ユーザーストーリーはチームとステーク ホルダー間の議論論を活性化させるための 道具 • ユーザーストーリーは仕様ではなく、機 能に関する議論論のエッセンスである • 議論論の道具なので、全員が分かる⽤用語を 使う。
20. チーム全体で書く • ユーザーストーリーを書くのに全員が協 ⼒力力する • ユーザーストーリーをより良良くするため に定期的にバックロググルーミングミー ティングを⾏行行う
21. シンプルに保つ • あいまいな表現や⾔言葉葉は避けて誰でも理理 解できる⾔言葉葉で書く • 重要なことにフォーカスし、必要以外の ことは書かない • より良良くするために継続的にリファイン する • GUIやDBレイアウトやアルゴリズム等は 含めない
22. 受け⼊入れ基準とセットにする • 受け⼊入れ基準(Acceptance Criteria)を 使う • 受け⼊入れ基準がある＝テスト可能 • ストーリーは最低３〜～５個の受け⼊入れ基 準を持つ • ここで作成した受け⼊入れ基準は、テスト シナリオとなる(可能ならBDDフレーム ワーク等を使って⾃自動テスト化)
23. #1 リマインダ 受け⼊入れ基準 • 飲み会開催の3⽇日前に参加者にメールで通 知されること • 通知の際には、開催⽇日時、開催場所、緊 急時連絡先が記載されていること • 不不参加者や参加キャンセル者には通知さ れないこと
24. 紙のカードを使う • ユーザーストーリーは紙に書く • ユーザーストーリーの中⾝身はどんどん議 論論されるべきなので⾒見見える壁等に貼って おく
25. ストーリーをグループにわける • ストーリーをグループ分けしてテーマに する • テーマ分けすることで網羅羅性が分かる • テーマ分けすることで優先度度の⾼高いス トーリーが分かる
26. ユーザーストーリーマッピング 「アジャイルな地図作り」 より引⽤用 http://www.slideshare.net/kkd/user-‐‑‒story-‐‑‒mapping-‐‑‒for-‐‑‒agile-‐‑‒team
27. 例例外 • ユーザーストーリーとして記述しにくい ものもある • 通常それはシステムにおける制約・制限 に対する記述であることが多い • 制約としてシステムに重要な影響を及ぼ すものは項⽬目として管理理する
28. 分割 利利⽤用者として ホテルの予約をキャンセル することができる ストーリーが⼤大きすぎて受け⼊入 れ基準が沢⼭山できそうな場合は、 分割のチャンス プレミアムメンバーとしてギ リギリまで予約をキャンセル することができる ⼀一般メンバーとして24時間前 まで予約をキャンセルするこ とができる 利利⽤用者として、宿泊をキャン セルした場合は確認のメール が送られること □ プレミアムメンバーであれば キャンセル料料なしに宿泊当⽇日にキャ ンセルできること □ プレミアムメンバー以外であれ ば、当⽇日キャンセルは宿泊料料の10% をキャンセル料料として請求すること □ 確認のメールが利利⽤用者に送信さ れること □ ホテル側には全てのキャンセル 情報がメールで通知されること
29. ストーリー分割のメリット (1) • ストーリー分割によって、元のストーリー上のいくつか の仕事はやる必要がなくなるかもしれない • ストーリーを⼩小さくした⽅方が扱いやすく、分かりやすい • ストーリーを分割すると、個々のリスクが明らかになる • ストーリー分割によって、変更更への対応が容易易になる。 ⼤大きいストーリーが変更更されると、⼤大きなショックを受 けるけど、⼩小さなストーリーならショックも⼩小さい • ⼩小さなストーリーの⽅方が複数⼈人で同時作業しやすい。ス トーリーが⼤大きくて専⾨門知識識が必要だったりすると、⼀一 ⼈人の⼈人にそのストーリーを任せる傾向にあるが、⼩小さく 分割されていれば、専⾨門的知識識がなくてもできるところ が沢⼭山ある
30. ストーリー分割のメリット (2) • ストーリー分割によって、本当のストーリーのサイズが 明らかになる。ストーリーポイントが13のストーリーを 3つに分割してみたら、個々のストーリーポイントはそ れぞれ8だった、みたいなことを良良く⾒見見てきた。これは 不不確実ということではなくて、⾃自分たちの限界を超える ようなものは何でも”Big” と判断してしまう傾向にある からだ。 • ストーリー分割によって、新たな品質標準を使うことが 出来るようになる。例例として、あるレポートシステムは ２種類の似たようなレポート機能を持っていて、１つは 毎時動作し、もう⼀一つは1年年に1回しか動作しない。毎時 のレポートは年年次のレポートよりも⾼高い品質が必要とさ れていた。あんまり良良い例例ではないかもしれないけど、 相対する概念念については分かるだろう。
31. ストーリー分割のメリット (3) • ストーリーが正しく分割されるとテストしやすくなる • ストーリー分割はパフォーマンスの問題を切切り離離すこと ができる。元のストーリーの⼀一部の機能がパフォーマン スに影響を与えるかもしれないというような場合に、パ フォーマンステストの優先順位を⾼高くすることができる • ストーリー分割することで、より消化しやすいチャンク にすることができ、スプリントにぴったりはまるように なる
32. プロダクトバックログの管理理 • ユーザーストーリーを集めたものがプロ ダクトバックログ • この中には沢⼭山の項⽬目は⼊入れすぎない – 通常100個以内程度度に収める – 成熟度度が低いチームであれば50個程度度まで
33. PBI優先順位決定の原則 • • • • ⾼高い価値のものから 市場投⼊入への時間を短く リスクを最⼩小化 将来の無駄を避ける
34. 優先順位の決め⽅方（狩野モデル） • フィーチャーが実現された場合、 実現されない場合にどう考えるかを ５択で選ぶ Q1:ホテルの部屋に無料料のミネラルウォーターが あったらどう思いますか？ 1. とても嬉しい 2. それって普通でしょ 3. 特になんとも思わない 4. 別にそれでも構わない 5. それは困る Q2:ホテルの部屋に無料料のミネラルウォーターが なかったらどう思いますか？ 1. とても嬉しい 2. それって普通でしょ 3. 特になんとも思わない 4. 別にそれでも構わない 5. それは困る http://www.flickr.com/photos/darrylh/392577074/
35. 狩野モデル ⾮非実現時1 ⾮非実現時2 ⾮非実現時3 ⾮非実現時4 ⾮非実現時5 実現時1 Q E E E L 実現時2 R I I I M 実現時3 R I I I M 実現時4 R I I I M 実現時5 R R R R Q M...Mandatory(基本) なくてはならないもの。外せないもの。 L...Linear(性能) なくてもよいが、あればあるほど良良い。 E...Exciter(魅⼒力力) いわゆる差別化ポイント。 Q...Questionable(不不明) 回答がおかしい。 R...Reverse(逆⾏行行) あっては困る。つまり作ってはいけない。 I...Indifferent(不不問) どうでもよい。作ってもいいが作らなくても良良い。
