Más contenido relacionado
La actualidad más candente (20)
Similar a ユーザーストーリーワークショップ実践編 (20)
ユーザーストーリーワークショップ実践編
- 2. ジコ、ショウカイ。
H/N: You&I(読み:ユーアンドアイ)
出身: 生まれも育ちも名古屋市
年齢: 30代中盤
本職: 商学部出身の職業プログラマ
言語: C++, C#, VB6.0, 日本語COBOL
日記: http://d.hatena.ne.jp/youandi/
所属: プログラミング生放送 名古屋支部
名古屋アジャイル勉強会
2
- 7. ATTENTION
本資料は後日公開致します。
資料の内容について全ての
メモを取る必要はありません。
セッション内容に集中して
頂ければ幸いです。
7
- 9. 1. 踏まえる (1/2)
ユーザーストーリーワークショップ基礎編では、ユー
ザーストーリー作成に関する基礎的な事をやりま
した。
その基礎的な事を前提に午後の実践編では、
ユーザーストーリーを中心にして、どのようにして固
定されたタイムボックスの中で作業を行っていくの
かを体験して頂きます。
実践編でも、お題についてユーザーストーリーを
洗い出していくやり方は同じです。
9
- 12. 2. 考える (1/3)
何はともかく、まずはお題から。
お題「新規OSの開発」
今回はファシリテーター役をやっている私が顧客と
なります。
弊社では、最高の性能を持ったハードウェアの開
発に成功しました。
いち早く世にこのハードウェアを出す為に既存の
OSを実行させてみましたが、満足のいくものでは
ありませんでした。
12
- 13. 2. 考える (2/3)
そこで各グループの皆さんには、このハードウェアの
性能をくまなく活かす事ができるように新規にOS
の開発を行って頂きたいと思います。
何を作る必要があるのかは、プロダクトバックログ
を作成して管理を行います。
まずブレインストーミングで、今回のプロダクトであ
る新規OS製作について色々と案を出してみま
しょう。書式は特に指定はなく自由形式とします。
13
- 14. 2. 考える (3/3)
最高性能のハードウェアを活かせるOSについて、
どのような機能・実装が必要になるかブレインス
トーミングでアイデア出しをしましょう。
尚、当該ハードウェアには一般的なPC等に搭載
されている機能、HDMI、USB、無線LAN、
USBカメラ等は実装されており、またタブレット形
式の端末であり持ち運びもできるデバイスとします。
付箋紙1枚につき案を1つ書き出しましょう。
15分間
14
- 16. 3. 絞る (1/3)
製品の売りを決める為に、製品責任者(プロダク
トオーナー)を決めましょう。
まずプロダクトオーナーとは・・・
顧客に一番近い立場。でもチームの一員。
従来のやり方におけるプロジェクトマネージャーとは役
割が大きく異なる。
製品の成功に責任を持つ
製品のビジョン・ゴール・ PBI(プロダクトバックログ項目)につ
いて開発チームと明確に共有し、開発チームが次にやるべ
き事を明確にする。
開発チームの成果物を受け入れるかどうか判断する。
16
- 18. 3. 絞る (3/3)
製品責任者(プロダクトオーナー)を決めるにあた
り、まずはブレインストーミングした結果を同じ内
容・系列のものでグルーピングしましょう。
そして今回のお題であるOSに対して、明確なビ
ジョンを持った人を製品責任者(プロダクトオー
ナー)として選出しましょう。
選出に当たっては、ビジョンを決める事から始める
と良いかも知れません。
5分間
18
- 20. 4. 並べる (1/5)
製品の方向性が決まったら、次はユーザーストー
リーを作成しましょう。ユーザーストーリーはフィー
チャーの粒度で書いていきます。
顧客のやりたい事
サーガ エピック
フィーチャー
エピック
フィーチャー
フィーチャー
フィーチャー
製品の方向性が決まったら、次はユーザーストーリーを作成しましょう。
エピック エピック
フィーチャー フィーチャー
フィーチャー フィーチャー
フィーチャー
20
- 21. 4. 並べる (2/5)
フィーチャーは、エンドツーエンド(例:画面操作
~DB登録)になっている事が望ましいです。
http://blogs.itmedia.co.jp/hiranabe/2012/09/agile-and-data-modeling.html
http://www.agileproductdesign.com/downloads/patton_incremental_releases_handouts.pdf
21
- 22. 4. 並べる (3/5)
ブレスト結果からユーザーストーリーを作成しま
しょう。INVESTを考慮するのを忘れずに。
Independent (他のストーリーとの独立性があるか)
Negotiable (交渉の余地を残し適切な粒度か)
Valuable (顧客にとって価値があるか)
Estimable (見積り可能か)
SizedRight/Small (適切なサイズか)
Testable (テスト可能か) [役割]として
[機能など]を出来る
それは[価値・理由]の為だ
10分間 22
- 24. 4. 並べる (5/5)
今回はやりませんが、優先度を決めるやり方とし
て狩野モデル(かのうモデル)というものもあります。
魅力的品質と当り前品質
http://ci.nii.ac.jp/naid/110003158895
狩野モデルでは、3つのカテゴリーに分けて優先
順位付けを行います。
1. 当たり前、または必須のフィーチャー
2. 線形、一元的なフィーチャー
3. 魅力的、わくわくするフィーチャー
24
- 27. 5. 見積もる (2/10)
ベロシティはタイムボックス毎に変化する指標とな
ります。開発の最初の頃はタイムボックス毎の増
減が大きいですが、開発が進むにつれて安定した
値となります。この変化を見る事でチームの状況
を知る事ができます。
アジャイル開発ではチームメンバーは固定化する
事が推奨されていますので、作業内容は変わっ
たとしても、チームメンバーが同じであればベロシ
ティは同じです。逆にメンバーが替わった場合はベ
ロシティは変わってしまい、再計測が必要です。
27
- 28. 5. 見積もる (3/10)
アジャイル開発では、開発を始める前にスパイク
などを通してチームのベロシティを計測・見積した
上で作業を始めます。
今回のワークショップでは、サイコロを振って算出
した値をチームの基準とするベロシティ値として利
用します。
各テーブルで、1人1回ずつ20面体のサイコロを
振り、その平均値を算出して下さい。その際に端
数は切り捨てで計算して下さい。
2分間 28
- 29. 5. 見積もる (4/10)
ユーザーストーリーの見積は・・・、
1. プロダクトオーナーと開発チームメンバーで行います。
プロダクトについての知識のある人・ない人を含めて行い、
属人性を排除した見積を行います。
2. ユーザーストーリーの見積は相対的な指標を用いて
行います。
一般的に、見積において10倍を超える規模の差が出ると、
見積の精度が悪くなります。
大小の基準を決めて三角測量にて見積を行います。
3. ストーリーポイントを決める方法としては、プランニング
ポーカーが使われる事が多いです。
29
- 31. 5. 見積もる (6/10)
プランニングポーカーの数値は、フィボナッチ数列
(1・2・3・5・8・13・20・40・・・)になっています。
この数値がそのままストーリーポイントになります。
2ptに対して5ptの作業は2.5倍の規模の差がある
事を示します。
それ以外に、自分の意思表示を行う目的のカー
ドがあります。
?,∞:見積もれない・判断できない
0:作業としては発生するが別計上だったり、本当に作
業量しては些細なもの。
31
- 32. 5. 見積もる (7/10)
プランニングポーカーは色分けされているので、一
人一色ずつ持ちます。間違ってもシャッフルしない
ようにして下さい(´・ω・`)
ポーカーと名前が付いていますが、揃えるのは自
分の手札ではなく、チームメンバー全員の出した
札が同じになる、又は近いものになるように、ワイ
ドバンド・デルファイ法(広帯域デルファイ法)を
使ってユーザーストーリーについて意見を出したり
意識合わせしながら見積ります。
32
- 33. 5. 見積もる (8/10)
プランニングポーカーの前準備
小規模と大規模の指標と対象のストーリーを使って
三角測量の要領で見積を行っていきます。
小規模未満
小規模以上、大規模未満
大規模以上
最初に基準となるストーリーを2つ決めましょう。
小規模(3ポイント位)
大規模(13ポイント位) ※決めずに進める事も可
基準となったストーリーの右上にポイントを書きましょう。
33
- 34. 5. 見積もる (9/10)
プランニングポーカーの進め方
1. 各ストーリーについてどのような内容なのか整理して、
コンテキストを合わせます。
2. 1つストーリーを選び、それが「ストーリーポイント」幾
つになるかを各自が考えて、「せーの!」で一斉に手
札からカードを1枚出す。
3. 値が一致しなかったら、最大・最小値の人にその理
由を聞いたりして、コンテキストを合わせます。3回
繰り返して一致しなかったら後回しにします。
4. 確定したストーリーポイントは付箋紙の右上にその
値を記入しましょう。
34
- 38. 6. 見せる (2/5)
顧客のやりたい事 プロダクト
プロダクト バックログ プロダクト インクリメント
スプリント
バックログ レビュー
グルーミング
デイリー
スクラム
スプリント計画 プロダクトオーナーの担当
ミーティング
(オプション)
開発チームの担当
スプリント レト
ロスペクティブ
スプリント バックログ 38
- 44. 7. 回す (2/13)
顧客のやりたい事 プロダクト
プロダクト バックログ プロダクト インクリメント
スプリント
バックログ レビュー
グルーミング
デイリー
スクラム
スプリント計画 プロダクトオーナーの担当
ミーティング
(オプション)
開発チームの担当
スプリント レト
ロスペクティブ
スプリント バックログ 44
- 46. 7. 回す (4/13)
Doneの定義 (1/4)
今回のワークショップでは明確には行っていませんが、
ユーザーストーリーには完了条件を明確にする事がと
ても重要です。INVESTではValuableやTestable
がそれに当たります。そしてSized Right/Smallも重
要な要素です。
アジャイル開発では、その源流であるトヨタ生産方式
の特徴の1つである1個流し生産を受けて、作業は
1つずつ完了させてから次の作業へと入ります。
これを実現する為に、作業量・作業単位の平準化と
して、ユーザーストーリーを今まで作成してきました。
46
- 47. 7. 回す (5/13)
Doneの定義 (2/4)
相対見積で見積もられたユーザーストーリーは、理想
時間で見積もられたタスクに分割される。
1タスクは1日で完了させられる作業量が目安。
サーガ 顧客のやりたい事
エピック
エピック
ユーザーストーリー
ユーザーストーリー
エピック タスク タスク
タスク タスク
製品の方向性が決まったら、次はユーザーストーリーを作成しましょう。
ユーザーストーリー
タスク タスク
ユーザーストーリー
ユーザーストーリー
タスク タスク
タスク タスク
47
- 48. 7. 回す (6/13)
Doneの定義 (3/4)
ユーザーストーリーの完了条件は、PBI作成時や、ス
プリント計画ミーティング第1部などで、プロダクトオー
ナーと開発チームとで合意して決めます。
そしてスプリントレビューにて、開発チームがスプリント
作業で作成したプロダクトインクリメントを受け入れる
かどうかをプロダクトオーナーが判断します。
これらにより、従来の開発では「9割できました!」か
らずっとそのままだったり、作業を並行して進めすぎて
プロジェクト終盤にならないと、動作する成果物が出
来上がらない状況を回避します。
48
- 49. 7. 回す (7/13)
Doneの定義 (4/4)
Doneの定義を明確にしないままスプリント作業を
行ってしまっては、緊張感もなく単なる流れ作業に
なってしまいます。
そこで今回のワークショップはDoneの定義として、スプ
リントの開始で1回サイコロを振って頂き、それをNG
の目とします。そのスプリントのベロシティがNGの目と
同じだった場合は、そのスプリントで行ったストーリーの
1つがDone出来なかったものとします。
49
- 50. 7. 回す (8/13)
スプリントワークショップルール (1/2)
1. スプリント計画ミーティング第1部を行い、そのスプリ
ントで行うユーザーストーリーを、先程出したチームの
基準とするベロシティ値の範囲内で決めて下さい。
2. スプリント計画ミーティング第2部で行う、ユーザース
トーリーからタスクへの分解は今回は省くものとします。
3. デイリースクラムも今回は省きます。
4. 日々の作業の部分は簡略化し、チームの基準ベロ
シティを算出した方法と同じく、そのスプリントのベロ
シティはチームメンバーが1回ずつサイコロを振った平
均値(端数切り捨て)とします。
50
- 51. 7. 回す (9/13)
スプリントワークショップルール (2/2)
5. スプリントレビューでは、Doneの定義のNGの目とそ
のスプリントのベロシティの判定を行って下さい。
6. スプリントが終了したら、そのスプリントの実行結果を
バーンダウンチャートに反映して下さい。その際にはベ
ロシティ値もバーンダウンチャートに書き込んで下さい。
7. 以上で、1スプリント終了となります。引き続きPBI
が無くなるまでスプリント作業を行って下さい。
51
- 53. 7. 回す (11/13)
ストーリーポイントの扱い方
チームの基準ベロシティ=15ptの場合
1. スプリントで作業予定とするユーザーストーリーのストーリー
ポイントは合計15±3pt以内にする。大きすぎる、足り
ない場合などはユーザーストーリーの分割を行いましょう。
スプリントのベロシティ=20ptの場合
2. NGの目でなければ、1で選択したストーリーは完了。
スプリントのベロシティ=10ptの場合
3. NGの目でなければ、1で選択したストーリーの内、合計10pt
分までは完了。
スプリントのベロシティ=NGの目の場合
4. Doneにならなかった事にするストーリーを1つ選ぶ。
53
- 54. 7. 回す (12/13)
ではスプリント作業を始めてみましょう。
1. スプリントで行うストーリーを決めましょう。
2. Doneの判定サイコロを1回振りましょう。
3. メンバーが1回ずつサイコロを振りその平均値を出し
てスプリントの達成ベロシティを求めましょう。
4. Doneの判定を行いましょう。
5. スプリントの最後にバーンダウンチャートも更新しま
しょう。各スプリントの達成ベロシティ値をバーンダウン
チャートに記入して下さい。
6. 以上をPBIがなくなるまで繰り返しましょう。
15分間 54
- 55. 7. 回す (13/13)
お疲れ様でした。PBI(プロダクトバックログ項目)
は全て消化できましたでしょうか?
各テーブルで作成したプロダクトがどんなOSになっ
たのか共有したいと思います。
以下の3点についてA3用紙にまとめて下さい。
発表時間は2分以内に収まるようにして下さい。
1. 何が売りのOSなのか
2. OSはどこまで完成させられたか(使えるか)
3. ユーザーストーリーを中心としたやり方はどうだったか
10分間 55
- 57. 8. まとめる (1/2)
顧客のやりたい事 プロダクト
プロダクト バックログ プロダクト インクリメント
スプリント
バックログ レビュー
グルーミング
デイリー
スクラム
スプリント計画 プロダクトオーナーの担当
ミーティング
(オプション)
開発チームの担当
スプリント レト
ロスペクティブ
スプリント バックログ 57
- 58. 8. まとめる (2/2)
今回は、ユーザーストーリーワークショップ実践編
として、ユーザーストーリーを主体として、固定化
されたタイムボックス作業を行っていく流れを体験
して頂きました。
今回はScrumを主体とした流れでワークショップ
を行いましたが、eXtreme Programmingに
おいてもほぼ同様の流れとなります。
ユーザーストーリーの作成方法や、タスクへの分
割などは一度で覚えるのは難しいです。是非皆
さんも現場でやってみましょう。
58