1. SCRUMの概要 RYUZEE.COM http://www.flickr.com/photos/18091975@N00/3654141771/
2. SCRUMとは？ ✤ 可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのもの ✤ 複雑で変化の激しい問題に対応するための仕事の進め方 ✤ 既知のことより未知のことが多い領域に向いている ✤ 役割・成果物・会議体を定めている
3. SCRUMの特徴 ✤ 軽量 ✤ 理解が容易 ✤ 習得は結構大変
4. 従来の手法と異なる点 ✤ リソースと期間によって総量規制をかける ✤ 総量をあふれる要求は実現されない ✤ もしくは必要な機能を作り終わるまで期間が延びる
5. 1番目に欲しい 大事なことから始める 2番目に欲しい 3番目に欲しい 4番目に欲しい ✤ 欲しいものをリストにして順位をつける 5番目に欲しい 6番目に欲しい 7番目に欲しい ✤ リストには項目が追加されたり、削除される ✤ この順番は定期的に見直す ... 99番目に欲しい 100番目に欲しい ✤ 優先度ではない！
6. 【成果物1】プロダクトバックログ http://www.flickr.com/photos/38793485@N00/3600409147/
7. 【ロール1】プロダクトオーナー ✤ プロダクトバックログの管理者 ✤ 優先順位の意思決定の最終決定権限をもつ ✤ プロダクトの責任者(結果責任) ✤ プロジェクトに１人必ず必要 ✤ プロダクトの価値を最大化する ✤ チームに相談できるが干渉はできない
8. 【ロール2】開発チーム ✤ モノを作る ✤ ３人∼９人で構成 ✤ 上下関係なし ✤ 全員 えばプロダクトを作れる能力が う
9. 自己組織化 ✤ 最良のやり方を自分たちで決める ✤ 一番やり方をしっているのは現場の人
10. 一定のリズムで仕事を進める 2週間 2週間 2週間 ✤ ◎同じ長さに区切って繰り返す ✤ ☒期間の長さが変わってはいけない 2週間 4週間 2週間 1週間 2週間 2週間 1週間
11. 1番目に欲しい 【会議1】スプリント計画会議 2番目に欲しい 3番目に欲しい 4番目に欲しい ✤ スプリントで開発をするためには計画が必要 5番目に欲しい 6番目に欲しい 7番目に欲しい ✤ プロダクトオーナーは何をほしいか（トピック1） ✤ 開発チームはどれくらいできそうか（トピック1） ... 99番目に欲しい 100番目に欲しい ✤ 開発チームはどうやって実現するか（トピック2）
12. 1番目に欲しい 【成果物2】スプリントバックログ 2番目に欲しい タスク タスク タスク タスク タスク タスク タスク タスク タスク タスク 4番目に欲しい タスク タスク タスク タスク タスク 5番目に欲しい タスク タスク タスク タスク タスク タスク タスク タスク タスク タスク タスク タスク タスク タスク タスク 3番目に欲しい 6番目に欲しい 7番目に欲しい ... 99番目に欲しい 100番目に欲しい ✤ プロダクトバックログを具体的なタスクに分割する ✤ 後から増えることもある ✤ １タスクは１日以内のサイズ
13. 【成果物3】出荷可能な製品の増分 ✤ 開発チームは出荷判断可能なプロダクトの増分をつくる
14. 出荷判断可能とは？ ✤ 部品だけでは出荷判断できない ✤ 小さくても使えるものを作る
15. 完了の判断 あれもこれもできて ないじゃない！ ここまでできれば終 わりだと思ったんだ けど
16. 完了の定義 ✤ 完了の定義を作り、何をもって出荷判断可能かを定める ✤ スプリントでどこまでやるか決める コード レビュー チェックイン ユニット テスト カバレッジ 75% 結合テスト 受け入れ テスト クロス ブラウザ 静的解析 ドキュメント 性能 セキュリティ デプロイ
17. 開発を進める ✤ 開発チーム全員で仕事をすすめる ✤ 特定の誰かに特定の責任が付与され るわけではない ✤ 外部からやり方は指示しない http://www.flickr.com/photos/globalgamejam2009/3241345650/
19. デイリースクラム ✤ 開発チームの状況を毎日検査する ✤ 開発チームがスプリントゴールに向かって進んでいるか検証。残作業を追跡する ✤ 毎日、同じ場所で同じ時間に開始 ✤ 15分間で延長なし ✤ たった３つの質問 ✤ 開発チームのための会議で部外者は口出しなし
20. スプリントゴールに向かって進む ✤ スプリント開始時点で決めたスコープを外圧によって変更してはいけない
21. 【会議3】スプリントレビュー ✤ 開発チームのスプリントでの成果物(完成したもの)をデモする ✤ フィードバックを得て、プロダクトバックログを見直す ✤ 全体の残作業や進 ✤ プロダクトオーナーが主催 をトラッキングする
22. 1番目に欲しい 完成しているかを事前に判断する 2番目に欲しい 頼んだ通りなのでOKです 3番目に欲しい 4番目に欲しい これクリックした時の遷移先が違うのでNGです 5番目に欲しい なるほど。今回はOKだけど次のスプリントで機能追加しようか 6番目に欲しい 7番目に欲しい ... 99番目に欲しい 100番目に欲しい ✤ プロダクトオーナーが厳密に判断する ✤ 新しいアイデアはプロダクトバックログに項目を追 加する
23. 【会議4】スプリントふりかえり ✤ 短いスプリント単位で頻繁に確認と調整を行いプロダクトをよりよくする ✤ 仕事のやり方ももっとうまくできるはずなのでカイゼンを繰り返す ✤ 人、関係、プロセス、ツールなどの観点で今回のスプリントを検査する ✤ うまくいったこと、今後の改善点を整理する ✤ 今後のアクションプランを作る
24. KPTをはじめ様々なやり方 http://www.flickr.com/photos/magnus_d/5121009259/
25. スプリント中の過ごし方 スプリント計画会議 デイリースクラム デイリースクラム デイリースクラム .......... バックログリファインメント スプリントレビュー スプリントふりかえり ✤ すべてのスプリントで同じ過ごし方をする ✤ イベントの省略は不可 ✤ スプリントに入るためには準備が完了しているプロ ダクトバックログ項目が必要
26. 【会議体5】バックログリファインメント ✤ スプリント中に次スプリントのためにプロダクトバックログの手入れ(リ ファインメント)をするイベントを行う ✤ Readyなプロダクトバックログをスプリント開始前までに準備しないとス プリントがうまく回らない ✤ ただしプロダクトオーナーは未着手のプロダクトバックログ項目はいつで も変更できるし優先順位を変えられる
27. イベントのタイムボックス イベントの種類 1ヶ月スプリント スプリント スプリント計画会議 1週間∼4週間 8時間 デイリースクラム スプリントレビュー それ以下 5% 15分以内 4時間 5% スプリントふりかえり 3時間以内 バックログリファインメント 10%以下 ✤ スクラムの基本はタイムボックス ✤ 時間は原則延長しない
28. 繰り返す 2週間 2週間 2週間 ✤ タイムボックスを繰り返して ✤ POがほしいものから順に ✤ 出荷判断可能なプロダクトを届け続ける ✤ うまく届けられるように改善し続ける 2週間 2週間
29. 【ロール3】スクラムマスター ✤ このプロセスがうまくまわるようにする ✤ 妨害の排除 ✤ 支援と奉仕 （サーバントリーダーシップ） ✤ 教育、ファシリテート、コーチ、推進役
30. ワークショップ ✤ ここまで説明したScrumのフレームワークを1枚の絵で書いてください ✤ 2人または3人一組で1枚作ってください ✤ 5分で作成し、終わったらテーブルでお互いに内容を確認してください ✤ 分からないところを明らかにする
31. プロダクトオーナー プロダクトバックログ スプリント計画会議 開発チーム スプリントバックログ デイリースクラム スクラムマスター 出荷判断可能な増分 スプリントレビュー スプリントふりかえり リファインメント http://www.flickr.com/photos/18091975@N00/3654141771/
32. SCRUMまとめ ✤ 欲しいものを作る順番に並べ替える。その順にモノを作ることで成果を最 大化する(価値を基準) ✤ 短い時間に区切って繰り返す(タイムボックス) ✤ 現在の状況や問題点を関係者の間で常に共有(透明性) ✤ 定期的に進 状況や作っているモノが正しいのか、仕事の進め方に問題が ないかどうかを確認(検査) ✤ 問題があったりもっとうまくできる方法があれば、やり方を変える(適応)
33. 学習リソース ✤ スクラムガイド ✤ http://www.scrumguides.org/docs/ scrumguide/v1/Scrum-Guide-JA.pdf ✤ 全員が共通認識をもつことは極めて重要 なので、最低限これだけはプロジェクト メンバー全員が読むこと
34. 吉羽龍太郎 / Ryuzee.com ✤ アジャイル開発/DevOps/クラウドに関する 従量課金型コンサルティングサービスを提供 ✤ http://www.ryuzee.com @ryuzee
35. 提供サービスの概要 アジャイルコーチング Agile開発については多くの誤解があり、 また経験の無いチームが自力で行うのは 難易度が高いものです。当方ではオンサイ トでAgile開発での企画∼開発まで全工程 を支援します。例えばプロジェクト立ち上 げに際しての集合研修、ふりかえりや計画 ミーティングのファシリテーションな ど。 DevOps実践支援 Cloud Architecting支援 ビジネスの成長やシステムの利用状 況に柔軟に対応できるのがクラウド の特性ですが、一方でシステムアー キテクチャがレガシーであればその メリットを享受できません。本支援 ではマイクロサービス化を始めとし て、柔軟で結合度の低いクラウドネ イティブアーキテクチャの構築を支 援します。 DevOpsには組織とツールの2つの要 技術顧問・執筆・講演 素があります。サイロ型の組織構造 技術顧問として定期的に訪問した のDevOps型組織への転換(組織デザ り、Agile・DevOps・クラウドに関 イン、採用プロセス、評価プロセ する講演をいたします。またWeb・ ス)、ツールによるデプロイ・プロビ 書籍・雑誌など各媒体向けの執筆・ 翻訳を行ないます。 ジョニング・運用・監視の自動化な ど幅広い側面で支援します。 主な提供トレーニング：「強いチームの作り方」「スクラム(半日∼2日)」「Chef入門」「カンバン入門」など
36. スクラムトレーニング (SCRUM BOOT CAMP) 本トレーニングのゴール アジャイル開発の本質的な価値を理解する アジャイル開発とウォーターフォールの違いを理解する スクラムで定義されている活動や成果物を理解する 1日コースタイムテーブル例 10:00-10:15 前説 10:15-11:00 アジャイル開発の基礎 11:00-12:00 ワークショップ 12:00-12:30 スクラム全体の流れ アジャイル開発で必要とされる自己組織化やマインドセットを理解 12:30-13:30 昼食休憩 する 13:30-14:30 スクラムのロールや会議体 14:30-15:30 プロダクトバックログ演習 対象者 15:30-16:30 スプリント計画演習 16:30-17:15 スクラムその他のトピック 17:15-18:00 ふりかえり、質疑応答 スクラムによるアジャイルな開発に興味を持っており導入の検討をされている方もし ※ご要望に応じて内容はカスタマイズいたします くは既にスクラムチームに参加されている方(管理職、マネージャ、開発者、デザイ お客様の声(一例) ナーなど)で、体系的なトレーニングの受講をされたことが無い方 アジャイル開発やスクラムの基本を学びたい方 実際に体験しながらフレームワークを学べたので非常に理解しやすかった 費用 楽しく受講できました プロダクトバックログの作り方、管理方法など具体的に学べて良かった アジャイルの本質を体感で理解させてくれる手法が良かった 費用: 1日コース50万円∼ 半日コース25万円∼。(例：参加者30人1日 => 60万円 + 税) 何となくWebなどで情報を集めていたものを体系的に把握できた 全国各地にてご提供いたします。遠方については別途交通費・宿泊費が発生する場合が あります。休日の開催も承ります その他ご調整に応じますのでお気軽にお問い合わせください。 具体的なロールプレイングができてアジャイルがわかった 他の研修でよくあるその場限りのワークショップと異なり、自分で何かに 活かそうと思えるワークショップだった
