『ユーザーストーリーマッピング～前編～』第2回 POStudy 〜プロダクトオーナーシップ勉強会〜

ユーザーストーリーマッピング
～前編～
2011年09月30日（金）第2回 POStudy
@fullvirtue
1Copyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved.

POStudyのご紹介（1/3）
POStudy（プロダクトオーナーシップ勉強会）とは（1/1）
 日本のITサービス業界において「プロダクトマネジメント」と
いう分野が欠落していると言われています。そんな中で、
いかに「プロダクトオーナーシップ」を発揮していくかについて、
普段の生活や仕事を通して自己成長を重ねていく為のヒントを
提供していきます。
– 【オフライン】
» 東京・沖縄を中心にワークショップ形式の勉強会を通じて
「参加者同士で議論」を行い「情報交換」をすることで
互いに有益な場を作っていきます。
– 【オンライン】
» ワークショップを中心とした動画・静止画コンテンツを
配信していきます。

POStudyの情報を得るには（1/1）
Question Answer / URL
イベント情報のメール通知を
受け取りたいときは？
POStudy用のDoorKeeperへメンバー登録してください！
次回以降の告知やお知らせがメールで届きます。
http://postudy.doorkeeper.jp/
過去の資料を閲覧したり、
参加レポートを参照したい
ときは？
以下のPOStudy公式サイトにて過去の資料や今後の予定等
を公開しています。
https://sites.google.com/site/spostudy/
ツイートする時の
ハッシュタグは？
以下のハッシュタグをお使いください！
#postudy
POStudyの最新情報が欲しい、
or 参加者と議論をしたいとき
は？
POStudyのFacebookグループへご参加ください！
https://www.facebook.com/groups/postudy/
Twitterによるお知らせを
購読したいときは？
POStudyのTwitterアカウントをフォローしてください！
https://twitter.com/POStudySmile/

過去に実施してきたテーマ（1/1）
実施日テーマ参加者
第1回 2011/09/16（金）アジャイルとスクラム 9名
第2回 2011/09/30（金）ユーザーストーリーマッピング ~前編~ -
第3回 2011/10/14（金）ユーザーストーリーマッピング ~後編~ -

Copyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved.
今日のアジェンダ（1/1）
第1回目の復習
プロダクトバックログ解説
ユーザーストーリーマッピング解説
ワークショップ#1
振り返り＆ディスカッション
まとめ
5

おことわり（1/1）
今回の資料について（1/1）
 今回の資料は、以下の資料を参考にしています。
私自身のオリジナルはほとんどありませんので、
ご了承ください。
 前半のプロダクトバックログの説明部分と
後半のワークショップは、
@kawaguti さんがScrum Boot Campで
使用した資料を参考にさせて頂いています。
 前半のユーザーストーリーの説明部分については、
@ryuzee さんの公開資料
http://www.slideshare.net/Ryuzee/ss-8332120
を参考にさせて頂いています。
Copyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved. 6

第1回目の復習
いきなり本題に入る前に、前回の復習をしましょう

第1回目の復習（1/9）
アジャイルソフトウェア開発とは
 「アジャイルソフトウェア開発宣言」の
「4つの価値」と「12の原則」に基づいた開発
– 出典：Agile Manifesto
» http://agilemanifesto.org/

アジャイルソフトウェア開発宣言–4つの価値（1/1）
 私たちは、ソフトウェア開発の実践あるいは実践を手助けを
する活動を通じて、よりよい開発方法を見つけだそうとしている。
この活動を通して私たちは以下の価値に至った。
– プロセスやツールよりも個人と対話を、
– 包括的なドキュメントよりも動くソフトウェアを、
– 契約交渉よりも顧客との協調を、
– 計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。

アジャイルソフトウェア開発宣言–12の原則（1/3）
アジャイル宣言の背後にある原則
私たちは以下の原則に従う
1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に
提供します。
2. 要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。
3. 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ
短い時間間隔でリリースします。
4. ビジネス側の人と開発者は、プロジェクトを通して日々一緒に
働かなければなりません。

5. 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援
を与え仕事が無事終わるまで彼らを信頼します。
6. 情報を伝えるもっとも効率的で効果的な方法は
フェイス・トゥ・フェイスで話をすることです。
7. 動くソフトウェアこそが進捗の最も重要な尺度です。
8. アジャイル･プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。

