認定スクラムマスタートレーニング
認定スクラムマスターが取得できる、6時間 * 2日の集中トレーニングです。
ただ講師の話を聞くよりも、結構な頻度でチームワークとかをやってもらうので、横文字いっぱいのスクラムの概念を、楽しく覚えられます。
講師：Joe Justice-sensei
背景
最短でスクラムマスターになれるということで、今まではなんとなく参加だけしていたスクラム開発のことを基本から学ぼうと思い、参加してみました。
学習内容の概要
今回はトレーニングの中で説明や気づきをメインに書いていこうと思います。
アジャイル開発
短い時間（スプリント）の中で、小さな単位の成果物を出し続けることを重点に置きます。
ソフトウェア開発におけるアジリティー（俊敏性）は、現代の不確実なマーケット環境に対応すべく、小さい単位から開発（Minimum Valuable Productの考え方など）し、その効果を試すことでフィードバックできるという方法を提示しています。
もちろん前提として、チームの心理的安全性、開発速度を下げないための技術的負債解消、コミュニケーションツールやCI/CDなどの仕組み、持続できるテストなどが必要となります。
また、チーム同士の待ち時間の発生を防止するため、クロス・ファンクショナルであるべきと説いています。
何よりも大事な点は、スクラムとはステークホルダー（顧客・開発者を含む、プロジェクトに関わる全員）の幸福を、スピーディーに追求するゲームということです（開始から終了時まで強調されました）
3つのロールと責任
スクラムでは大きく分けてPO(プロダクトオーナー) / SM(スクラムマスター) / Dev(開発者)の役割があり、それぞれ以下のような責任を持ちます
- PO
- プロジェクトのビジョンを作成し、ステークホルダーとチームの調律を行う
- 予算管理・優先度管理・人材管理
- プロダクトバックログの責任を持つ
- SM
- デイリースクラムの管理、コーチング
- チームのプロセス管理
- プロジェクトの進捗追跡
- ファシリテーション
- DEV
- スプリントバッグログの責任を持つ
- コミットを行う
5つのイベント
スクラムではスプリントと呼ばれる決められた期間の中で、以下のようなイベントを順に行い、なお繰り返します。
- リファインメント
- POが主導
- プロダクトバックログの見直し
- DoR（準備完了の定義） / DoD（完了の定義）の見直し
- 優先順位の見直し
- 上記はチームの合意のもとに行うこと
- プランニング
- SMが主導
- スプリントバックログにタスクを優先順位に従ってストーリーを詰めていく
- 具体的なタスクを書いていく
- ヴェロシティは、前のスプリントの完了分を参照していく
- デイリースクラム
- 毎日、15分ほどの進捗や障害の確認
- 障害や割り込みが必要な作業が見つかった場合、別途ミーティングを用意
- レビュー
- ステークホルダーと成果物の確認
- 5分以内、最大4時間で、顧客が成果物を使うのを確認します
- SpaceXの事例
- レトロスペクティブ
- 進行における振り返り
- 良かったこと、よくなかったこと、KAIZENできるものを設定
- KAIZENは、次回のスプリントにて消化する
3つの作成物(Achivements)
スクラムでは、以下の3つが作成されます。
- プロダクトバックログ
- POが管理
- ビジネスゴールのためのストーリー
- 大きめの粒度で、大まかな機能、ゴールをまとめる
- 優先度が高いものからスプリントゴールとして消化していく
- スプリントバックログ
- 開発者が管理
- プロダクトバックログを実現するための、具体的なタスクの一覧
- 開発者が責任を持ち、ゴール達成のためのタスクのブレイクダウンしていく
- （提供可能な）成果物
- テストが終わり、ステークホルダーが確認できる状態になっているもの
- 紙でもいいので、ユーザーのフィードバックを取り入れることが大事
- CD環境が整っていることが大事
- Nordstromの1週間の電撃スクラム開発
モブプログラミング
チーム全員で一つのタスクに取り掛かること
開発とレビューが同時に行われるため、レビュー待ちが発生しなくなることで、アジャイルと相性が良い
長時間でなくとも、日1時間など時間を決めて行うなど
チームのクロスファンクショナルさを育成できる
モブ導入事例
見積もり(Estimate)
見積もりの精度は、プロジェクトの大きさに反比例し、進捗度合いに比例する
見積もり通りに作業を完了しようとするプレッシャーは、時に不健康な圧力を与えたりすることから、
#NoEstimateムーブメントといった既存の見積もり方法への疑問が生じている
ストーリーポイントによるサイズ推定
最も簡単なタスクを1ポイントとし、フィボナッチ数列でポイントをつけていく
（フィボナッチ数列を採用理由は、サイズ感の比較に役立つ）
基準はタスク達成のための労力と複雑性
標準化と明確化により、より正確な作業の推定できるようにする
標準化: 個人のスキルに依存しない、作業そのものの難しさを標準化することができる
明確化: フィボナッチ数列を適用することで、作業にかかる労力度合いを明確にする
Griffen開発チームの事例
ワークアウト
このトレーニングでは、スクラム概念一つ一つに対して丁寧なトレーニングがあります。
以下では印象的だったアクティビティを紹介します
簡単にルールと、実施してみた感想、実際使ったMiloボードのキャプチャーを載せます。
モブプロでビジネスメールを作成する
ルール
- Mob Timerを使用して、チーム員でナビゲーター、ドライバー、モブの順番を決める
- タスクとして一つの題材を決めて、E-mailを作成
- タイマーを3分に設定し、ナビゲーターは文章の指示出しを、ドライバーは画面共有した状態で実際文章を作成
- モブはアイデア提供、質問、誤字チェックなど
- 交代のアラームが鳴ったら、役割を交換
- 最大15分間実施し、終了したら完成した本文を読み上げる
感想
かなり短い時間でことが進むため、役割のスイッチングを意識しつつ、まず3分でできることを決めて取り掛かるのがいいと思いました。
あとはナビゲーターとドライバー同士は多くコミュニケーションしなければならないので、伝え方などを考える必要があります。
Lean Coffee
Lean Coffeeとは
アジェンダーを用意せず、時間を決めてイテレーションする議論方法を試します。
ToDoにトピックを優先度順におき、Doingに一つ移動させ議論、結論が出なかったら継続、終わったらDoneに移動させます
ルール
- それぞれトピックを作成し、ToDoの列に置く（2分）
- それぞれのトピックを端的に紹介する（3分）
- チームで優先度決めの投票を行い、優先度順にToDoを整列する
- ToDo列の上から、Doingに移動させ、5分間議論する
- 時間が達したら、議論を続けるかどうかを投票する
- 継続に決まったら、3分でタイマーを設定し、議論を継続する
- 議論が完了すれば、カードをDoneに移動させる
- 次のToDo列からカードをDoingに移動させる
- 次のアクションが必要な場合、Actionに記載
- 最大20分間実施してみる
感想
トピック設定が難しい！5分で終わらせるためにはなるべくシンプルかつ端的にトピックを選択する必要があります。トレーニングでは、「上司や顧客にアジャイル開発をどう提案するか？」「業務の一部を外注している場合、どうスクラムを構成するか？」など、スクラムに関するトピックがサンプルとして用意されておりました。
実際使うときは、トピックをシンプルにすることと、説明を用意する必要がありそうと思いました。
スクラム開発体験
実際スクラムボードを用意し、チームでスクラム開発を試します。
- 30分 * 2スプリントで、スクラム開発をしてみる
- PO / SM / Devの役割を設定し、スプリントごとにスイッチする
- 以下のスプリントを回してみる
- リファインメント（4分）
- スプリントプランニング（4分）
- ビルド（4分）
- デイリースクラム（4分）
- ビルド（4分）
- スプリントレビュー（4分）
- レトロスペクティブ（4分）
- スプリント終了後、休憩を挟んでから役割シャッフルして2回目のスプリントを実施する
- 2回目のスプリント終了後、それぞれのチームで成果物の発表を行う
リファインメント
プロダクトバックログを作成する
ビルドタイムは8分 * 2回分なので、スケールを調整する（e.g. アイスブレイクのための双六を作ってみる、チームのランチメニューを決めるツールを作ってみる、チェックイン時のステータスを表示するカレンダーを作ってみる等）
PO：プロダクトの定義
チーム：アイデア出し
プロダクトが決まったら、プロダクトバックログを記載し、優先度付けていく
スプリントプランニング
プロダクトバックログのアイテムをスプリントゴールに置く
スプリントゴールを達成するためのタスクを、スプリントバックログに記載していく
全員が参加するが、開発チームが中心となり、技術タスクを作成
ビルド
全員で一緒に作業を行う
開発者がメインに、SM＆POは作業支援を行う
モブでやるのも可
デイリースクラム
現在の進捗を見直し、1日の作業を再計画
終わった作業をDONEに移動する
スプリントバックログの優先度を見直す
スプリント中の改善点を探す
スプリントレビュー
顧客の代わりに、POが成果物のレビューを行う
成果物を使用してみてフィードバックをあげる
レトロスペクティブ
スプリントの見直しを行う
チーム全員で、スプリント中での良かったこと、効率化できたこと、よくなかったことを分けて書く
(良かったことを上に、よくなかったことを下に集める)
SMは、上から順番にカードを声に出して読んでいく
チーム全員で、次のスプリントでカイゼンすべき付箋を一つ選ぶよう投票する
SMは投票で選ばれた付箋を次のスプリントバックログの一番上に置く
休憩を挟んだ後、次のスプリントに移る
感想
小規模でしたが、実際タスクの洗い出し、開発、レビュー、レトロスペクティブが手軽に体験できるので非常にいいと思いました。簡単なものでしたが、ルーレットを使ってチームランチを決めて、そのレビューを行うようなものを作りました。些細でも成果物ができ、そのレビューから次のフィードバックができたりするのを経験でき、改めてスクラムのゲーム的な面白さを体験できたと思いました。
成果物とボードは下の資料に載せていますので、よろしければ見てみてください。
全体感想
6時間 * 2日といった短めのトレーニングでしたが、グループワーク（30人中英語できる人がなかったため、スウェーデンの人と2人チームで久々に英語で頑張りました）が多く、集中を要しますが飽きる暇なく楽しめます！
講義・ワーク・講義・ワークと続くので、この記事をただ眺めるよりお実際体験した方が理解しやすいと思います。スクラム初心者や興味のある方はぜひ、トレーニングを試してみてください。
Next Step
スクラムアライアンスのテストを受験し、認定取得を予定です
8/24にテストを受験し、無事資格習得しました。
問題はシンプルな選択問題で、60分で50問あります。
問題文はそう難しいものではありませんが、翻訳があれで問題文がわかりづらかったりはします。
資料共有
トレーニング内容をタスクとしたスクラムボード
上のバーンアップチャート
プランニングポーカーサンプル
スクラムで作ったランチルーレット
