名古屋アジャイル勉強会 Srcum"再"入門 http://blogs.yahoo.co.jp/nagoya_agile_study_group/36920922.html この資料はワークショップの失敗例としてみて頂けると幸いです・・・orz

1. Scrum体験
スパルタワークショップ
名古屋アジャイル勉強会 Scrum"再"入門
2 0 1 2 年 1 1 月 2 4 日 ( 土 ) Yo u & I 1

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

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

4. ATTENTION
このワークショップでのお願い事
• 職場では失敗すると大変な事になりますが、この
勉強会では失敗しても、それ程大変な事にはな
りません。どんどん失敗しましょう！
• アジャイルなやり方(の一つ)を体験して頂く
• 普段のやり方と比較して、アジャイルなやり方の
良い所、悪い所を見つけましょう。
• 体験した事を職場に持ち帰りましょう。
4

5. AGENDA
1. チーム決め＆自己紹介
2. スプリント解説
3. スプリント体験ワークショップ
4. プロダクトバックログ解説
5. プロダクトバックログ作成ワークショップ
6. ふりかえり
5

6. チーム決め＆自己紹介
１
6

7. 1. チーム決め＆自己紹介(1/3)
まずは
いきなりですが
席替えをします
7

8. 1. チーム決め＆自己紹介(2/3)
• 自己紹介
1. お名前 時間：10分
2. 今日の会場までの移動経路
3. チームで行動した時の自分の役割
• チーム名
• 各テーブルで１つ決めて下さい。
• 時間が余ったらメンバーの事を知る時間として活
用して下さい。
• 自己組織化はもうここから始まっていますよ？

9. 1. チーム決め＆自己紹介(3/3)
以降のワークショップでは、
このテーブルメンバーで
進めていきますので宜し
くお願いします。
9

10. スプリント解説
２
10

11. 2.スプリント解説(1/13)
やりたい事 成果物
スプリン
トレ
ビュー
(スプリン
デイリー トレトロ
スクラム スペク
ティブ)
スプリン
ト計画
ミーティ
ング
プロダクトバック スプリントバック リリース可能に
ログ ログ なったもの
11

12. 2.スプリント解説(2/13)
1. スプリント計画ミーティング(1/3)
• ２部構成で実施する。
• 第１部
• スプリントで「何」を完了させるか決める。
• やる事やゴールを決める。
• プロダクトオーナーと開発チームとスクラムマスターが参加する。
• 第２部
• スプリントで「どう」完了させるか決める。
• 機能の実現方法の検討、作業量・作業時間の見積。
• 開発チームとスクラムマスターが参加する。プロダクトオーナーはいつ
でも連絡が取れる状態となっていれば良く、参加しない事もある。
12

13. 2.スプリント解説(3/13)
1. スプリント計画ミーティング(2/3)
• 第１部の目的
• 状況確認
• プロダクトバックログ(優先順位付けされたやる事リスト)
• キャパシティ(開発チームの過去の作業実績の確認)
• 作るものを決める
• スプリントで実施するプロダクトバックログ項目の選択
• プロダクトオーナーと開発チームで作業内容について合意する
• スプリントゴールを設定する(※オプション)
• スプリント毎に達成されるフィーチャーなどを決める事によって、スクラム
チームの目標を明確にしたり他者へ説明しやすくする。
13

14. 2.スプリント解説(4/13)
1. スプリント計画ミーティング(3/3)
• 第２部の目的
• 選択したバックログ項目を実現する為にゴールにたどり着く方
法を計画する。
• どこまでできてるか
• どのようにやるか
• 技術的な難易度等
• 作業内容を適切な大きさにする(タスク作成)
• ユーザーストーリーをタスクに落とし込む
• タスク＝スプリントバックログ項目
• タスクの時間見積(タスク作業は理想時間による見積)
14

15. 2.スプリント解説(5/13)
2. デイリースクラム(1/2)
• 朝会(あさかい)とも呼ばれます。
• ルール
• 毎日決まった場所で立ったまま行う十数分以内のチームミー
ティング
• ３つの事について話す
1. 前回のデイリースクラムから今までに何をやったか
2. 次のデイリースクラムまでに何をするか
3. 作業の妨げや問題になっている事はなにか
• 参加者は開発チームとスクラムマスター。それ以外の人の
立ち会いは認めるものの、発言権はなし。
• スプリントバーンダウンチャートやタスクボードの前で行う。
15

