第50回名古屋アジャイル勉強会午後の部の発表資料 http://blogs.yahoo.co.jp/nagoya_agile_study_group/37223482.html

1. 2013/02/23(土) 第50回名古屋アジャイル勉強会
You&I
ユーザーストーリー
ワークショップ 実践編

2. ジコ、ショウカイ。
H/N： You&I(読み：ユーアンドアイ)
出身： 生まれも育ちも名古屋市
年齢： 30代中盤
本職： 商学部出身の職業プログラマ
言語： C++, C#, VB6.0, 日本語COBOL
日記： http://d.hatena.ne.jp/youandi/
所属： プログラミング生放送 名古屋支部
名古屋アジャイル勉強会
2

3. おこしもん (1/4)
3

4. おこしもん (2/4)
4

5. おこしもん (3/4)
5

6. おこしもん (4/4)
6

7. ATTENTION
本資料は後日公開致します。
資料の内容について全ての
メモを取る必要はありません。
セッション内容に集中して
頂ければ幸いです。
7

8. AGENDA
1. 踏まえる
2. 考える
3. 絞る
4. 並べる
5. 見積もる
6. 見せる
7. 回す
8. まとめる
8

9. 1. 踏まえる (1/2)
ユーザーストーリーワークショップ基礎編では、ユー
ザーストーリー作成に関する基礎的な事をやりま
した。
その基礎的な事を前提に午後の実践編では、
ユーザーストーリーを中心にして、どのようにして固
定されたタイムボックスの中で作業を行っていくの
かを体験して頂きます。
実践編でも、お題についてユーザーストーリーを
洗い出していくやり方は同じです。
9

10. 1. 踏まえる (2/2)
ワークショップに入る前に席替えを行います。
今回は、昨年に映画館で映画を観た回数で順
番に並んで下さい。
各テーブルに着席したら、午前のワークショップで
使った自己紹介の用紙を使って、１人１分程
度で自己紹介を行って下さい。
5分間
10

11. AGENDA
1. 踏まえる
2. 考える
3. 絞る
4. 並べる
5. 見積もる
6. 見せる
7. 回す
8. まとめる
11

12. 2. 考える (1/3)
何はともかく、まずはお題から。
お題「新規OSの開発」
今回はファシリテーター役をやっている私が顧客と
なります。
弊社では、最高の性能を持ったハードウェアの開
発に成功しました。
いち早く世にこのハードウェアを出す為に既存の
OSを実行させてみましたが、満足のいくものでは
ありませんでした。
12

13. 2. 考える (2/3)
そこで各グループの皆さんには、このハードウェアの
性能をくまなく活かす事ができるように新規にOS
の開発を行って頂きたいと思います。
何を作る必要があるのかは、プロダクトバックログ
を作成して管理を行います。
まずブレインストーミングで、今回のプロダクトであ
る新規OS製作について色々と案を出してみま
しょう。書式は特に指定はなく自由形式とします。
13

14. 2. 考える (3/3)
最高性能のハードウェアを活かせるOSについて、
どのような機能・実装が必要になるかブレインス
トーミングでアイデア出しをしましょう。
尚、当該ハードウェアには一般的なPC等に搭載
されている機能、HDMI、USB、無線LAN、
USBカメラ等は実装されており、またタブレット形
式の端末であり持ち運びもできるデバイスとします。
付箋紙１枚につき案を１つ書き出しましょう。
15分間
14

15. AGENDA
1. 踏まえる
2. 考える
3. 絞る
4. 並べる
5. 見積もる
6. 見せる
7. 回す
8. まとめる
15

16. 3. 絞る (1/3)
製品の売りを決める為に、製品責任者(プロダク
トオーナー)を決めましょう。
まずプロダクトオーナーとは・・・
 顧客に一番近い立場。でもチームの一員。
 従来のやり方におけるプロジェクトマネージャーとは役
割が大きく異なる。
 製品の成功に責任を持つ
 製品のビジョン・ゴール・ PBI(プロダクトバックログ項目)につ
いて開発チームと明確に共有し、開発チームが次にやるべ
き事を明確にする。
 開発チームの成果物を受け入れるかどうか判断する。
