2012/6/16に参加したScrum Boot Campの体験を 2012/6/20にTFSUGで共有したときの資料です。

1. Scrum Boot Camp 体験記
(一般公開用)
塩井 唯史

2. はじめに
 当資料は2012/6/20にTFSUGで発表後、ネタバレ部分
を改訂したものです。
 Scrum Boot Campの資料にない部分を中心に説明して
います。
 TFSUGでの発表時間が20分でしたので、範囲を限定し
て紹介しています。実際にScrum Boot Campに参加し
ていただくことを強く推奨します。

3. About me
 氏名 : 塩井 唯史 (しおい ただし)
 出身 : 大阪府堺市
 職業 : 東京のSIベンダーでDeveloper
 TFSは実践ではCheck-in/Check-outのみ経験
 趣味 : カラオケ
 Twitter : @shioi

4. Goal
 Scrum Boot Campの体験の共有
 ワークショップでの失敗談、改善したこと
 Q & A
 その他心に染みた言葉

5. Agenda
 Scrum Boot Camp前日までの準備
 Scrum Boot Camp当日
 ウォームアップ
 プロダクトバックログ
 スプリント計画
 ふりかえり

6. Scrum Boot Campとは
 Scrum Boot Camp
 自分の現場で Scrum を始めたい or 始めているがよく分
かっていない人や体系的に学びたいが認定スクラムマス
ター研修は会社では受けられない人向けの勉強会。
Scrum の基礎を丸一日かけて丁寧に学ぶ事を目的として
います。(※スクラム道ホームページより抜粋)
 イベント開催の告知があった日に予約が満席になる大変
人気のあるイベントです。
 当資料は2012/6/16に東京で開催したScrum Boot
Campの体験記です。

7. 前日までの準備
 Scrumに関する本を読んで予習
スクラム全般を解説。
テクノロジーには依存していな
い。
TOC (制約理論) をベースに
Scrum, XP, FDDを比較。
Visual Studio, TFSを使用した
Scrumの実践。

8. バーンダウン (全期間)
 プロジェクト期間全体(約一年)でバーンダウン
チャートを作成してみた（実体験）
残タスクはいつまでも減らな
い。。。
予定を見える化して分散化できたの
で、無駄ではなかった。
期待 結果

9. バーンダウン (スプリント毎)
 期間を区切ると速度を計測できる。
スプリント1 スプリント2 スプリント3

10. Scrum Boot Camp 当日
 10:00 ～ 18:00
 約40人が参加。５人を1チームとしてプラクティス
 Agile, Scrumの講義
 演習
 ウオームアップ
 プロダクトバックログ
 スプリント計画

11. ウォームアップ
 ワークショップ
 あるルールと制約を課した単純なアクティビティ。
 決められたDoneの数を各チームで競い合う。
計画 1min.
実践 3min.
ふりかえり 2min.

12. Result Plan Result
 1回目
8 0
 成果があがらなかった。
2 8
 2回目
 見積もりを見直した。 13 12
 プロセス改善効果が表れた。 20 15
 3回目
 さらなるプロセス改善を見越して見積もりをした。
 見積もりに近い実績を実現できた。
 4回目
 プロセス改善に自身がつき、強気に見積もった。
 見積もりは甘かったが、プロセスの改善が確認できた。

13. ウォームアップふりかえり
 Time Boxを守るのは最初は難しい。
 最初はなにも計画できずにTime Up.
 繰り返すうちに各自段取りを把握でき、3回目以降はス
ムーズに進行できた。
 残時間が把握できると、集中力が保てる。
 振り返りがプロセス改善に大きく貢献
 各自が感じたボトルネック（改善点）を共有。
 良かった点も共有。定期的な対話が大事。
 対話の時間にもTime Boxを設けることで密度の高い対話
の仕方が体に染みついてくる。
 Time Boxを継続することでリズムが確立される。
Sprintを繰り返すことで見積もり精度と
生産性が向上したのを体感できた。

14. Teacher say
 講師はプロダクトオーナーとして作ってほしいもの
をチームに依頼した。
 ただし、やり方はチームに委任した。（口出ししな