9. 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
10. シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
11. 最良のアーキテクチャ・要求・設計は、自己組織的なチームから
生み出されます。
12. チームがもっと効率を高めることができるかを定期的に振り返り、
それに基づいて自分たちのやり方を最適に調整します。

アジャイルの現在（1/1）
 出典：平鍋健児氏 http://www.publickey1.jp/blog/10/post_121.html

スクラムにおける役割（1/1）
14
•プロダクトの機能と特徴を定義し、リリースの内容と日付を決める
•プロダクト収益性または投資収益率の責任者
•機能の市場価値をもとに機能の順付けをする
•スプリントごとに仕様や優先順位を変える権利がある
•作業結果を許可または却下する
プロダクトオーナー
•チームの機能と効率を支援または保証する
•作業者の協力を支援し、それを妨害するものに対処する
•チームを外部妨害から守る
•プロセス通りの作業を保証し、デイリースクラム、スプリント末の
レビューとプラニングを設定する
スクラムマスター
•多数目的に対応
•３人から９人まで
•スプリントゴールを選択し、目標となる結果を定義する
•プロジェクト規則内であれば目標達成するには何してもよい
•作業とチーム自身の整理と制御をする
•作業を結果をプロダクトオーナーの為にでもする
チーム

スクラムの進め方（1/2）
• 出典：MOUNTAIN GOAT SOFTWARE
http://www.mountaingoatsoftware.com/scrum/figures
15
PO SM
プロダクトオーナースクラムフィーチャーチーム
マスター＋スクラム

スクラムの進め方（2/2）
• 出典：MOUNTAIN GOAT SOFTWARE + Powerd by @nawoto
@yattom http://www.mountaingoatsoftware.com/scrum/figures
16
PO SM
プロダクトオーナースクラムフィーチャーチーム
マスター＋スクラム

前回やったプロダクトバックログについて、
もう少し踏み込んで説明していきます
【参考：@kawaguti Scrum Boot Camp資料】

プロダクトバックログ解説（1/16）
プロダクトバックログ（1/2）
# 概要デモ方法優先 SP
21 管理者画面を利用出来る
トップ画面から「管理者」ボタンで
画面に遷移
700 3
25
管理者として
ログインできるようになる
管理者権限を持つIDだけに「管理者」ボタ
ンを表示するところを見せる
640 5
27
セッションは15分間維持
されるが、その後は破棄
操作終了後15分待ってから操作を行う
（その間は、他のデモを見せる）
500 2
24
管理画面は50件ごとに
ページを分けて表示
管理画面を表示する。
次ページを選択して
最終ページまで見せる
490 2
29
タイトルを文字列検索で
探すことが出来る
トップ画面の検索窓に入力し、
検索結果画面へ。
～項目をクリックして
470 3

プロダクトバックログ（2/2）
# 概要デモ方法優先 SP
21 管理者画面を利用出来る
トップ画面から「管理者」ボタンで
画面に遷移
700 3
25
管理者として
ログインできるようになる
管理者権限を持つIDだけに「管理者」ボタ
ンを表示するところを見せる
640 5
27
セッションは15分間維持
されるが、その後は破棄
操作終了後15分待ってから操作を行う
（その間は、他のデモを見せる）
500 2
24
管理画面は50件ごとに
ページを分けて表示
管理画面を表示する。
次ページを選択して
最終ページまで見せる
490 2
29
タイトルを文字列検索で
探すことが出来る
トップ画面の検索窓に入力し、
検索結果画面へ。
～項目をクリックして
470 3

スプリント計画（1/10）
 スプリント計画第1部では、チームの到達範囲を予測
2
1
3
5
1

プロダクトバックログ
＝優先順位順に積まれた
提供項目のリスト
2
1
3
5
1

2
1
3
5
1

ベロシティ＝６
2
1
3
5
1

2
1
3
5
1
2
1
3
当スプリント
で着手

2
1
3
5
1

ベロシティ＝８
2
1
3
5
1

ベロシティ＝８
2
1
3
5
1
6

2
1
3
5
1
6
2
1
3
1
5
7

2
1
3
5
1
6
2
1
3
1
5
7
2
1
3
2
3
1
8

