ユーザーストーリーとは?

スクラムなどでよく使われるユーザーストーリーに関する説明

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が決める。 毎⽇日チームが以下の3つの質問に答える ・昨⽇日やったこと ・今⽇日やること ・困っていること バーンダウンチャート 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 –  受け⼊入れテストによってストーリーが正しく 実装されているか確認する
8. どちらの作り⽅方を選ぶか?
9. 分割の⽅方向 •  技術的レイヤー単位で分割しない –  このやり⽅方だと、全てが揃わないとリリース できないリスクがある。 •  動作する機能単位で分割する –  エンドツーエンドで動作する単位で分割する。 –  リリース可能な単位が⼩小さくなる –  早くリリースできることはビジネス価値につ ながる
10. #1  リマインダ 飲み会の幹事として 飲み会の直前に参加者にリマインドするこ とが出来る それによって参加予定者のドタキャンを防 ⽌止する ⾒見見積もり 8 優先順位 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)を 使う •  受け⼊入れ基準がある=テスト可能 •  ストーリーは最低3〜~5個の受け⼊入れ基 準を持つ •  ここで作成した受け⼊入れ基準は、テスト シナリオとなる(可能なら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”  と判断してしまう傾向にある からだ。 •  ストーリー分割によって、新たな品質標準を使うことが 出来るようになる。例例として、あるレポートシステムは 2種類の似たようなレポート機能を持っていて、1つは 毎時動作し、もう⼀一つは1年年に1回しか動作しない。毎時 のレポートは年年次のレポートよりも⾼高い品質が必要とさ れていた。あんまり良良い例例ではないかもしれないけど、 相対する概念念については分かるだろう。
31. ストーリー分割のメリット  (3) •  ストーリーが正しく分割されるとテストしやすくなる •  ストーリー分割はパフォーマンスの問題を切切り離離すこと ができる。元のストーリーの⼀一部の機能がパフォーマン スに影響を与えるかもしれないというような場合に、パ フォーマンステストの優先順位を⾼高くすることができる •  ストーリー分割することで、より消化しやすいチャンク にすることができ、スプリントにぴったりはまるように なる
32. プロダクトバックログの管理理 •  ユーザーストーリーを集めたものがプロ ダクトバックログ •  この中には沢⼭山の項⽬目は⼊入れすぎない –  通常100個以内程度度に収める –  成熟度度が低いチームであれば50個程度度まで
33. PBI優先順位決定の原則 •  •  •  •  ⾼高い価値のものから 市場投⼊入への時間を短く リスクを最⼩小化 将来の無駄を避ける
34. 優先順位の決め⽅方(狩野モデル) •  フィーチャーが実現された場合、 実現されない場合にどう考えるかを 5択で選ぶ 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(不不問) どうでもよい。作ってもいいが作らなくても良良い。
No comments...
Attractor Inc. Founder / CTO / Agile Coach / Certified Scrum Professional / Certified ScrumMaster / Certified Scrum Product Owner Twitter : @ryuzee Web : https://www.attractor.co.jp/ Web : http://www.ryuzee.com/

Related Slides