16

17. 3. 絞る (2/3)
アジャイル開発における役割(ロール)
1. 顧客
今回は私
2. 製品責任者(プロダクトオーナー) New!
今から1人選出
3. 開発者 New!
実作業を行う人たち
4. スクラムマスター(今回はなし)
何の権限は持たないが、チームに対する干渉からチームを守る
17

18. 3. 絞る (3/3)
製品責任者(プロダクトオーナー)を決めるにあた
り、まずはブレインストーミングした結果を同じ内
容・系列のものでグルーピングしましょう。
そして今回のお題であるOSに対して、明確なビ
ジョンを持った人を製品責任者(プロダクトオー
ナー)として選出しましょう。
選出に当たっては、ビジョンを決める事から始める
と良いかも知れません。
5分間
18

19. AGENDA
1. 踏まえる
2. 考える
3. 絞る
4. 並べる
5. 見積もる
6. 見せる
7. 回す
8. まとめる
19

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

23. 4. 並べる (4/5)
ユーザーストーリーが書けたら、次は作業の優先
順位を決めましょう。
優先順位の決め方は、以下の通りです。
1. 顧客価値が高い
2. 難易度が高い(技術的・作業量的)
 優先順位付けするにあたり、必ず順位は一意
になるように、上から並べ替えましょう。同列は
認めません。
10分間
23

24. 4. 並べる (5/5)
今回はやりませんが、優先度を決めるやり方とし
て狩野モデル(かのうモデル)というものもあります。
 魅力的品質と当り前品質
 http://ci.nii.ac.jp/naid/110003158895
狩野モデルでは、３つのカテゴリーに分けて優先
順位付けを行います。
1. 当たり前、または必須のフィーチャー
2. 線形、一元的なフィーチャー
3. 魅力的、わくわくするフィーチャー
24

25. AGENDA
1. 踏まえる
2. 考える
3. 絞る
4. 並べる
5. 見積もる
6. 見せる
7. 回す
8. まとめる
25

26. 5. 見積もる (1/10)
アジャイル開発において、見積を行う際の基準と
なるのがベロシティです。
ベロシティとは、チームの生産性を示す値で、固
定化されたタイムボックス(イテレーション/スプリン
ト)において、そのチームが完了させる事のできた
ユーザーストーリーの大きさの合計値です。
このユーザーストーリーの大きさの事をストーリーポ
イントと呼びます。
26

27. 5. 見積もる (2/10)
ベロシティはタイムボックス毎に変化する指標とな
ります。開発の最初の頃はタイムボックス毎の増
減が大きいですが、開発が進むにつれて安定した
値となります。この変化を見る事でチームの状況
を知る事ができます。
アジャイル開発ではチームメンバーは固定化する
事が推奨されていますので、作業内容は変わっ
たとしても、チームメンバーが同じであればベロシ
ティは同じです。逆にメンバーが替わった場合はベ
ロシティは変わってしまい、再計測が必要です。
27

28. 5. 見積もる (3/10)
アジャイル開発では、開発を始める前にスパイク
などを通してチームのベロシティを計測・見積した
上で作業を始めます。
今回のワークショップでは、サイコロを振って算出
した値をチームの基準とするベロシティ値として利
用します。
各テーブルで、1人１回ずつ20面体のサイコロを
振り、その平均値を算出して下さい。その際に端
数は切り捨てで計算して下さい。
2分間 28

29. 5. 見積もる (4/10)
ユーザーストーリーの見積は・・・、
1. プロダクトオーナーと開発チームメンバーで行います。
 プロダクトについての知識のある人・ない人を含めて行い、
属人性を排除した見積を行います。
2. ユーザーストーリーの見積は相対的な指標を用いて
行います。
 一般的に、見積において10倍を超える規模の差が出ると、
見積の精度が悪くなります。
 大小の基準を決めて三角測量にて見積を行います。
3. ストーリーポイントを決める方法としては、プランニング
ポーカーが使われる事が多いです。
29

30. 5. 見積もる (5/10)
http://softwareengineeringplatform.com/articles/planning-poker/
30

