Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

POStudy Conference 2012 - ユーザーストーリーマッピング

1,181 views

Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

POStudy Conference 2012 - ユーザーストーリーマッピング

  1. 1. POStudy Day 2013 Spring in Tokyoユーザーストーリーマッピング2012年11月04日(日)POStudy@fullvirtueCopyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved.POStudyConference
  2. 2. Copyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved.今日のアジェンダ(1/1)第2回,第3回,第4回各チーム振り返り結果ご紹介ユーザーストーリーマッピング解説ワークショップ #1ワークショップ #2ワークショップ #3ワークショップ #4ワークショップ #5ワークショップ #6ワークショップ #7振り返り&ディスカッション2
  3. 3. おことわり(1/1)今回の資料について(1/1) 今回の資料は、以下の資料を参考にしています。私自身のオリジナルはほとんどありませんので、ご了承ください。 前半のプロダクトバックログの説明部分と後半のワークショップは、@kawaguti さんがScrum Boot Campで使用した資料を参考にさせて頂いています。 前半のユーザーストーリーの説明部分については、@ryuzee さんの公開資料を参考にさせて頂いています。http://www.slideshare.net/Ryuzee/ss-8332120 ワークショップの内容は、Jeff PattonさんがScrum GatheringTokyo 2011 Day2で実施したワークショップを参考にさせて頂いています。Copyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved. 3
  4. 4. 第2回各チーム振り返り結果ご紹介前回の振り返り結果をご紹介します4
  5. 5. 第2回各チーム振り返り結果ご紹介(1/2)Aチーム(1/1) Keep– ストーリーと時系列に並べて抜けた見えた– ペルソナがあるとイメージしやすい– システム化不要なモノが意外と多いことに気づいた problem– 時間が足りない、ペルソナ読むヒマない– 背景が複雑だった→ストーリーが発散した– 独立しているストーリーにはなっていない– 価値が高いストーリーから出すことができなかった Try– 時間を増やす、ワークショップの時間を長く– 開始時間に間に合うようにする、話を単純にする– ストーリー出しはブレスト方式の方が良いかな・・– 個人ワークの前にチームで話す時間が欲しい– 自己紹介する時間を取るBチーム(1/1)– ストーリーカードに書くと要件が小さくなって良い– 字はきれいに書きたい– 書く項目が多くて時間がかかる» 色を使い分けると良いのでは» 色で区別出来る» 記号を使う– カードの重なり具合でチームの考え方の傾向がわかる– ストーリーを逆からも考える» 双方向からだと抜けが少なくなる– 時間が区切られていないと考えが発散する– 見通しをよくする工夫– 概要のフローがあると良い5
  6. 6. 第2回各チーム振り返り結果ご紹介(2/2)Cチーム(1/1)– 最小限の機能» 業務知識が高い» 集約がうまかった– 作り手が作りたくなるシンプルさ– ストーリーが軽い– モチベーションが下がらないDチーム(1/1)– 利用者の中でも重要人物に絞ると軽量化できる– 幹事側の方が多かった– なぜか» 「自分が幹事だったら」という前提をおいてしまったから» 「利用者目線」で書けていなかったかも– ユーザーストーリー作成時» 互いのズレがあった» ワークショップを通して、認識のズレを解消できたと思う(短い時間でも)– 「利用者」1人1人にもっと注目していけば、挙げられなかったストーリーが出てくると思う6
  7. 7. 第3回各チーム振り返り結果ご紹介前回の振り返り結果をご紹介します7
  8. 8. 第3回各チーム振り返り結果ご紹介(1/3)Aチーム(1/1) Keep– 自己紹介の時間は有意義だった– ワークショップは面白い– プランニングポーカーの意識合わせは面白い– 振り返りのKPTのフレームは、次に使えそう– プランニングポーカーは認識のズレをあぶり出すには手軽で良い problem– 時間が足りない、– プランニングポーカーの見積は、スキルによる差の考慮が必要そう Try– 終了時間を遅らせる– プランニングポーカーに適切なストーリーの粒度を見極めたいBチーム(1/2) Keep– 各ワークショップで、個々のやり方の話ができた– プランニングポーカーが面白かった– 相対見積Good!– チームの意志が合ってきた problem– 部屋が暑い– デモストーリーの作成の時間がもっと欲しい– デモの案を出すとき、拡散しすぎて終わらなかった– チームの意識合わせに時間を取られた– ワークショップの時間はもう少し欲しい8
  9. 9. 第3回各チーム振り返り結果ご紹介(2/3)Bチーム(2/2) Try– 1人1人が話せる場が欲しい– 1日当たりの勉強会のスケジュールをもっとゆるやかにしても良いのでは?– もっとプランニングポーカーがしたい!– 基準を変えたプランニングポーカーをやってみたい。– デモを行うという前提に立った作業を意識しながら– 重要とするアクターを決めないといけない– 誰に対して「価値」を与えるか– スプリントバックログまで落とし込んでみたいCチーム(1/1) Keep» 初参加者へのフォローがあり、初参加者が増えてよかった» メインの機能(ユーザーストーリー)を5で見積もったことで、見積が簡単にできた» 見積もりできてチーム内の合意が取れたこと» 見直しによるシステムの効率化が出来て、開発規模がスリム化したこと problem» 見積の時間が断然足りなすぎ、、、ですw» 優先順位を付けるワークショップがなかった Try» ワークショップのタイムボックスを増やして貰えるように働きかけてみたい» 振り返りの時間は初参加者としてはありがたいが、時間が足りなくなるので事前に各自自習を義務づける9
  10. 10. 第3回各チーム振り返り結果ご紹介(3/3)Dチーム(1/2) 気づき» ユーザーストーリーは、タスクレベルで書いてしまうのを避けるべき» プランニングポーカーの「0」の意味 = ToDoやらないといけないけど、すぐおわるただし、めったにない» 何かやることがあるならば、プランニングポーカーでは「1」とすべき» プランニングポーカーでは、だいたい「13」が最大のボリューム» プランニングポーカーで「13」を超える場合、ユーザーストーリーの分解を検討するDチーム(2/2) 気づき» プランニングポーカーのワークショップは、時間が足りなかった» アジャイルを初めて実践する際、最初は時間が掛かることを身をもって実感できた» 時間の意識を持って、今後は取り組みたい» ユーザーストーリーを見積出来るレベルまで詳細化する必要があると思った» プロダクトオーナーとして、ストーリーを立てて提示することを覚えると、プランニングポーカーの精度が高くなるまた、ストーリーの粒度も適切に分解出来ると思った» ユーザーストーリーを見直すと、頂いたサンプルの形式で書くことは重要» ユーザーストーリーは、交渉の余地がある書き方にする必要がある10
  11. 11. 第4回各チーム振り返り結果ご紹介前回の振り返り結果をご紹介します11
  12. 12. 第4回各チーム振り返り結果ご紹介(1/10)Aチーム(1/2) Keep– 最低限の機能に絞る– ファーストリリースを検討する際に、足りないユーザーストーリーをアジャイルに追加したのが良かった– ユーザーストーリーマッピングに触れてよかった– ワークショップ参加は楽しい– 笑って楽しかった– いろいろな意見に触れられて勉強になった– 多様な意見– 新しい人とご挨拶12
  13. 13. 第4回各チーム振り返り結果ご紹介(2/10)Aチーム(2/2) problem– 立ち位置が混乱した– セカンドストーリーが決まらなかった– 見積もれなかった– 価値の話が出てくるとわかりにくい– 話さないと皆が何を思っているのかがわからない→前提を合わせていないから?– 認識合わせに時間がかかった– 言葉の認識の違いがあったなぁ– 思ったほどスピードが出ない– 細かい仕様に話が行ってしまう Try– ペルソナは初めての人も読む– 優先順位を話し合って情報共有したい– さらにチーム内のコミュニケーションアップを図って、効率よくストーリー作業する♪– 笑いまくる– 運用でカバー– 誰をターゲットにして価値を出すか決めてからストーリーの優先順位を決めたい– リリースの線を引きたい– 価値の認識を合わせることを先に行う– 価値・優先度を考える意識をする13
  14. 14. 第4回各チーム振り返り結果ご紹介(3/10)Bチーム(1/1) Keep– ストーリーのそぎ落とし– 役割を分担してストーリーを作ったのが成功した– 納得いくまで話した(ポーカー)– 使うカードを絞ったのが良かった(ポーカー)– 楽しかった problem– doneを書く時間がなかった– ポーカーの軸ストーリーが後半ゆらいだ Try– doneをきちんと裏に書こう– 話し合うこと– ふりかえること– ポーカーの基本ストーリーは小さいストーリーでやってみる14
  15. 15. 第4回各チーム振り返り結果ご紹介(4/10)Cチーム(1/2) Keep– アーキテクチャまで掘り下げて議論したので、見積が揃いやすかった– 各テーブルに経験者とはじめての方がいて、スムーズでした– スクラム経験者をまんべんなく入れるのは良いと思いました– スクラムの進め方がどういうものかよく分かった– ポーカーを始めての人に説明することで、自分も再認識– システム化範囲を考えて、最優先事項を導き出した– 画面イメージがあると話しやすい15
  16. 16. 第4回各チーム振り返り結果ご紹介(5/10)Cチーム(2/2) problem– 作らねばならないもののレギュレーションについては、もう少し細かく説明した方がよいと思う– 青でまとめたものをアクティビティと呼んでしまってもよかったのでは?– フローをみて書いたのでまとまった– 知識が足りない– 実際のユーザーがいないので、不明点が仮説の積み重ねになってしまう– 行動の洗い出しとソフトウェアでサポートするものをどう議論するか Try– 時間があれば予定をきめるところから– ユーザーの規模とか決定をもっと明確にしてあたれば良いモノを考えられたかな– プラグマティックペルソナを作る系のワークもやりたい16
  17. 17. 第4回各チーム振り返り結果ご紹介(6/10)Dチーム(1/2) Keep– 前回よりストーリーの深掘りが出来てよかった– 人間系と機械系の切り分けがはっきりしていた「人がやればいいでしょ」– 各ストーリーのストーリーポイントが収束している– 早く完成させることの目的を共有出来た– 小さい単位にストーリーを落とすことが出来た– 自己紹介の2週目は良かった problem– プロダクトオーナーなのにタスク(作業)レベルの見積になってしまった– ストーリーが小さすぎた– 技術面を洗い出しすぎる– フローをちゃんと理解してなかった– 勝手な要求をしてしまった– 受入条件がきちんと書けなかった– 見積の基準数字が小さいので場合によってはブレが大きくなるかも– どれくらい価値があるかもっと議論してもよかった機がする– 有効性をアピールする機能についてフォーカスをしてもよかった– 基準としたポイントが小さすぎて1~3にすべておさまってしまった17
  18. 18. 第4回各チーム振り返り結果ご紹介(7/10)Dチーム(2/2) problem– 見積時、幹事観点ばかりで出資者、参加者の観点がなかった– タイムボックスを意識してなかったので、見積が終わらなかった Try– タイムボックスを意識して、各ワークショップを確実に完了させる– プロダクトの題材を商用レベルのものにする– フローとペルソナの読み合わせをしたい– 受入条件を書く時間を取る– 中くらいのストーリーを5ストーリーポイントくらいで基準にすべき– どう展開出来るか考える– 参加者がすごく多い場合のユーザーストーリーの見積をしたい– 対象とするストーリーを絞ってでも完了基準を書くべき18
  19. 19. 第4回各チーム振り返り結果ご紹介(8/10)Eチーム(1/1) Keep– この場に来たことそのもの– 以前やったときの復習になった– ユーザーストーリーに対する認識を合わせることに気づいたこと– 時間配分(チーム内)が良かった→余裕あった– コンパクトなリリースに向けての方向性が合ってたこと problem– ユーザーストーリーの認識が合ってなかったこと→どうやって合わせる?– 受入条件を見てなかった– 受入条件を短い時間で書くのが難しい– 利用者の行動順に考えていたので後ろの方のユーザーストーリーが充実しなかった Try– 実際の仕事で使いたい→ヒアリングの時→ブレストの一環として– 継続的に復習していきたい– 自社で勉強会! →POもメンバーも– ストーリー出しの2週目(イテレーション)の後にやってみる– 受入条件をきちんと書く– ペルソナをおいてみる→よりユーザーストーリーマッピングらしく 疑問– 実際のお客様とどうやってこの手法を使うか– ユーザーストーリーマッピングの前後左右の知識がないので、応用方法がわからない19
  20. 20. 第4回各チーム振り返り結果ご紹介(9/10)Fチーム(1/2) Keep– 見積でいろいろな話を聞けた– 見積の細かい擦り合わせ– リリース物件のイメージができた– ストーリーに分解する前に全体感を共有できて話がスムーズだった– スコープを決めるのが早くできた– プロダクトへの要求をシンプルにまとめることができた– ワークショップの時間が長くなった– ストーリーポイントを相対的に出すことで、一つ一つの大きさが把握出来てよかった– ストーリー作成に参加出来た20
  21. 21. 第4回各チーム振り返り結果ご紹介(10/10)Fチーム(2/2) problem– 最後まで見積もれなかった– 確認方法が書けなかった– 机の線の使い方、付箋のまとめ方は、先に共有したかった Try– 時間足りなかった– 時間配分間違えた– ストップウォッチを活用する– (チーム内で)時間を先にアナウンスする→タイムボックスを意識する– タイムキーパーを決める– 時計をテーブルに置く– タイムキープできるようにマイルストンを設定する (ex ~分までに決める) Try– プロダクトの機能を固めるまえに見積を始めてしまった– ストーリーの内容をすりあわせたかった– 見積前に前提条件を共有する– 見積前にストーリーのDoneの定義を裏書きする– 最初にプロダクトの共有を詳しくやっておくべき– PJの前提の共有をする→どんなプロダクト?21
  22. 22. ユーザーストーリーマッピング解説ユーザーストーリーについて説明していきますCopyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved. 22【参考:@ryuzee ユーザーストーリーとは?】http://www.slideshare.net/Ryuzee/ss-8332120
  23. 23. ユーザーストーリーマッピング解説(1/15)ユーザーストーリーとは(1/2) 要求仕様を自然言語で簡潔に記述したもの [役割]として [結果]が欲しい それは [理由]のためだ [役割]として [機能や性能]が欲しい それは [ビジネス価値]のためだCopyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved. 23
  24. 24. ユーザーストーリーマッピング解説(2/15)ユーザーストーリーとは(2/2) 顧客との会話に役立つ 計画づくりに役立つ 無駄な詳細化から解放されるCopyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved. 24
  25. 25. ユーザーストーリーマッピング解説(3/15)なぜユーザーストーリーが必要なのか(1/1) 要件(機能)のスケジュールが可能なユニット– スケジュールは他に依存していない ユーザーがどう使うかという目線に立って表現– 他に依存せずにスケジュール可能な特徴を実現Copyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved. 25
  26. 26. ユーザーストーリーマッピング解説(4/15)Ron Jeffries の 3C / 3Cs(1/1) Card– ストーリーはカードに書き、見積もりやメモ等も一緒に書く Conversation– ストーリーの背後にある詳細事項はPOとの会話から引き出される Confirmation– 受け入れテストによってストーリーが正しく実装されているか確認するCopyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved. 26
  27. 27. ユーザーストーリーマッピング解説(5/15)どちらの作り方を選びますか?(1/1)Copyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved. 27
  28. 28. ユーザーストーリーマッピング解説(6/15)分割の方向(1/1) 技術的レイヤー単位で分割しない– このやり方だと、全てが揃わないとリリースできないリスクがある。 動作する機能単位で分割する– エンドツーエンドで動作する単位で分割する。– リリース可能な単位が小さくなる– 早くリリースできることはビジネス価値につながるCopyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved. 28
  29. 29. ユーザーストーリーマッピング解説(7/15)ユーザーストーリーのINVEST(1/7) INVESTとは Independent 独立 Negotiable 交渉可能 Valuable 価値 Estimable 見積可能 Sized right (Small ) 適切な大きさ Testable テスト可能Copyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved. 29
  30. 30. ユーザーストーリーマッピング解説(8/15)ユーザーストーリーのINVEST(2/7) Independent 互いに独立していること 依存関係や前後関係はなるべく排除 依存関係が高いと見積が難しくなるCopyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved. 30
  31. 31. ユーザーストーリーマッピング解説(9/15)ユーザーストーリーのINVEST(3/7) Negotiable 交渉可能 会話のための道具 一度決めたことが絶対なわけではないCopyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved. 31
  32. 32. ユーザーストーリーマッピング解説(10/15)ユーザーストーリーのINVEST(4/7) Valuable 価値がある– ステークホルダーにとって– ビジネスにとって– チームにとってCopyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved. 32
  33. 33. ユーザーストーリーマッピング解説(11/15)ユーザーストーリーのINVEST(5/7) Estimable 見積可能 見積できるくらいのストーリー粒度Copyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved. 33
  34. 34. ユーザーストーリーマッピング解説(12/15)ユーザーストーリーのINVEST(6/7) Sized Right 適切な大きさ 十分にストーリーが分割されているCopyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved. 34
  35. 35. ユーザーストーリーマッピング解説(13/15)ユーザーストーリーのINVEST(7/7) Testable テスト可能 受入テストを記述できるCopyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved. 35
  36. 36. ユーザーストーリーマッピング解説(14/15)ユーザーストーリー作成時の大切なこと(1/1) システムの利用者に焦点をあてる ストーリーの記述では、ユーザーロールを意識するCopyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved. 36
  37. 37. ユーザーストーリーマッピング解説(15/15)PBI優先順位決定の原則(1/1) 高い価値のものから 市場投入への時間を短く リスクを最小化 将来の無駄を避ける– PBI:Product Backlog ItemCopyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved. 37
  38. 38. ワークショップ#1各チームごとに改めて自己紹介を行ってください(チームワークショップ)38
  39. 39. 今日の進め方今日は第2回・第3回で実施したワークショップ#1~#6のユーザーストーリーの作成を、 30分間で実施していきます次に残り30分を使って、プランニングポーカーを使いながら、ユーザーストーリーの見積をしていきます39
  40. 40. ワークショップ#2題材を元に、10分間で黄色い付箋紙にユーザーストーリーを書き出していってください裏には受入条件を記載してください(個人ワークショップ)40
  41. 41. ワークショップ#3チーム単位で、5分間で左から右へ時系列に並べてください(チームワークショップ)41
  42. 42. ワークショップ#4チーム単位で、5分間で似たタスクをまとめてください今までのワークショップで遅れを取っている場合は、この5分間で遅れを取り戻してください(チームワークショップ)42
  43. 43. ワークショップ#5チーム単位で、5分間でやっていることが変わっているところの上部に、青い付箋紙を貼ってください青い付箋紙には、そのまとまりの概要を書いてください(チームワークショップ)43
  44. 44. ワークショップ#544
  45. 45. ワークショップ#545
  46. 46. ワークショップ#6机の真ん中を境界線とします。チーム単位で5分間で最初のリリース対象にするものを境界線の上部に、次回以降のリリース対象にするものを境界線の下部にそれぞれ付箋紙を移動してください(チームワークショップ)46
  47. 47. ワークショップ#647
  48. 48. ワークショップ#648
  49. 49. スプリントとリリース解説スプリントとリリースについて解説します49
  50. 50. スプリントとリリース(1/2)スプリントとリリース(1/2)50【参考:@kawaguti - 20110118 scrum 10 mins】http://www.slideshare.net/kawaguti/20110118-scrum-10-mins
  51. 51. スプリントとリリース(2/2)スプリントとリリース(2/2)51【参考:@kawaguti - 20110118 scrum 10 mins】http://www.slideshare.net/kawaguti/20110118-scrum-10-mins
  52. 52. プランニングポーカーと見積もり解説プランニングポーカーと見積もりについて説明します52
  53. 53. プランニングポーカーと見積もり(1/3)プランニングポーカー(1/2)53【参考:@ryuzee – Scrum概論】http://www.slideshare.net/Ryuzee/scrum-8048905
  54. 54. プランニングポーカーと見積もり(2/3)プランニングポーカー(2/2) プランニングポーカーの進め方1. 基準となるストーリーを決めます。(早めに着手するであろう)基本的なストーリーで、全員が内容を想像でき、規模の小さいものを選びます。基準のストーリーのポイントを2とします。2. 次のストーリーを選び、その規模を相対的に考え、カードで一斉に示します。3. 数が食い違っている場合は、一番大きい数を出した人、一番小さい数を出した人に理由を言ってもらい、その情報を共有します。2に戻ります。4. 数が一致した場合はその数で確定です。5. 2~3回行って僅差なら、大きい数字を採用します。54【参考:@kawaguti - 20110118 scrum 10 mins】http://www.slideshare.net/kawaguti/20110118-scrum-10-mins
  55. 55. プランニングポーカーと見積もり(3/3)相対的な見積もり(1/1)55【参考:@ryuzee – Scrum概論】http://www.slideshare.net/Ryuzee/scrum-8048905
  56. 56. ワークショップ#7各チーム毎に、30分間でユーザーストーリーを見積してください見積する際に、ストーリーポイントの基準をチーム内で決定し、その基準を元にプランニングポーカーを使って見積を実施してください(チームワークショップ)56
  57. 57. 振り返り&ディスカッション今日気づいたことをテーブルごとに共有してください各チームでの振り返り結果を、配布したA3用紙に記載してください次回、全チームの振り返り結果をまとめたものをご連絡します57
  58. 58. まとめ今日お話したことを振り返ってみましょう58
  59. 59. Copyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved.今日お話したこと(1/1)第3回の復習第3回各チーム振り返り結果ご紹介ワークショップ #1ワークショップ #2ワークショップ #3ワークショップ #4ワークショップ #5ワークショップ #6ワークショップ #7振り返り&ディスカッション59
  60. 60. Copyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved. 60ご静聴ありがとうございました。

×