16. 2.スプリント解説(6/13)
2. デイリースクラム(2/2)
• 目的
• スプリント作業を行う人達の為に行う。
• スプリントゴールに向かって自分達が何をしているのか説明で
きるようにする為
• 余計なミーティングや妨げとなるもの(問題点)を排除する為
• 迅速な意志決定を助長する為
• チーム内コミュニケーションの促進
16

17. 2.スプリント解説(7/13)
3. スプリントレビュー(1/2)
• スプリントの成果物の確認、リリースバーンダウン
チャートなどで状況確認、プロダクトバックログの改訂
• 目的
• スプリント作業をする人向け
• やった事に対するフィードバック及び更なる協力を引き出す
• 成果物を受け取る人向け
• 動作する成果物を確認できる
• 皆にとって
• 現実についての共通認識を持てる
• 現実に即した予測ができる
17

18. 2.スプリント解説(8/13)
3. スプリントレビュー(2/2)
• バックロググルーミング(実は4+1のイベント？)
• プロダクトバックログのメンテナンス作業。スプリントレビュー
のタイミングだけでなく、スプリント中の任意のタイミングで
実施する。
• スクラムチームで集まってプロダクトバックログ項目の追加・
削除・優先順位の変更を行います。
• スプリント計画ミーティングの開始時には、そのスプリントや
更にその次で実施する分のプロダクトバックログ項目の準
備が整って("Ready")いなければならない。
18

19. 2.スプリント解説(9/13)
4. スプリントレトロスペクティブ(※オプション)
• やる事
• スプリント中の人や関係、やり方、方法についてふりかえる。
KPTやプラス＆デルタなどのプラクティスを使います。
• 上手くいった事を共有する。
• 改善点を特定する。
• スクラムチーム全体の改善計画を作る。
• 目的
• スクラムチームの「検査と改善」の機会のひとつ
• 現実に合わせてこまめに軌道修正する
19

20. 2.スプリント解説(10/13)
• タイムボックスでの作業
• 開発にリズムが生まれる
• 期間内での作業量による見積が可能となる
• アジャイル開発って
• 要は小さく細切れにして反復開発する事でしょ？
• 違います。
• Jeff Patton, ThoughtWorks, Successful
Incremental Releases, P.40 - P.44
• http://www.agileproductdesign.com/download
s/patton_incremental_releases_handouts.pdf
20

21. 21

22. 22

23. 2.スプリント解説(13/13)
一通り説明聞いたら
もう出来ますよね？
実際に今の説明を体
験してみましょう！ 23

24. スプリント体験ワークショップ
３
24

25. 3.スプリント体験ワークショップ(1/11)
• 今からスプリントによる開発を体験して頂きます。
• 本ワークショップは、以下のワークショップを元にし
たものです。
• Scrum Trainers Gathering : The
Specification Exercise
• http://kanemar.com/2008/04/14/scrum-
trainers-gathering-34-the-specification-
exercise/
• お題は「サイレント伝聞お絵かき」です。
25

26. 3.スプリント体験ワークショップ(2/11)
• ルール(1/3)
• 各テーブル内で「仕様書き」と「実装者」の２つのロー
ルに分けます。
• 「実装者」の人は今のテーブルに残ったままで作業しま
す。 「実装者」の方は絶対に喋ってはいけません。
• 「仕様書き」の人は会場の後方に移動して頂きます。
会場後方で「仕様書き」の人同士の会話は行って良
いです。
• 「実装者」の人と「仕様書き」の人は会話してはいけま
せん。
26

27. 3.スプリント体験ワークショップ(3/11)
• ルール(2/3)
• 「仕様書き」の人は会場の後方で「絵」の詳細を、絵
やイラストを使わずに文字のみで仕様書として書いて
下さい。
• 「仕様書き」の人は書いた仕様書を持って「実装者」
の人の所に行き、渡して下さい。
• 「実装者」の人は渡された仕様書を元に絵を描いて
下さい。
27

28. 3.スプリント体験ワークショップ(3/11)
• ルール(3/3)
• 「仕様書き」の人は、 「実装者」の人の描いている様
子や描かれた絵をチェックして下さい。
• 「仕様書き」の人が、ゼスチャー等で「実装者」の人に
フィードバックする行為は禁止です。顔の表情や目の
動きでの表現はOKとします。
• 一度決めた「仕様書き」 「実装者」の変更は禁止とし
ます。
28