31. 5. 見積もる (6/10)
プランニングポーカーの数値は、フィボナッチ数列
(1・2・3・5・8・13・20・40・・・)になっています。
この数値がそのままストーリーポイントになります。
 ２ptに対して5ptの作業は2.5倍の規模の差がある
事を示します。
それ以外に、自分の意思表示を行う目的のカー
ドがあります。
?,∞：見積もれない・判断できない
0：作業としては発生するが別計上だったり、本当に作
業量しては些細なもの。
31

32. 5. 見積もる (7/10)
プランニングポーカーは色分けされているので、一
人一色ずつ持ちます。間違ってもシャッフルしない
ようにして下さい(´・ω・`)
ポーカーと名前が付いていますが、揃えるのは自
分の手札ではなく、チームメンバー全員の出した
札が同じになる、又は近いものになるように、ワイ
ドバンド・デルファイ法(広帯域デルファイ法)を
使ってユーザーストーリーについて意見を出したり
意識合わせしながら見積ります。
32

33. 5. 見積もる (8/10)
プランニングポーカーの前準備
 小規模と大規模の指標と対象のストーリーを使って
三角測量の要領で見積を行っていきます。
 小規模未満
 小規模以上、大規模未満
 大規模以上
 最初に基準となるストーリーを２つ決めましょう。
 小規模(3ポイント位)
 大規模(13ポイント位) ※決めずに進める事も可
 基準となったストーリーの右上にポイントを書きましょう。
33

34. 5. 見積もる (9/10)
プランニングポーカーの進め方
1. 各ストーリーについてどのような内容なのか整理して、
コンテキストを合わせます。
2. １つストーリーを選び、それが「ストーリーポイント」幾
つになるかを各自が考えて、「せーの！」で一斉に手
札からカードを1枚出す。
3. 値が一致しなかったら、最大・最小値の人にその理
由を聞いたりして、コンテキストを合わせます。３回
繰り返して一致しなかったら後回しにします。
4. 確定したストーリーポイントは付箋紙の右上にその
値を記入しましょう。
34

35. 5. 見積もる (10/10)
それでは早速プランニングポーカーで作業量を見
積もってみましょう。
作成したユーザーストーリーについて、まず基準と
なる小規模・大規模のストーリーを決めて下さい。
そして優先度の高いものから順次見積もりを進
めて下さい。
20分間
35

36. AGENDA
1. 踏まえる
2. 考える
3. 絞る
4. 並べる
5. 見積もる
6. 見せる
7. 回す
8. まとめる
36

37. 6. 見せる (1/5)
ここまでのワークショップでは、プロダクトバックログ
の作成を行ってきました。
1. 考える →アイデア出し
2. 絞る →目的決め
3. 並べる →優先順位付け
4. 見積もる →見積
 実際のアジャイル開発(Scrum)での開発の流
れは・・・
37

38. 6. 見せる (2/5)
顧客のやりたい事 プロダクト
プロダクト バックログ プロダクト インクリメント
スプリント
バックログ レビュー
グルーミング
デイリー
スクラム
スプリント計画 プロダクトオーナーの担当
ミーティング
(オプション)
開発チームの担当
スプリント レト
ロスペクティブ
スプリント バックログ 38

39. 6. 見せる (3/5)
開発作業を進める上で、プロダクトバックログやス
プリントバックログの進捗状況を見える化するのに
使われるのが、バーンダウンチャートです。
アジャイル開発の源流である、リーンソフトウェア
開発において、プロジェクトをトラッキングする際に
は、チェックする項目は減らすべきであるとされて
います。
39

40. 6. 見せる (4/5)
従来のプロジェクト管理でよく使われているWBS
(Work Breakdown Structure)のようなもの
では、以下の項目をトラッキングしていますね。
1. 作業項目
2. 作業時間
3. 担当者
対して、バーンダウンチャートでトラッキングしてい
る項目は・・・
1. スプリント毎のストーリーポイントの残数
40

41. 6. 見せる (5/5)
それでは早速プロダクトバックログから、スプリント
開始前のリリースバーンダウンチャートを作成して
みましょう。
A3用紙を横向きにして、現在のPBI(バックログ
項目)のストーリーポイント合計値を書き込んで
下さい。 ス
ト
ー
リ
ー
ポ
イ
ン
ト スプリント
5分間
41

42. AGENDA
1. 踏まえる
2. 考える
3. 絞る
4. 並べる
5. 見積もる
6. 見せる
7. 回す
8. まとめる
42

43. 7. 回す (1/13)
さて、ここまでプロダクトバックログを作成して、固
定化されたタイムボックス(イテレーション/スプリン
ト)で作業を進める為の準備をしてきました。
先程も紹介した、実際のアジャイル開発
(Scrum)での開発の流れは・・・
43

44. 7. 回す (2/13)
顧客のやりたい事 プロダクト
プロダクト バックログ プロダクト インクリメント
スプリント
バックログ レビュー
グルーミング
デイリー
スクラム
スプリント計画 プロダクトオーナーの担当
ミーティング
(オプション)
開発チームの担当
スプリント レト
ロスペクティブ
スプリント バックログ 44

45. 7. 回す (3/13)
まだほんの入り口ですね(^^;)
ここから漸く本格的な実行作業に入ります。
図に示した通り、Scrumのスプリント作業は以
下の流れを繰り返し行います。
1. スプリント計画ミーティング(第1部＋第2部)
2. デイリースクラム＋日々の作業
3. スプリントレビュー
4. スプリントレトロスペクティブ(※オプション)
ここで重要になってくるのが作業の完了判断です。
45

46. 7. 回す (4/13)
Doneの定義 (1/4)
 今回のワークショップでは明確には行っていませんが、
ユーザーストーリーには完了条件を明確にする事がと
ても重要です。INVESTではValuableやTestable
がそれに当たります。そしてSized Right/Smallも重
要な要素です。
 アジャイル開発では、その源流であるトヨタ生産方式
の特徴の１つである１個流し生産を受けて、作業は
１つずつ完了させてから次の作業へと入ります。
 これを実現する為に、作業量・作業単位の平準化と
して、ユーザーストーリーを今まで作成してきました。
46

47. 7. 回す (5/13)
Doneの定義 (2/4)
 相対見積で見積もられたユーザーストーリーは、理想
時間で見積もられたタスクに分割される。
 １タスクは1日で完了させられる作業量が目安。
サーガ 顧客のやりたい事
エピック
エピック
ユーザーストーリー
ユーザーストーリー
エピック タスク タスク
タスク タスク
製品の方向性が決まったら、次はユーザーストーリーを作成しましょう。
ユーザーストーリー
タスク タスク
ユーザーストーリー
ユーザーストーリー
タスク タスク
タスク タスク
47

48. 7. 回す (6/13)
Doneの定義 (3/4)
 ユーザーストーリーの完了条件は、PBI作成時や、ス
プリント計画ミーティング第1部などで、プロダクトオー
ナーと開発チームとで合意して決めます。
 そしてスプリントレビューにて、開発チームがスプリント
作業で作成したプロダクトインクリメントを受け入れる
かどうかをプロダクトオーナーが判断します。
 これらにより、従来の開発では「９割できました！」か
らずっとそのままだったり、作業を並行して進めすぎて
プロジェクト終盤にならないと、動作する成果物が出
来上がらない状況を回避します。
48

49. 7. 回す (7/13)
Doneの定義 (4/4)
 Doneの定義を明確にしないままスプリント作業を
行ってしまっては、緊張感もなく単なる流れ作業に
なってしまいます。
 そこで今回のワークショップはDoneの定義として、スプ
リントの開始で１回サイコロを振って頂き、それをNG
の目とします。そのスプリントのベロシティがNGの目と
同じだった場合は、そのスプリントで行ったストーリーの
１つがDone出来なかったものとします。
49

50. 7. 回す (8/13)
スプリントワークショップルール (1/2)
1. スプリント計画ミーティング第１部を行い、そのスプリ
ントで行うユーザーストーリーを、先程出したチームの
基準とするベロシティ値の範囲内で決めて下さい。
2. スプリント計画ミーティング第２部で行う、ユーザース
トーリーからタスクへの分解は今回は省くものとします。
3. デイリースクラムも今回は省きます。
4. 日々の作業の部分は簡略化し、チームの基準ベロ
シティを算出した方法と同じく、そのスプリントのベロ
シティはチームメンバーが１回ずつサイコロを振った平
均値(端数切り捨て)とします。
50

51. 7. 回す (9/13)
スプリントワークショップルール (2/2)
5. スプリントレビューでは、Doneの定義のNGの目とそ
のスプリントのベロシティの判定を行って下さい。
6. スプリントが終了したら、そのスプリントの実行結果を
バーンダウンチャートに反映して下さい。その際にはベ
ロシティ値もバーンダウンチャートに書き込んで下さい。
7. 以上で、１スプリント終了となります。引き続きPBI
が無くなるまでスプリント作業を行って下さい。
51

52. 7. 回す (10/13)
ス
ト
ー
リ
ー
ポ
イ
ン
ト
SP0 SP1 SP2 SP3 SP4 SP5 ・・・ スプリント
13pt 12pt 15pt 17pt 10pt 20pt
52

53. 7. 回す (11/13)
ストーリーポイントの扱い方
 チームの基準ベロシティ＝１５ptの場合
1. スプリントで作業予定とするユーザーストーリーのストーリー
ポイントは合計１５±３pt以内にする。大きすぎる、足り
ない場合などはユーザーストーリーの分割を行いましょう。
 スプリントのベロシティ＝２０ptの場合
2. NGの目でなければ、１で選択したストーリーは完了。
 スプリントのベロシティ＝１０ptの場合
3. NGの目でなければ、１で選択したストーリーの内、合計１０pt
分までは完了。
 スプリントのベロシティ＝NGの目の場合
4. Doneにならなかった事にするストーリーを１つ選ぶ。
53

54. 7. 回す (12/13)
ではスプリント作業を始めてみましょう。
1. スプリントで行うストーリーを決めましょう。
2. Doneの判定サイコロを１回振りましょう。
3. メンバーが１回ずつサイコロを振りその平均値を出し
てスプリントの達成ベロシティを求めましょう。
4. Doneの判定を行いましょう。
5. スプリントの最後にバーンダウンチャートも更新しま
しょう。各スプリントの達成ベロシティ値をバーンダウン
チャートに記入して下さい。
6. 以上をPBIがなくなるまで繰り返しましょう。
15分間 54

55. 7. 回す (13/13)
お疲れ様でした。PBI(プロダクトバックログ項目)
は全て消化できましたでしょうか？
各テーブルで作成したプロダクトがどんなOSになっ
たのか共有したいと思います。
以下の３点についてA3用紙にまとめて下さい。
発表時間は２分以内に収まるようにして下さい。
1. 何が売りのOSなのか
2. OSはどこまで完成させられたか(使えるか)
3. ユーザーストーリーを中心としたやり方はどうだったか
10分間 55

56. AGENDA
1. 踏まえる
2. 考える
3. 絞る
4. 並べる
5. 見積もる
6. 見せる
7. 回す
8. まとめる
56

57. 8. まとめる (1/2)
顧客のやりたい事 プロダクト
プロダクト バックログ プロダクト インクリメント
スプリント
バックログ レビュー
グルーミング
デイリー
スクラム
スプリント計画 プロダクトオーナーの担当
ミーティング
(オプション)
開発チームの担当
スプリント レト
ロスペクティブ
スプリント バックログ 57

58. 8. まとめる (2/2)
今回は、ユーザーストーリーワークショップ実践編
として、ユーザーストーリーを主体として、固定化
されたタイムボックス作業を行っていく流れを体験
して頂きました。
今回はScrumを主体とした流れでワークショップ
を行いましたが、eXtreme Programmingに
おいてもほぼ同様の流れとなります。
ユーザーストーリーの作成方法や、タスクへの分
割などは一度で覚えるのは難しいです。是非皆
さんも現場でやってみましょう。
58

59. 参考にした文献等
アジャイルな見積りと計画づくり
 ISBN:978-4839924027
アジャイルなゲーム開発
 ISBN:978-4797369731
スクラムガイド
 http://www.scrum.org/Scrum-Guides
アジャイルサムライ
 ISBN:978-4274068560
59