【資格】 認定スクラムマスター
先日、2日間の認定スクラムマスター研修を受講し、認定を頂きました。
スクラムの基礎学習、役割の定義、ワークショップでのスクラム体験等、非常に良い学びとなりましたので、メモを整理して共有します。
◆ スクラム
■ アジャイル開発の手法の一つ
- アジャイル開発 = スクラムではない
- 他の手法よりもチームのコミュニケーションを重視した手法
■ 複雑なプロダクトを開発・提供・保守する為のフレームワーク
- プロジェクト開発の為のフレームワークではない
- スクラムの役割の中にプロジェクトマネージャは存在しない
■ 変化する状況に対応する為に設計されている
- 要件定義を後回しにできる手法ではない
- 最終的なビジョンがなければ結局は上手くいかない
■ あらゆるプロダクトに利用できる
- ソフトウェアだけの手法ではない
- ハードウェアから組織運営にも使われている
■ 経験を基に学び適応し、予測可能性とリスク管理のバランスを目指す
- 同じことを繰り返しているだけじゃ足りない
- 不安定を恐れずチャレンジする事が必要になる
■ 小さな単位の成果を頻繁に届けられる
- より速く価値が届けられる事に注力すべき
- 終わらないタスクを細かく報告してるだけではいけない
■ プロダクトバックログにある課題を開発チームでスプリントに落とし込む
- プロダクトオーナーやスクラムマスターが決めてはいけない
■ スクラムはスプリントと呼ぶ短いタイムボックスで仕事を組み立てる
- 計画は毎回アップデートされ、検査まで終わらせないといけない
- 最初に立てた計画に基づきソースをコミットするだけではいけない
- スクラムにおいて計画はし続けるものであって、スプリント0は存在しない
- 環境構築はスプリントが始まる前に準備する
◆ スクラムの３つの役割
■ プロダクトオーナー
- プロダクトの価値を最大化する責任を持つ
- プロダクトのビジョンを開発チームに共有する
- プロダクトバックログの作成・管理・説明に責任がある
- スプリントプランニング時にトレードオフの判断をする
- プロダクトインクリメントのリリース時期の判断をする
- 緊急事態の場合はスプリントを中止できる権限を持つ
- 開発チームに指示をする権限は無い
- プロダクトオーナーが仕事をしないと他が全部進まない
■ スクラムマスター
- 定義に従いスクラムを促進・支援する責任を持つ
- フレームワークの中でチームと組織をコーチする
- 理論・ルール・価値基準を共有し徹底させる
- プロダクトオーナーが自身の役割に集中できるよう支援する
- 開発チームをコーチして見守り、妨害事項を除去する
- マネージャがスクラムにやってきて干渉しはじめたら裏に連れて行ってスクラムを説くべし
- スプリントの遅れやチームの疲弊については、原因をチーム自身が気付くまで質問する
- 必要に応じてスクラムイベントをファシリテートする
- プロダクトオーナーとスクラムマスターは兼任してはいけない
- 開発チームに指示をする権限は無い
■ 開発チーム
- スプリントの終了時に完成したインクリメントを届ける事に責任を持つ
- プロダクトバックログ項目の見積もりに責任がある
- スプリントで実行する項目を選択し確約する責任を持つ
- 項目の見積もり手法の一つにプランニングポーカーがある
- スプリントバックログの作成・管理・説明に責任がある
- デイリースクラムの開催に責任がある
- 自己管理・自己組織化し、自律的に価値や目標に向けて作業する
- チームメンバー同士支援・協力し合い、全員で責任を果たす
- メンバー構成は長期的に安定させ関係を最適化すべき
- チーム内でプロダクトを完成・提供できる機能横断的なスキルが必要
- 様々な専門知識を持つメンバーが一体となって仕事を行う事をスウォーミングと言う
- なるべく同じ場所で作業をするのが望まれる
- ３〜９人が推奨される
◆ スクラムの３つの成果物
■ プロダクトバックログ
- プロダクトに必要だと思われる機能・要求・要望・修正すべての一覧
- 項目の管理はプロダクトオーナーの責任
- 項目毎に設計・実装・検査し、完成できるものでなければならない
- 上位は１スプリントで完成でき、高い価値を届けるものにする
- 上位はテスト基準・受け入れ条件を明確にすべき
- スプリント中いつでも項目の追加・変更・破棄が可能
- 何をいつ誰が、に着目して作成する
- 価値・リスク・コストを基に継続的に更新する
- メンテコストが高くなるので大きいプロダクトでも 100 項目以内にすべき
- 慣れると 3-4 ヶ月先は読めるようになるのでそれより先の要件は書かなくて良くなる
- 使うユーザーが居ない機能は消す。コードから消せばメンテも要らない
■ スプリントバックログ
- スプリントで実施するプロダクトバックログ項目の一覧
- プロダクトバックログ項目をさらに細分化する事もある
- 項目の管理は開発チームの責任
- 一度決定したらスプリントの途中で変更できない
- 達成に対して最善を尽くす責任は開発チームにある
- 完成できなかった項目はプロダクトオーナーが再見積してプロダクトバックログに戻すか破棄する
- スプリント中は項目の変更はしない
- 新しい課題はプロダクトバックログに追加する
■ インクリメント
- スプリント毎に完成したプロダクトバックログ項目
- 検査まで完了し、完成したものでなければいけない
- 開発チームは完成したものについて説明できなければいけない
- 顧客へのリリースとは別で、ステークホルダーがレビューできるもの
- インクリメント数を積み上げてリリースバーンアップチャートを作る事でリリース時期を予測できる
◆ スクラムの６つのイベント
■ スプリントプランニング
- プロダクトバックログをインプットし、スプリントバックログをアウトプットする
- 最長８時間で実施する。スプリントの長さに応じて短くする
- ステークホルダーも含めて全員参加する
- 参加者全員がここでスプリントのゴールと目的を理解し同意する
- 最適なスプリントに分割する手法としてウォーキングスケルトンがある
■ スプリント
- スプリントバックログをインプットし、インクリメントをアウトプットする
- 最大１ヶ月で実施する。２週間が一般的
- 一つのタイムボックスの中に計画・設計・実装・検査が含まれる
- 開発進行度で伸ばしたり縮めたりしてはいけない
- スプリントを中止できるのはプロダクトオーナーのみ
- 残作業予想の手法としてスプリントバーンダウンがある
- タスクの完了度をキャパシティ（ベロシティ）と言う
■ デイリースクラム
- ゴールに向けた進捗についてのフィードバックを共有する
- 透明性のある共有によりお互いを援助し合い計画の微調整を実施する
- 最大１５分で実施する
■ スプリントレビュー
- インクリメントへの評価をインプットし、更新されたプロダクトバックログをアウトプットする
- スクラムチームとステークホルダー全員がインクリメントに対してフィードバックする
- 現スプリントを評価し次のスプリントの価値を最大化するためにプロダクトバックログを更新する
- 開発チームはインクリメントについて説明し、問題点などを議論する
- 最大４時間で実施する。スプリントの長さに応じて短くする
- 準備に３０分以上使わない
■ スプリントレトロスペクティブ
- チーム自体を検査し改善計画をたてる
- 最大３時間で実施する
■ プロダクトバックログリファインメント
- プロダクトオーナーはプロダクトバックログを常に最新に保ちプロダクト価値向上の計画を立てる
- 次のスプリントで実施するのに必要な情報を詳細に準備する
- 開発チームはプロダクトバックログの上位の項目について質問や見積もりを実施する
- 次のスプリントで行われるであろう項目について３日程度に分割する
- 開発チームのキャパシティの１０％以内で実施する
◆ まとめ
今まで本格的なアジャイル開発はしておらず、他チームの案件を参考にしていただけでしたが、今回学んだ事をチームの動き方や提案で活かしていこうと思います。
最後に普段プロジェクトのマネージメント業務をしていると勘違いしそうな事をまとめます。
- プロジェクト開発の為のフレームワークではない
- スクラムの役割の中にプロジェクトマネージャは存在しない
- スクラムマスターは支援し見守るだけで指示や手助けをしてはいけない
- プロジェクトマネージャーはプロジェクトの完了がゴールだが、スクラムマスターはチームの成熟がゴール
- 要件定義を後回しにするための手法ではない
- スプリント毎にクライアントに見せれる単位での成果物が必要
- 差し込みがあった場合でも開発チームの作業を妨害させない
- 準備期間であるスプリント0は存在しない