29. 3.スプリント体験ワークショップ(4/11)
• スプリント開発を体験する為に以下の流れでワー
クショップを進めます。
スプリン
ト計画
ミーティ
ング
スプリン
トレトロ ワーク
スペク ショップ
ティブ
スプリン
トレ
ビュー
29

30. 3.スプリント体験ワークショップ(5/11)
Any Questions?
この後はスプリント計画に入り
ます。不明点があるなら今こ
こで質問して下さい。
30

31. 3.スプリント体験ワークショップ(6/11)
時間：3分
各テーブルで
「仕様書き」「実装者」
を決めて下さい。 31

32. 3.スプリント体験ワークショップ(7/11)
• スプリント計画ミーティング
• 第１部
時間：5分
• スプリントで「何」を完了させるか決める。
• やる事やゴールを決める。
• プロダクトオーナーと開発チームとスクラムマスターが参加する。
• 第２部
• スプリントで「どう」完了させるか決める。
• 機能の実現方法の検討、作業量・作業時間の見積。
32

33. 3.スプリント体験ワークショップ(8/11)
• スプリント作業
時間：10分
• 「実装者」エリアでの会話やゼスチャーは禁止
• 仕様書にイラストや記号を利用するのは禁止
• 「仕様書き」の人は転ばないように注意
33

34. 3.スプリント体験ワークショップ(9/11)
• スプリントレビュー
• スプリントの成果物についてチェックします。
• 各テーブルの絵を共有します。
34

35. 3.スプリント体験ワークショップ(10/11)
• スプリントレトロスペクティブ
時間：5分
• 今のスプリントについてふりかえりを行います。
• ふりかえりなので作戦タイムではありません。
• 以下の要点に沿って意見をまとめて下さい。
• 上手くいった事を共有する。
• 改善点を特定する。
• スクラムチーム全体の改善計画を作る。
35

36. 3.スプリント体験ワークショップ(11/11)
• 最後にスプリントレトロスペクティブの内容について
テーブル間の共有を行いたいと思います。
• 各テーブルの代表者の方は、以下の３点につい
て発表をお願いします。
1. 絵の出来映え
2. 良かった事・悪かった事
3. このワークショップで得られた気づき等
36

37. プロダクトバックログ解説
４
37

38. 4.プロダクトバックログ解説(1/8)
• 各リリースの最初のスプリントが始まる前に作る
• プロダクトオーナーがビジョンを実現する為に、やる
事・やりたい事リスト
• 顧客のやりたい事をプロダクトオーナーが整理したもの
• 機能要件・非機能要件を含む
• プロダクトオーナーが項目に優先順位を付けの責任
を持つ。
• 顧客価値の高いものから優先順位付けを行う。
• スクラムチームのメンバーは誰もが項目を追加する事
ができる。
38

39. 4.プロダクトバックログ解説(2/8)
• プロダクトオーナーはいつでも改訂可能
• バックロググルーミング又は任意のタイミング
• プロダクトバックログ項目は、通常インデックスカー
ドに記述する。以下の様式を利用する事が多い。
• ユーザーストーリー
• ユースケース
• プロダクトバックログ項目は見積もられている。
• 相対見積でなるべく正確になるように見積もる
• 優先順位が低いほど見積は粗くて良い
39

40. 4.プロダクトバックログ解説(3/8)
• ユーザーストーリーは、通常インデックスカードとい
う付箋紙大のメッセージカード1枚につき１つのス
トーリーを記述して管理します。
• 記述例(UMLのユースケース記述と似ている)
• オンラインショップの利用者として、ブラウザで商品の注
文を行いたい。
• オンラインショップの利用者として、商品カートの内容を
編集したい。
40

41. 4.プロダクトバックログ解説(4/8)
ユーザーストーリー作成時の６つのポイント
• INVEST(頭文字を取って)
• Independent (独立性がある)
• Negotiable (交渉の余地がある)
• Valuable (価値がある)
• Estimable (見積り可能)
• SizedRight/Small (適切なサイズか)
• Testable (テスト可能)
41

42. 4.プロダクトバックログ解説(5/8)
• Independent (独立性がある)
• ユーザーストーリー間で順序の依存がない事。この場
合には１つの大きなストーリーにまとめるか、抽象的な
表現でまとめる。
• Negotiable (交渉の余地がある)
• 対話を省略する恐れがあるので、具体的に書きすぎ
ない。
• Valuable (価値がある)
• ユーザーにとって価値のある内容となっているか。
42