かった。）
 チームが自身でプロセスを改善していった。
自己組織化

15. Time Box
 各Time Boxの目安
スプリント 2W ～ 4W
スプリント計画会議 8H
スプリントレビュー 4H
ふりかえり MAX 3H
デイリースクラム MAX 15M

16. Keep time
 朝会
 情報共有の場。問題解決の場ではない。
 問題は朝会の後で関係者だけ集めて対話をする。
 情報共有をメールで代用しない。対話が重要。
 チームの顔色はどうか？等対話しないとわからないことは多
い。
 スプリント
 最初は2Wがお勧め。
 1Wは忙しすぎる。4Wはだれる。
 ふりかえり
 15min ～ 30minで手短に
 頻繁に行うことが重要。プロセス改善が目的。

17. プロダクトバックログ演習
 各々がプロダクトオーナーになり課題に着手
 プロダクトバックログ作成
 見積もり

18. Result
 時間を守れなかった
 チームメンバー間でバックログの粒度が異なった。
 「通知する」とか「メールを通知する」とか。
 本当に重要なものがなにかで議論になった。
 通知？場所？登録機能？参照機能？
 見積もりの時点で、まだメンバーの間で各バックロ
グの内容の認識が異なることが発覚した。
 話し合って、プロダクトバックログをさらに詳細に分割
した。

19. プロダクトバックログふりかえり
 プロダクトオーナー(PO)が複数いる場合
 優先順位を決定する仕組みを構築しておく。
 例：チーフPOを決める、多数決を取る。
 最初に全ての見積もりに時間をかけても価値はない
 プロダクトバックログ項目の優先順位はビジネス環境に
合わせて頻繁に変更される。
 優先順位の低い項目を実装しない可能性がある。
 見積もりは最初は精度が低い。スプリントの積み重ねで
見積もり精度が高くなる。
 全体の見積もりはざっくりでも把握しておく
 現在のおおよその位置や速度は把握できる。

20. スプリント計画演習
 チームメンバーとしてスプリントを計画
 重要なプロダクトバックログを上位3個を選択
 各バックログをタスクに分割
 各タスクの時間を見積もり

21. Result
 時間を守れなかった
 プランニングポーカーの数字の根拠を聞くのに時間がか
かった。
 タスクに含める範囲で意見が異なった。
 設計は？
 基本設計書は？
 画面イメージをスケッチで共有？
 結合テストとか、、、
 レイヤー分割は細かすぎ？

22. スプリント計画ふりかえり
 タスクの内容が自明と思っていると痛い目にある。
対話が重要。
 プロダクトバックログを分割するときはプロダクト
オーナーに相談。

23. その他
 初めてスクラムをするときはアナログがお勧め。
 いきなりいろいろ学習するのは辛い。
 まずはスクラム、次にツールという順番。
 ちょっとしたアレンジが楽。
 バックログへイラストを描き込むとか。
 デイリースクラムで問題の把握と改善は可能。
 デジカメで各スプリントの成長を記録
 バーンダウンは順調でも帰宅時間が遅い場合あり。
 いろいろな指標を組み合わせる。
 コードチャーンとかバグの再アクティブ化とか。
 そもそもTime Boxを守らせる。

24. その他
 ベロシティを他チームと比較しても意味ない
 作業場所、メンバー、成果物等さまざまな環境が異なる
 タスクボードを使ってWIPを一人一つにする。
 仕掛品をなくす
 小規模で成功してから大規模にScrumを適用する。
 成功体験が必要
 コミットメントとはチームが最善を尽くこと。
 チームで継続的に改善を行う。
 責任はチームが持つ。個人に責任を持たせない。
 個人の責任をすると隠し事をし始める。
 評価制度の仕組みの改善が必要。

25. 全体ふりかえり
 ウォームアップでプロセス改善の工程を体験したの
で、初めての作業がうまくいかなくても落ち着くこ
とができた。
 Time Boxを設けてチームで作業をする習慣がつい
た。自己組織化を体験した。
 対話が重要。
 Time Box重要。
 ふりかえり重要。
Scrumを身に着けるには
今後もScrumを継続することが大切