このページについて
Scrum Allianceの公認研修である認定スクラムマスター研修に行ってきました。
全3日制。その3日目で得た学びをまとめたものです。
※3日通しての総括編はこちら
※以下は全て個人の理解/感想であり、内容に誤りを含む可能性があります。悪しからず。
アジェンダ
- 半分はアジャイル開発宣言、スクラムガイドに基づくQ&A（グループ討論）
- もう半分はボードゲーム製作を題材にしたスクラム体験
以下、個別のメモ
プロダクトオーナーの責任
- バックログの管理の他に、「プロダクトのビジョンを示すこと」も大切
「直感」で見積もる事に真剣になる
【見積もりは難しい】
- アジャイルでは不確実性を前提としており、どこまで考えても正解には辿り着かない
- 見積もりの当てにならなさは何度も証明されてきたそうだ
- 同じ内容の資料について、文字の大きさを変えて渡すと、文字が大きい(＝紙の数が多くなる)資料の方が見積もりが高くなる
- 要求が5つ書いてある資料と、要求が6つ書いてあり1つが斜線で取り消された資料を渡すと、後者の方が見積もりが高くなる
【開発者が見積もる意義】
- 最も信頼出来る直感を持つ人たち ＝ 開発メンバ
- 開発者が自分たちで決めた（彼らに権限を委譲した）という事実も重要になる
- これによって、彼らがベストを尽くすことにコミット出来る環境が整う
【その他】
- POは見積もりには参加しないが、その場には居た方が良い
- アンカリング（他人につられる）ため、いっせーのせで見積もろう
- 開発者間の認識相違を無くすことが見積もりの最も重要な要素
- 最初はあえてSとXLだけのカードで見積もるのも手（有用でした！）
スクラムマスターの役割
- 最初はスクラムチームの導入支援
- 次第に組織を変えていくことに役割が移っていく
- 次第にスクラムマスターはスクラムチームからフェードアウトしていく
スクラムマスターの活動をどうやって評価するか？
- スクラムマスターズチェックリストで確認することが出来る
- ただし、スクラムチームの理解度（実力の何％を出せたか）を測るものであり、スクラムチームの成果（提供出来た価値の総量）とは切り離して考えるべきだ。という議論になった（受講生内で）。
スプリントレビュー
- デモでは開発者から多くを説明しないほうが良い（素直な評価を阻害する）
- プロダクトバックログアイテムが完了したかどうかは、POと開発チームが協力して判断する
- 設計書や自動テストなども含まれるため、POやステークホルダだけでは判断できない
- デモの参加者からのフィードバックをプロダクトバックログへ組み込む
- 完了しなかったアイテムもプロダクトバックログへ戻す
- ただし、優先順位が依然として最上位とは限らない
- フィードバックも含め、POはこれらの優先順位を最新化する
レトロスペクティブ
- スプリントレビューはWhat（モノ）のカイゼンを図ることに対して、スプリントレトロスペクティブはHow（スクラムチーム）のカイゼンを図るもの
- KPTも良いが、先ずはニュートラルにチームを観察し、沢山上げることを重視した方が良い
その他の雑感（スクラム体験をやっての気づき）
- 終わったのか微妙だけれど締めちゃおうのDone5つよりも、ちゃんと終わったと判断出来る1つのDoneの方が尊い
- 余裕が無いとスプリントの最後の方でバタバタして品質を誤魔化したり、デモの準備が不十分になる危険がある
- 開発者目線でバックログを並べるとログイン機能などが上の方に来がちだが、もっとコアな機能(注文機能とか)が上に来るべきである
- プロダクトがユーザの欲しいものかどうか（価値あるものかどうか）はコア機能ほど判断しやすい