43. 4.プロダクトバックログ解説(6/8)
• Estimable (見積り可能)
• ユーザーストーリーについての知識はあるか？
• ユーザーストーリーが大きすぎないか？
• SizedRight/Small (適切なサイズか)
• ユーザーストーリーが大きすぎないか？
• ユーザーストーリーが小さすぎないか？
• Testable (テスト可能)
• ゴールは明確になっているか？
43

44. 4.プロダクトバックログ解説(7/8)
• ６つのポイントに＋１で大事な事
• 機能縦断的(End to End)となっているか？
• 平鍋健二さんのブログにあった説明が分かりやすい(と
思った)ので引用します。
• http://blogs.itmedia.co.jp/hiranabe/2012/09/agile-and-data-modeling.html
44

45. 4.プロダクトバックログ解説(8/8)
• ピュアなアジャイルでは、機能を縦スライスで作る。UIから
DBまで、細い縦の線をつなぎ、それをユーザのフィードバッ
クを得ながら太くしていく。ぼくはこれを例えるのに、ぼくは水
越さんが書いてくれたこのケーキをよく使う。
• つまり、ケーキをつくるのに、一層目のスポンジ、二層目、そ
してクリームを塗って最後にイチゴを乗せる、という作り方で
はなく、まさに、すぐに食べられるショートケーキを縦に作って
いくのだ。
• この利点は明らかで、作り終えるまでの半完成品（仕掛、
在庫）が少なく、仕様変更のインパクトが低いこと。また、
ユーザに食べさせることで、フィードバックを早期に得て、より
効果的な仕様を引き出せることだ。
45

46. プロダクトバックログ
作成ワークショップ
５
46

47. 5.プロダクトバックログ作成(1/3)
• 今回のワークショップにおいて、全テーブルで同じ
プロダクトを対象に進めるものとします。
• またお題もこちらから提示したものになります。
• 今回のワークショップにおいて、プロダクトオーナー
役は講師の私が担当します。製品に関する疑問
などはジャンジャンして下さい。
47

48. 5.プロダクトバックログ作成(2/3)
• 今回のお題は「イベント告知サイトの新規構築」
• いわゆる ATN● や k●kucheese や
D●●rKeeper とかいった奴です。
• この新規プロダクトの作成にあたり、各テーブルで
どのような実装を行うか検討して頂き、バックログ
として完成させて頂きます。
• 今回の案件の要件は次の通りです・・・
48

49. 5.プロダクトバックログ作成(3/3)
やりたい事リスト
• サイトの利用者として、イベントの参加申し込み・キャンセルがしたい。
• イベントの主催者として、イベント告知ページが作りたい。
• イベントの主催者として、イベント参加者と連絡が取りたい。リマインダを
送りたいからだ。
• イベントの主催者として、イベント告知ページの管理者を複数指定した
い。
• イベントの主催者として、イベント参加者のSNS IDやアイコン画像が取
得したい。参加証を作りたいからだ。
• イベントの主催者として、繰り返し開催するイベントの告知ページ作成
を簡単に行いたい。
• イベントの主催者として、イベント告知ページに過去に行ったものや開催
予定のイベントのリンクが自動的についかされて欲しい。
49

50. 5.1 ユーザーストーリー作成(1/5)
• 今からユーザーストーリーの作成を行って頂きます。
• 先程示した、POのやりたい事を精査して、より具
体的な内容に落とし込んで下さい。
• 要件について分からない事があれば随時質問し
て下さい。
• ユーザーストーリー作成にあたっての注意事項は、
先程も説明した次の通りです・・・
50

51. 5.1 ユーザーストーリー作成(2/5)
ユーザーストーリー作成時の６つのポイント
• INVEST(頭文字を取って)
• Independent (独立性がある)
• Negotiable (交渉の余地がある)
• Valuable (価値がある)
• Estimable (見積り可能)
• SizedRight/Small (適切なサイズか)
• Testable (テスト可能)
51

52. 5.1 ユーザーストーリー作成(3/5)
• ユーザーストーリーの記述の注意点
• 顧客視点で、顧客への価値を提供する内容を書く。
• 主語と述語をはっきり書く。誰が何をどうやってどうする
のか。
• あまり細かく書かない。プロダクトバックログの時点では
不要な情報は邪魔になる。見積に必要な情報のみ
を記述する。
• 機能縦断的にストーリーを書く。(フィーチャー単位)
• ストーリーカードの裏書きにそのストーリーのゴール・完
了条件を記述する場合もあります。
52

