More Related Content
Similar to POStudy Day 2012 in Okinawa - ユーザーストーリーマッピング
Similar to POStudy Day 2012 in Okinawa - ユーザーストーリーマッピング (20)
POStudy Day 2012 in Okinawa - ユーザーストーリーマッピング
- 1. POStudy Day 2013 Spring in Tokyo
ユーザーストーリーマッピング
2012年12月01日(土)POStudy
@fullvirtue
Copyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved.
POStudy Day
in Okinawa
- 2. Copyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved.
今日のアジェンダ(1/1)
第2回,第3回,第4回各チーム振り返り結果ご紹介
ユーザーストーリーマッピング解説
ワークショップ #1
ワークショップ #2
ワークショップ #3
ワークショップ #4
ワークショップ #5
ワークショップ #6
ワークショップ #7
振り返り&ディスカッション
2
- 5. 第2回各チーム振り返り結果ご紹介(1/2)
Aチーム(1/1)
Keep
– ストーリーと時系列に並べて抜けた見えた
– ペルソナがあるとイメージしやすい
– システム化不要なモノが意外と多いことに気づいた
problem
– 時間が足りない、ペルソナ読むヒマない
– 背景が複雑だった→ストーリーが発散した
– 独立しているストーリーにはなっていない
– 価値が高いストーリーから出すことができなかった
Try
– 時間を増やす、ワークショップの時間を長く
– 開始時間に間に合うようにする、話を単純にする
– ストーリー出しはブレスト方式の方が良いかな・・
– 個人ワークの前にチームで話す時間が欲しい
– 自己紹介する時間を取る
Bチーム(1/1)
– ストーリーカードに書くと要件が小さくなって良
い
– 字はきれいに書きたい
– 書く項目が多くて時間がかかる
» 色を使い分けると良いのでは
» 色で区別出来る
» 記号を使う
– カードの重なり具合でチームの考え方の傾向がわ
かる
– ストーリーを逆からも考える
» 双方向からだと抜けが少なくなる
– 時間が区切られていないと考えが発散する
– 見通しをよくする工夫
– 概要のフローがあると良い
5
- 6. 第2回各チーム振り返り結果ご紹介(2/2)
Cチーム(1/1)
– 最小限の機能
» 業務知識が高い
» 集約がうまかった
– 作り手が作りたくなるシンプルさ
– ストーリーが軽い
– モチベーションが下がらない
Dチーム(1/1)
– 利用者の中でも重要人物に絞ると軽量化できる
– 幹事側の方が多かった
– なぜか
» 「自分が幹事だったら」
という前提をおいてしまったから
» 「利用者目線」で書けていなかったかも
– ユーザーストーリー作成時
» 互いのズレがあった
» ワークショップを通して、認識のズレを
解消できたと思う(短い時間でも)
– 「利用者」1人1人にもっと注目していけば、
挙げられなかったストーリーが出てくると思う
6
- 8. 第3回各チーム振り返り結果ご紹介(1/3)
Aチーム(1/1)
Keep
– 自己紹介の時間は有意義だった
– ワークショップは面白い
– プランニングポーカーの意識合わせは面白い
– 振り返りのKPTのフレームは、次に使えそう
– プランニングポーカーは認識のズレをあぶり出すには
手軽で良い
problem
– 時間が足りない、
– プランニングポーカーの見積は、スキルによる差の
考慮が必要そう
Try
– 終了時間を遅らせる
– プランニングポーカーに適切なストーリーの粒度を
見極めたい
Bチーム(1/2)
Keep
– 各ワークショップで、個々のやり方の話ができた
– プランニングポーカーが面白かった
– 相対見積Good!
– チームの意志が合ってきた
problem
– 部屋が暑い
– デモストーリーの作成の時間がもっと欲しい
– デモの案を出すとき、拡散しすぎて終わらなかっ
た
– チームの意識合わせに時間を取られた
– ワークショップの時間はもう少し欲しい
8
- 9. 第3回各チーム振り返り結果ご紹介(2/3)
Bチーム(2/2)
Try
– 1人1人が話せる場が欲しい
– 1日当たりの勉強会のスケジュールを
もっとゆるやかにしても良いのでは?
– もっとプランニングポーカーがしたい!
– 基準を変えたプランニングポーカーをやってみたい。
– デモを行うという前提に立った作業を意識しながら
– 重要とするアクターを決めないといけない
– 誰に対して「価値」を与えるか
– スプリントバックログまで落とし込んでみたい
Cチーム(1/1)
Keep
» 初参加者へのフォローがあり、初参加者が増えて
よかった
» メインの機能(ユーザーストーリー)を5で見積
もったことで、見積が簡単にできた
» 見積もりできてチーム内の合意が取れたこと
» 見直しによるシステムの効率化が出来て、開発規
模がスリム化したこと
problem
» 見積の時間が断然足りなすぎ、、、ですw
» 優先順位を付けるワークショップがなかった
Try
» ワークショップのタイムボックスを増やして貰え
るように働きかけてみたい
» 振り返りの時間は初参加者としてはありがたいが、
時間が足りなくなるので事前に各自自習を義務づ
ける
9
- 10. 第3回各チーム振り返り結果ご紹介(3/3)
Dチーム(1/2)
気づき
» ユーザーストーリーは、タスクレベルで書いてしまう
のを避けるべき
» プランニングポーカーの「0」の意味 = ToDo
やらないといけないけど、すぐおわる
ただし、めったにない
» 何かやることがあるならば、プランニングポーカーで
は「1」とすべき
» プランニングポーカーでは、だいたい「13」が
最大のボリューム
» プランニングポーカーで「13」を超える場合、
ユーザーストーリーの分解を検討する
Dチーム(2/2)
気づき
» プランニングポーカーのワークショップは、
時間が足りなかった
» アジャイルを初めて実践する際、最初は時間が
掛かることを身をもって実感できた
» 時間の意識を持って、今後は取り組みたい
» ユーザーストーリーを見積出来るレベルまで
詳細化する必要があると思った
» プロダクトオーナーとして、ストーリーを立てて
提示することを覚えると、プランニングポーカー
の精度が高くなる
また、ストーリーの粒度も適切に分解出来ると
思った
» ユーザーストーリーを見直すと、頂いたサンプル
の形式で書くことは重要
» ユーザーストーリーは、交渉の余地がある書き方
にする必要がある
10
- 13. 第4回各チーム振り返り結果ご紹介(2/10)
Aチーム(2/2)
problem
– 立ち位置が混乱した
– セカンドストーリーが決まらなかった
– 見積もれなかった
– 価値の話が出てくるとわかりにくい
– 話さないと皆が何を思っているのかがわからない
→前提を合わせていないから?
– 認識合わせに時間がかかった
– 言葉の認識の違いがあったなぁ
– 思ったほどスピードが出ない
– 細かい仕様に話が行ってしまう
Try
– ペルソナは初めての人も読む
– 優先順位を話し合って情報共有したい
– さらにチーム内のコミュニケーションアップを
図って、効率よくストーリー作業する♪
– 笑いまくる
– 運用でカバー
– 誰をターゲットにして価値を出すか決めてからス
トーリーの優先順位を決めたい
– リリースの線を引きたい
– 価値の認識を合わせることを
先に行う
– 価値・優先度を考える意識をする
13
- 17. 第4回各チーム振り返り結果ご紹介(6/10)
Dチーム(1/2)
Keep
– 前回よりストーリーの深掘りが出来てよかった
– 人間系と機械系の切り分けが
はっきりしていた
「人がやればいいでしょ」
– 各ストーリーのストーリーポイントが収束している
– 早く完成させることの目的を共有出来た
– 小さい単位にストーリーを落とすことが出来た
– 自己紹介の2週目は良かった
problem
– プロダクトオーナーなのにタスク(作業)レベル
の見積になってしまった
– ストーリーが小さすぎた
– 技術面を洗い出しすぎる
– フローをちゃんと理解してなかった
– 勝手な要求をしてしまった
– 受入条件がきちんと書けなかった
– 見積の基準数字が小さいので
場合によってはブレが大きくなるかも
– どれくらい価値があるかもっと
議論してもよかった機がする
– 有効性をアピールする機能について
フォーカスをしてもよかった
– 基準としたポイントが小さすぎて
1~3にすべておさまってしまった
17
- 19. 第4回各チーム振り返り結果ご紹介(8/10)
Eチーム(1/1)
Keep
– この場に来たことそのもの
– 以前やったときの復習になった
– ユーザーストーリーに対する
認識を合わせることに気づいたこと
– 時間配分(チーム内)が良かった
→余裕あった
– コンパクトなリリースに向けての
方向性が合ってたこと
problem
– ユーザーストーリーの認識が合ってなかったこと
→どうやって合わせる?
– 受入条件を見てなかった
– 受入条件を短い時間で書くのが難しい
– 利用者の行動順に考えていたので後ろの方のユーザー
ストーリーが充実しなかった
Try
– 実際の仕事で使いたい
→ヒアリングの時
→ブレストの一環として
– 継続的に復習していきたい
– 自社で勉強会! →POもメンバーも
– ストーリー出しの2週目(イテレーション)の後
にやってみる
– 受入条件をきちんと書く
– ペルソナをおいてみる
→よりユーザーストーリーマッピングらしく
疑問
– 実際のお客様とどうやってこの手法を使うか
– ユーザーストーリーマッピングの前後左右の知識
がないので、応用方法がわからない
19
- 21. 第4回各チーム振り返り結果ご紹介(10/10)
Fチーム(2/2)
problem
– 最後まで見積もれなかった
– 確認方法が書けなかった
– 机の線の使い方、付箋のまとめ方は、
先に共有したかった
Try
– 時間足りなかった
– 時間配分間違えた
– ストップウォッチを活用する
– (チーム内で)時間を先にアナウンスする
→タイムボックスを意識する
– タイムキーパーを決める
– 時計をテーブルに置く
– タイムキープできるようにマイルストンを
設定する (ex ~分までに決める)
Try
– プロダクトの機能を固めるまえに
見積を始めてしまった
– ストーリーの内容を
すりあわせたかった
– 見積前に前提条件を共有する
– 見積前にストーリーのDoneの
定義を裏書きする
– 最初にプロダクトの共有を
詳しくやっておくべき
– PJの前提の共有をする
→どんなプロダクト?
21
- 26. ユーザーストーリーマッピング解説(4/15)
Ron Jeffries の 3C / 3Cs(1/1)
Card
– ストーリーはカードに書き、
見積もりやメモ等も一緒に書く
Conversation
– ストーリーの背後にある詳細事項は
POとの会話から引き出される
Confirmation
– 受け入れテストによってストーリーが
正しく実装されているか確認する
Copyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved. 26
- 59. Copyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved.
今日お話したこと(1/1)
第3回の復習
第3回各チーム振り返り結果ご紹介
ワークショップ #1
ワークショップ #2
ワークショップ #3
ワークショップ #4
ワークショップ #5
ワークショップ #6
ワークショップ #7
振り返り&ディスカッション
59