[読書メモ]SCRUM BOOT CAMP THE BOOK
はじめに
業務でスクラムによるアジャイル開発を主導することになり、きちんと勉強するべく本を読んでます。学んだことを整理するために読書メモとしてまとめておきます。
まずは「SCRUM BOOT CAMP THE BOOK」です。
感想
漫画形式で非常にわかりやすくまとまっており、「全体像を把握したい」方には最適だと思います。
反面、初心者向けのため細かな理論・背景やプラクティスについては割愛されているところも多いです。
※例えば、スプリントごとに行う振り返り(スプリントレトロスペクティブ)については、軽く触れられている程度にとどまっています。
とはいえ、実務で使ってみようと思えるだけの情報は得られるため、
本書で概要とざっくりとした進め方を把握し、他の書籍で理解を深めながら業務で運用、という流れでも良いかなと思います。
メモ
スクラムの基礎知識
- スクラムとは
- 不確実性を乗りこなす、アジャイル開発の手法のひとつ
- 短い期間で動くソフトウェアを継続的に提供し、顧客のフィードバックを得ながらプロダクトと開発プロセスを改善していく
- 最良のやり方を自分たちで決められるチームであること(=自己組織化)
- 銀の弾丸ではない。問題を可視化しやすくするが、解決するのはチームである
- 【参考】アジャイル憲章
- 左のことに価値を認めながらも、右をより重要視する
- プロセスやツールよりも個人と対話を
- 包括的なドキュメントよりも動くソフトウェアを
- 契約交渉よりも顧客との協調を
- 計画に従うことよりも変化への対応を
- 価値とする
- 左のことに価値を認めながらも、右をより重要視する
- 3つのロール
- プロダクトオーナー(PO)
- プロダクトの成果最大化に責任を持つ。「何を作るか」を決める
- スクラムマスター(SM)
- プロダクトオーナーと開発チームをサポートし、障害を取り除く
- 開発チーム
- 「どのように作るか」を決め、その実現に向け最善を尽くす
- プロダクトオーナー(PO)
- 4つの会議体
- スプリントプランニング
- プロダクトバックログから、スプリントで何をやるか決める
- デイリースクラム
- 15分間のタイムボックスで、日々の進捗・課題を共有する
- 問題があればすぐに解決する
- スプリントレビュー
- 開発の成果を動くソフトウェアでPOやステークホルダーに見てもらう
- 受け入れる(=完了とする)かどうかはPOが判断する
- スプリントレトロスペクティブ
- スプリントを振り返り、次のスプリントに活かす
- スプリントプランニング
- 3つの成果物
- プロダクトバックログ
- POが、その内容と順序に責任を持つチームの「やること」リスト
- スプリントバックログ
- プロダクトバックログから、スプリントでやることを選び、タスクに分解したもの
- インクリメント
- スプリントの結果得られる動くソフトウェア
- プロダクトバックログ
実際のスクラムの進め方
- ロールを決める
- プロダクトオーナー、スクラムマスター、開発チーム
- プロダクトオーナーとスクラムマスターの兼任はNG
- チームを組成する
- インセプションデッキ
- リリースプランニング
- プロダクトバックログを作成する
- ユーザーストーリーの形式で書く
- <対象者>として、<機能>をしたい。それは<目的>するためだ
- 受け入れ条件
- POが、完了したと判断できる明確な基準
- デモ手順など
- ユーザーストーリーの形式で書く
- プロダクトバックログを見積もる
- ストーリーポイントによる見積もり
- 規模で見積もる
- 見積もりポーカー
- 素早く見積もるための工夫
- 正確な見積もりはできないので、見積もりに時間を掛けすぎない
- 見積もりを開発チームのメンバーそれぞれが出し合って、差異を議論する
- 数字はフィボナッチ数列を使うことで、細かな精度にこだわらずに済む
- 素早く見積もるための工夫
- ストーリーポイントによる見積もり
- プロダクトバックログを並べ替える
- 議論や相談はできるが、最終意思決定者はPO
- プロダクトバックログは定期的にメンテナンスする
- 誰でも追加して良い(やる/やらは別)
- 並び順はPOが責任を持つ
- 見積もりや受け入れ条件は常に見直す
- プロダクトバックログを作成する
- スプリントプランニング
- 2週間〜1ヶ月の短い期間で、何をどこまで作るかを計画する
- プロダクトバックログから、どこまで含めたいかを決める
- スプリントバックログを作成する
- Doneの定義を決める
- スプリントバックログを見積もる
- タスクの見積もりは理想時間で行う
- その時点での仕様が確定している必要がある
- 何を作るか？が決まっている
- 所要時間から必要に応じてプロダクトバックログを入れ替えるなどの調整を行う
- タスクではなく、ユーザーストーリーの完了にコミットする
- スプリントバックログは毎日確認し、見積もりが変わったら都度変更していく
- スプリント
- デイリースクラム
- タイムボックス運用 : 15分を越えないようにする
- 昨日やったこと/今日やること/困っていることを共有する
- バーンダウンチャートでチームの状態を管理する
- 時間軸×残タスク(H)
- 完了したストーリーの数
- 問題があればすぐに解決する
- スプリントレビュー
- ユーザーストーリーをデモする
- 受け入れ条件を満たしていれば完了とする(POが判断する)
- ベロシティ
- 1つのスプリントでいくつのストーリーポイントを完了させたか
- チームの開発速度の指標になる
- 毎回のスプリントでベロシティを計測することで、不確実性の高いプロジェクトでもリリーススケジュールの精度が高まってくる
- ベロシティは安定していくもの。意図的に高めるなどのハックはベロシティを無意味なものにしてしまうので注意
- 個人のベロシティを計測したり、評価のために使ってはならない。(参考アジャイルな見積りと計画づくり ～価値あるソフトウェアを育てる概念と技法～)
- 見積もり精度を上げたければ、多めに見積もってタスクが早く終わったら見積もりの締めまで抱えていれば良い
- チームのためではなく個人のために動く力学が働く
- あくまでチームの作業速度の可視化と、それによるチームの自主的改善、リリーススケジュールの精度向上のために使う
- デイリースクラム
- スプリントレトロスペクティブ : 振り返り
- スプリントを振り返り、進め方を改善する
終わりに
アジャイル開発やスクラムについて、概要やコンセプトは理解できていたつもりでしたが、読み進めるほどに実務レベルだと理解が甘いところが多々ありました。もっと勉強します。