SCRUM BOOT CAMP THE BOOKを読んだので、大事だなと思ったことをまとめる。
他に読んだアジャイル本(アジャイルサムライ, いちばんやさしいアジャイル開発の教本)の中では、スクラムに特化した内容。具体的なストーリーを通して学べるため、より現実を感じながら学ぶことができたと思う。
スクラムとは
スクラムはアジャイル開発の手法の一つ。そもそもアジャイル開発って何🤔って感じだが、アジャイル開発は次のような進め方をする開発のこと。
- 関係者は目的達成のためにお互いに協力し合いながら進める
- 一度にまとめてではなく少しずつ作り、早い段階から実際に動作するものを届け続けて評価を繰り返す
- 利用者の反応や関係者からのフィードバックを継続的に得ながら、作っているもの自体や計画を調整する。
アジャイル開発手法には、次の種類のものがある。
- スクラム
- エクストリーム・プログラミング（XP）
- カンバン
また、共通するのは『事前に全て正確に予測し、計画することはできない』ということを前提にしている点。
アジャイル開発では、どのくらいの期間・人数で仕事をするかを決めて、その範囲の中で大事な要求から順にプロダクトを作っていく。よって、重要なものから先に作り、そうでないものを後回しにして成果を最大化することを目指す開発。
スクラムの『５・３・３』
スクラムは最低限のルールのセットで構成されている。
5つのイベント（会議等）
| イベント名 | 説明 |
|---|---|
| スプリント | ・固定期間に区切って開発する際の単位。最長でも１ヶ月 ・スプリントは他のイベントの入れ物 ・スクラムではスプリントを繰り返すことでリズム良く開発を進める |
| スプリントプランニング | ・スプリントを進める計画のためスプリントの冒頭で行う ・スプリントで何(what)をどう(how)作るかを計画する |
| デイリースクラム | ・スプリントゴール達成のための毎日の状況確認 ・昨日やったこと、今日やること、障害となることなどを話す |
| スプリントレビュー | ・スプリントでの成果物をデモする ・フィードバックを受けて、プロダクトバックログを見直す ・今後の予定や見通しの共有 |
| スプリントレトロスペクティブ | ・直近スプリントでのカイゼン活動 ・バグが生まれるプロセスを直す ・提案されたカイゼンの１つは次回のスプリントに必ず反映する |
３つのロール（人の役割）
| ロール名 | 説明 |
|---|---|
| プロダクトオーナー | プロダクトバックログ管理の責任者 |
| 開発チーム | ・プロダクトバックログを開発する人 ・機能横断的なチームである必要がある (開発チームでプロダクトを作るための作業全てができる。) |
| スクラムマスター | ・スクラム開発のプロセスが円滑に回るように仕切る人 ・マネージャーや管理者ではなく、スクラム開発を誘導するトレーナー的な役割をする |
３つの作成物
| 作成物名 | 説明 |
|---|---|
| プロダクトバックログ | ・機能や要求、要望、修正などプロダクトに必要なものを抽出し、実現したい順に並べたもの ・常にメンテナンスして最新に保つ ・上位項目については見積もりを済ませる |
| スプリントバッグログ | ・選択したプロダクトバックログ項目と実行計画 ・プロダクトバックログを具体的な作業に分割する ・後から増えることもある ・１タスクは1日以内で終わるサイズ |
| インクリメント | ・スプリント単位で評価可能なもの （動作して検査可能なソフトウェア） ・累計のプロダクトバックログ項目を合わせたもの ・プロダクトバックログアイテムが完成の定義を満たした時に誕生する ・よって、完成の定義が決まっていないと評価できない |
全体の流れ
上記の『５・３・３』の流れのイメージをまとめる。
上のイメージのように、スクラム開発は『PDCA』を回すためのフレームワークと捉えると分かりやすい。『P：スプリントプランニング』、『D：実装＋デイリースクラム』、『C：スプリントレビュー』、『A：スプリントレトロスペクティブ』みたいな対応になると思う。
雰囲気はつかめた、で、どうする？
スクラムの進め方はなんとなくわかったので、それぞれのイベントで役立つノウハウをまとめておく。
プロダクトバックログの決定
プロダクトバックログでは次のことを決める必要がある。
- どういうことを実現するのか（ゴール）
- 絶対に達成したいことは何か（ミッション）
ゴールとミッションを明確にする
上記を決める活動の1つに、インセプションデッキと呼ばれる手法がある。インセプションデッキでは、明らかにすべき点を10個の質問でまとめられていて、それについてスクラムチームで話し合い、スライドにまとめていく。
プロダクトバックログのサンプル
詳細なフォーマットはない。機能を列挙したものや、ユーザストーリで書いたものなどがある。
機能列挙
機能 目的 詳細 見積もり 日報入力 最新情報から戦略を考える 日単位で訪問先、
担当者、案件情報を入力するログイン 機密のため利用者を制限 社員番号とパスワードで認証 ・・・ ユーザストーリ
ストーリー デモ手順 見積もり 毎日訪問先の状況を記録したい。最新情報から戦略を練りたいため XXX社の記録ページを表示して、訪問日時、商談状況、報告内容を入力して記録ボタンを押す。確認画面が・・・ 利用者を制限したい。機密情報を社員のみに開示するため 未ログイン状態でアクセスするとログイン画面を表示。〇〇の社員番号とパスワードを・・・ ・・・
作業の見積もり
プロダクトバックログの内容をまずは大雑把に下記くらいに分類する。
- 簡単に終わりそう
- 少し大変そう
- 結構大変そう
上記の振り分けをしたら、1つのプロダクトバックログの項目に対して、作業量の基準値を設定する。その基準に対して、他の項目たちが相対的にどんな感じかをそれぞれ見積もっていく。この時のやり方には、見積もりポーカーと呼ばれるものもある。
また、プロダクトバックログは、細かくしすぎない。見積もりは結局のところ推測でしかないので、プロダクトバックログを細かくして、見積もりを詳細にしたところでズレが起こる。その際、せっかく詳細に見積もりにかけた時間が無駄になるため
全体の見積もり（必要なスプリント数の見積もり）
上記で決定したプロダクトバックログと見積もりをもとに、全体でどの程度の時間が掛かるかが見通せるようになる。
理由は、それまでのスプリントで消化した見積もり数の値から、１スプリントで消化できる見積もり数（ベロシティ）を予測でき、残プロダクトバックログの見積もり数合計➗ベロシティで、残りどの程度かかるかがわかるようになるため。
スクラムを初めてやる場合には、何回か数をこなし、スプリントの平均ベロシティを出すと良い。
スプリントプランニングの実行
スプリントプランニングでは次のことを行う。
- このスプリントで何をするかを共有する
- 完成の定義を決める
- 必要な作業（タスク）を洗い出す
- スプリント内で終わるかを判断する
デイリースクラムで進捗確認
デイリースクラムでは次のことを共有する。
- スプリントゴール達成のために昨日やったこと
- スプリントゴール達成のために今日やること
- スプリントゴール達成の妨げになる障害や問題点
デイリースクラムの中では、問題を見つけることだけにとどめ、実際の対処はデイリー後に議論する。
また、スプリントゴールに対して、スプリントバーンチャートを書いてみると、進捗把握できるため、有効らしい。
スプリントレビューでフィードバックを得る
スプリントレビューでは、スプリント開始時に決めたプロダクトバックログのうち、完成したものを開発チームおよびステークホルダーに見せて、今後のフィードバックを得る。
実際に動くものを触ることで期待したものになっているかの確認を行え、要求通りであっても『実は使いにくかった』というような改善のヒントを得ることができる。
スプリントレトロスペクティブでスプリント自体を見直す
スプリントレトロスペクティブは『ふりかえり』。スプリントを通してうまくいかなかったことや改善点等をチームで話し合って、次のスプリントをよりうまく回せるようにする。
ふりかえりの手法としては、『KPT』や 『Fun Done Learn』などいろんなやり方がある。心理的安全性のあるチームを作るためにコミュケーション向上を狙ったものや、スプリント中のやりにくい作業などを思い起こして、どうすればいいかなどを考える。
PDCA でいうところの『C』にあたる部分かなと思っています。ここで決めた内容を次回のスプリントで『A』するという感じかなと。