53. 5.1 ユーザーストーリー作成(4/5)
では早速、ユーザーストーリーの作成を行ってみま
しょう。
ユーザーストーリーの作成は、まずブレインストーミ
ングで行います。POのやりたい事リストから実装
すべきフィーチャーについて、１付箋紙に1ストー
リーで記述を行っていきましょう。
ブレインストーミングの目的は数です。先のルール
(記述方法、６つのポイント)を守りつつ沢山の
ユーザーストーリーを書いていきましょう。
時間：5分 53

54. 5.1 ユーザーストーリー作成(5/5)
• グルーピング
• ユーザーストーリーの洗い出しが出来ましたら、次は
ユーザーストーリーのカテゴリ分けを行います。
• 同じ系統のストーリーに分類しましょう。
• 同じ内容のものは付箋紙を重ねてまとめましょう。
以上で、ユーザーストーリーの洗い出しは完了です。
時間：5分 54

55. 5.2 優先順位付け
• ユーザーストーリーの洗い出しが完了したら、次は、
そのストーリー群の優先順位付けを行います。
• 各テーブルでどの作業から取り組むべきか相談し、
付箋紙を上から優先順位順に並べ替えて下さい。
• 並べ替えにおいて、優先順位が同列となるもの
は設定しないようにして下さい。必ず一意な順位
となるようにして下さい。
時間：5分 55

56. 5.3 プランニングポーカー(1/6)
• プロダクトバックログ時点において、全体の作業
量を大まかに把握する為、そしてタイムボックスで
行う作業量の判断の為にユーザーストーリーの
作業見積を行います。
• プロダクトバックログのユーザーストーリーの見積は、
• プロダクトオーナーとチームメンバーで行います。
• そのユーザーストーリーの知識のある人ない人を含め
て行います。
• 誰もが完了させられるであろう属人性を排除した
作業量での見積結果の方が望ましいです。
56

57. 5.3 プランニングポーカー(2/6)
• ユーザーストーリーの作業見積では、相対見積で
見積を行います。
• 相対見積を利用するのは、厳密な見積は必要
ないが、それでもある程度の精度を確保する為で
す。
• 一般的に、見積において10倍を超える規模の
差が出ると、見積の精度が悪くなります。
57

58. 5.3 プランニングポーカー(3/6)
• プランニングポーカーは間違ってもシャッフルしない
ようにして下さい(´・ω・`)
• 相対的な作業見積で利用するのがプランニング
ポーカーです。
• ポーカーと名前が付いていますが、揃えるのは自
分の手札ではなく、チーム全員の出した札が同
じ値になる事が目的のワークショップです。
• 手札は色分けされているので、一人一色ずつ持
ちます。
58

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

60. 5.3 プランニングポーカー(5/6)
• プランニングポーカーの進め方
1. 各ストーリーにどのようなタスクが含まれるか話し合って、
コンテキストを合わせる。
2. 中規模位(3ポイント)の基準となるストーリーを決める。
3. 次に１つストーリーを選び、それが「ストーリーポイント」
幾つになるかを各自が考えて「せーの！」でカードを出す。
4. 値が大きくズレたら、なぜそうしたかなどを両端の人に話
を聞いたり、見積の視点についてコンテキスト合わせ。
5. 全員一致するまで繰り返します。確定したストーリーポ
イントを付箋紙に記入しましょう。
• 実際にやってみましょう。
時間：15分 60

61. 5.3 プランニングポーカー(6/6)
• プランニングポーカーで見積もったポイント値が
チームの開発速度の指標として使われます。
• これがベロシティと呼ばれます。ベロシティは、チー
ムがあるタイムボックスで完成させたユーザース
トーリーのポイント数の合計値になります。
• タイムボックスは固定なので、ストーリーポイント
数の変動によりベロシティが変動します。
• ベロシティはチームのメンバーの増減によっても値
が変動する為、ベロシティでの見積はチームメン
バーの変更は行われない事が前提です。
61

62. 5.4 プロダクトバックログの共有
• 各テーブルで作成したプロダクトバックログがどのよ
うなものに仕上がったか共有しましょう。
• POである講師が各テーブルを回って色々と質問
してみたいと思います。
62

63. ふりかえり
６
63

64. ふりかえり
• 各テーブルで今回のワークショップについてふりか
えってみましょう。
• １つの感想・意見について１枚の付箋に書き出
して下さい。
• KPT的にまとめてもOKです。
64