Scrum Boot Camp 体験記 2012/6/16
1 like735 views
2012/6/16に参加したScrum Boot Campの体験を 2012/6/20にTFSUGで共有したときの資料です。
Scrum Boot Camp 体験記 2012/6/16
- 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を継続することが大切