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