タスクボード（1/2）

タスクボード（2/2）
#172
リリース作業
3/22 18:00
#195
障害調査
IE6で表示が
崩れる
#193
件名からの
絞り込み表示
ができる 1
2
3

バーンダウンチャート（1/2）

バーンダウンチャート（2/2）

ユーザーストーリーについて説明していきます
【参考：@ryuzee ユーザーストーリーとは？】
http://www.slideshare.net/Ryuzee/ss-8332120

ユーザーストーリーマッピング解説（1/15）
ユーザーストーリーとは（1/2）
 要求仕様を自然言語で簡潔に記述したもの
 [役割]として
 [結果]が欲しい
 それは [理由]のためだ
 [役割]として
 [機能や性能]が欲しい
 それは [ビジネス価値]のためだ

ユーザーストーリーとは（2/2）
 顧客との会話に役立つ
 計画づくりに役立つ
 無駄な詳細化から解放される

なぜユーザーストーリーが必要なのか（1/1）
 要件（機能）のスケジュールが可能なユニット
– スケジュールは他に依存していない
 ユーザーがどう使うかという目線に立って表現
– 他に依存せずにスケジュール可能な特徴を実現

Ron Jeffries の 3C / 3Cs（1/1）
 Card
– ストーリーはカードに書き、
見積もりやメモ等も一緒に書く
 Conversation
– ストーリーの背後にある詳細事項は
POとの会話から引き出される
 Confirmation
– 受け入れテストによってストーリーが
正しく実装されているか確認する

どちらの作り方を選びますか？（1/1）

分割の方向（1/1）
 技術的レイヤー単位で分割しない
– このやり方だと、全てが揃わないと
リリースできないリスクがある。
 動作する機能単位で分割する
– エンドツーエンドで動作する単位で分割する。
– リリース可能な単位が小さくなる
– 早くリリースできることは
ビジネス価値につながる

ユーザーストーリーのINVEST（1/7）
 INVESTとは
 Independent 独立
 Negotiable 交渉可能
 Valuable 価値
 Estimable 見積可能
 Sized right (Small ) 適切な大きさ
 Testable テスト可能

 Independent
 互いに独立していること
 依存関係や前後関係はなるべく排除
 依存関係が高いと見積が難しくなる

 Negotiable
 交渉可能
 会話のための道具
 一度決めたことが絶対なわけではない

 Valuable
 価値がある
– ステークホルダーにとって
– ビジネスにとって
– チームにとって

 Estimable
 見積可能
 見積できるくらいのストーリー粒度

 Sized Right
 適切な大きさ
 十分にストーリーが分割されている

 Testable
 テスト可能
 受入テストを記述できる

ユーザーストーリー作成時の大切なこと（1/1）
 システムの利用者に焦点をあてる
 ストーリーの記述では、
ユーザーロールを意識する

PBI優先順位決定の原則（1/1）
 高い価値のものから
 市場投入への時間を短く
 リスクを最小化
 将来の無駄を避ける
– PBI：Product Backlog Item

別途配布したワークショップの題材を確認した後、
ユーザーストーリーをストーリーカードに書き出してください
（個人ワークショップ）

個人で作成したストーリーカードを
チームで共有し、まとめてください
（チームワークショップ）

チームでまとめたストーリーカードを元に
最低限のリリース目標を設定してください
（チームワークショップ）

※今回時間切れだったので、次回続きをやります

今日気づいたことをテーブルごとに共有してください
各チームでの気づきを配布した用紙に記載してください
後ほど全チームの気づきをまとめたものをご連絡します

まとめ
今日お話したことを振り返ってみましょう

今日お話したこと（1/1）
第1回目の復習
まとめ
56

ご静聴ありがとうございました。

『ユーザーストーリーマッピング～前編～』第2回 POStudy 〜プロダクトオーナーシップ勉強会〜

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie 『ユーザーストーリーマッピング～前編～』第2回 POStudy 〜プロダクトオーナーシップ勉強会〜

Ähnlich wie 『ユーザーストーリーマッピング～前編～』第2回 POStudy 〜プロダクトオーナーシップ勉強会〜 (20)

Mehr von 満徳関

Mehr von 満徳関 (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (9)