• Like
ユーザーストーリーとは?
Upcoming SlideShare
Loading in...5
×

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

  • 108,894 views
Uploaded on

ユーザーすと

ユーザーすと

More in: Technology , Sports
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
108,894
On Slideshare
0
From Embeds
0
Number of Embeds
40

Actions

Shares
Downloads
457
Comments
0
Likes
126

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. ユーザーストーリーとはhttp://www.flickr.com/photos/cannedtuna/4674434821/
  • 2. 吉羽龍太郎 (@Ryuzee) アジャイルコーチ 認定スクラムプロフェショナル(CSP) 認定スクラムマスター(CSM) 認定スクラムプロダクトオーナー(CSPO) http://www.ryuzee.com/ 野村総合研究所等を経てベンチャーのCTOhttp://www.flickr.com/photos/adforce1/2539903964/
  • 3. プロダクトオーナー スクラムマスター チーム (7±2人) ステークホルダー製品に対して責任をもち機能 スクラムプロセスがうまく プロダクトの開発を行う。 製品の利用者、出資者、管理職に優先順位を付ける いくようにする。 製品の成功に向けて最大限 などの利害関係者。鶏と称す 外部からチームを守る の努力をコミットする プロダクトバックログ デイリースクラム 製品の機能をストーリー形式で記載 毎日チームが以下の3つの質問に答える プロダクトオーナーが優先順位を付け、プラ ・昨日やったこと ンニングポーカーで相対見積もり。 ・今日やること 項目の追加はいつでも自由だが実施有無や優 ・困っていること 先順位は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 – 受け入れテストによってストーリーが正しく 実装されているか確認する
  • 8. どちらの作り方を選ぶか?
  • 9. 分割の方向• 技術的レ゗ヤー単位で分割しない – このやり方だと、全てが揃わないとリリース できないリスクがある。• 動作する機能単位で分割する – エンドツーエンドで動作する単位で分割する。 – リリース可能な単位が小さくなる – 早くリリースできることはビジネス価値につ ながる
  • 10. #1 リマインダ飲み会の幹事として飲み会の直前に参加者にリマ゗ンドすることが出来るそれによって参加予定者のドタキャンを防止する見積もり 8 優先順位 20
  • 11. ユーザーストーリーのINVEST Independent Negotiable Valuable Estimable Sized right (Small) Testablehttp://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. 分割 □ プレミゕムメンバーであれば 利用者として キャンセル料なしに宿泊当日にキャホテルの予約をキャンセル ンセルできること することができる □ プレミゕムメンバー以外であれストーリーが大きすぎて受け入 ば、当日キャンセルは宿泊料の10%れ基準が沢山できそうな場合は、 をキャンセル料として請求すること分割のチャンスプレミゕムメンバーとしてギリギリまで予約をキャンセル することができる □ 確認のメールが利用者に送信さ れること一般メンバーとして24時間前まで予約をキャンセルする ことができる □ ホテル側には全てのキャンセル 情報がメールで通知されること利用者として、宿泊をキャンセルした場合は確認のメール が送られること
  • 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 QM...Mandatory(基本) なくてはならないもの。外せないもの。L...Linear(性能) なくてもよいが、あればあるほど良い。E...Exciter(魅力) いわゆる差別化ポ゗ント。Q...Questionable(不明) 回答がおかしい。R...Reverse(逆行) あっては困る。つまり作ってはいけない。I...Indifferent(不問) どうでもよい。作ってもいいが作らなくても良い。