読書メモ：SCRUM BOOT CAMP THE BOOK
下記の本を読んだので備忘を記録する。
所感
- インセプションデッキは、システム要件(開発の概要)をまとめたスライドで外注するとしたらベンダーに最初に提案依頼の説明をするときの資料に近いように感じた
- プロダクトバックログは、機能要件をテキストで記載した機能一覧のようなものと思った
- ウォーターフォールでは全てのプロダクトバックログ項目をまとめて進めていくのに対して、アジャイル(スクラム)では機能別に毎回のスプリントで最後の受け入れテスト(スクラムの言葉で言えばデモ手順)まで進めていくのが違いかと思った。進め方だけが異なり、リリースまでに必要なことはどちらでも行う認識。
- この本は漫画&スクラム入門書と思われるため、実際の現場の泥臭い部分やうまくいかない部分で省略されている箇所もあるんだろうと思った。例えば下記の描写は実際にはスムーズにいかないところもあるのでは？と思った(引っかかった箇所を矢印で記載)
以下備忘
--------------
基礎編
- アジャイル開発とは何か単一の開発手法を指すものではなく似たような開発手法に共通した価値観と行動原則に名前がついたものであり体現する手法は複数ある
- スクラム
- エクストリームプログラミング
- カンバン
- スクラムの定義
- スクラムは5つのイベント（会議など）、3つのロール（人の役割）、3つの作成物など最低限のルールのセットで構成される
- スクラムの具体的な特徴
-
【成果物1】スクラムでは、機能や要求、要望、修正などプロダクトに必要なものを抽出し、順番に並べ替えたプロダクトバックログと呼ばれるリストを作成する(バックログはプロダクトに1つ)
- 順番は、その項目が実現されたときに得られる価値やリスク、必要性などによって決定する(優先度ではない？)
-
【成果物2】スプリントプランニングで決めることの2つ目として(1つ目はプロダクトバックログ項目の選択)、選択したプロダクトバックログ項目と作業の一覧を合わせて、スプリントバックログと呼ぶ。スプリントバックログは開発チームの作業計画であり、スプリント期間中も自由に作業を追加したり削除したりすることができる。また、個々の作業は1日以内で終わるように分割するのが一般的。
-
【成果物3】インクリメントとは、過去のスプリントでの成果と今回のスプリントで完成したプロダクトバックログ項目を合わせたもの。多くの場合、動作しているソフトウェアとして提供され、スプリント終了時点で完成していて正常に動作する必要がある。
-
【ロール1】プロダクトバックログの管理の責任者をプロダクトオーナー（PO）と呼ぶ。POはプロダクトのWhatを担当する。
-
【ロール2】開発チームはプロダクトのHowを担当する
-
【ロール3】スクラムマスターは、スクラムのルール、作成物、進め方をPOと開発チームに教育すると同時に妨害や割り込みから守るのが役割
-
【イベント1】スクラムでは最長1か月までの固定の期間に区切って、繰り返し開発を行うがこの固定の期間のことをスプリントと呼ぶ。
各期間の長さは変えてはならない。最終日に作業が残っても期間の延長はしない。
-
【イベント2】スプリントプランニングでは、各スプリントのWhatとHowを決定する
-
【イベント3】デイリースクラムは、開発チームのための会議。スプリントバックログの残作業を確認し、このまま進めてスプリントゴールが達成できるのかどうかを、毎日15分のタイムボックスで検査する
※ デイリースクラムは、問題解決の場ではないことに注意(問題があれば別途タイムボックスを設ける)
-
【イベント4】スプリントの最後では、プロダクトオーナー主催でスプリントの成果をレビューするイベントを開催する(スプリントレビュー)。スプリントレビューはステークホルダーからプロダクトに対するフィードバックを得るのが目的。
-
【イベント5】スプリントレトロスペクティブは振り返りのことでスプリントレビューのあとにスプリント内の最後のイベントとして行う
-
実践編
Scene No.01 ロールを現場にあてはめる
- ロールの兼務はOKだが、POとスクラムマスターの兼務はNG(役割が相反しており利害関係の衝突が起きるため)
Scene No.02 どこを目指すのか理解する
-
インセプションデッキという下記を含む10の質問で開発を始める前に明らかにしておくべきことを知ることができる
- どういうことを実現するのか（ゴール）→エレベーターピッチ
- 絶対に達成したいことは何か（ミッション）→我々はなぜここにいるのか
-
インセプションデッキを作るには、下記テンプレートをもとに叩き台を作り、疑問点や気になる点がないかをスクラムチームで話し合い、相談しながら具体的にしていく
テンプレート：
-
ちゃんとスライドを作っても開発チームに一方的に説明するだけではNGで不安を持たなくなるくらい自分たちが向かう先を理解するのが重要(なのでみんなで集まって話し合う)
Scene No.03 プロダクトバックログをつくる
- 最初のプロダクトバックログの作り方は、インセプションデッキや既存のシステム機能一覧を持ち寄り、含めた方が良い項目を付箋などに書き出していき、4段階くらい(超重要〜あれば嬉しい)に分類していく
- プロダクトバックログの並び順は、自分たちが大丈夫そうと思えるようなものにするために自分たち(スクラムチーム)で決める
- プロダクトバックログの項目は、目玉となる機能以外でも、目立たないが必要不可欠な機能、アーキテクチャの妥当性を検証できる機能やまだ不安のある技術要素を試すことができる機能といった、開発をする上で優先したい機能という分類を設けるのも重要
Scene No.04 見積りをしていく
- 各プロダクトバックログ項目を見積もれば最初のリリース時期や予算が分かるが、そのために相対見積もりという方法がよく使われる
- 相対見積もりは見積もり対象が不確実であるという前提があり、1,2,3,5,8,13,…とフィボナッチ数列を割り振っていくことが多い
- まず各項目を簡単に終わりそう、少し大変そう、結構大変そうの3分類に分け、少し大変そうに分類した項目を全て並べ、その真ん中あたりから具体的に作業がイメージできる項目を選び3として基準とする。その他項目はフィボナッチ数列から割り振っていく。
- 相対見積りでは素早く見積もるのが重要(素早く見積もることで先の見通しを確実にするための時間にあてられるため)
- 見積もりポーカーをやる目的は、作業を行う自分たち(開発チーム)で見積もりについて対話することで認識のズレを初期段階で明らかにしながら、素早くある程度の抜け漏れを防ぐため
Scene No.06 いつ何が手に入るのか？
- スプリントごとに終わらせられるポイント数を、ベロシティと呼ぶ。スクラムチームのスピードのこと。
- 絶対に必要な項目の見積りの合計 / ベロシティ = 必要なスプリント数(期間)
- ベロシティ × 期間内に実施できるスプリント数 = 実現できるポイント(どこまで実現できそうか)
- ベロシティは決めるものではなく測るもの。スプリントを1つやってみて、実現できたプロダクトバックログの項目の見積りの数字を合計する。
- リリースに伴う作業は、品証の部署との調整やパフォーマンス・セキュリティに関するテストといった通常時の作業とは異なることも多いため、自分たちの実力に応じて、プロダクトバックログの項目としてリリースの作業を扱うか、リリーススプリントを用意するか対応しておく
Scene No.07 ちゃんと計画できたかな？
- スプリントプランニングでは2つのことを行う
- そのスプリントで完成させる項目を選定し(POが開発チームに提示し実現可否を判断)、各項目の完成状態をPOと開発チームで合意する。完成状態は具体的に、このボタンを押下するとこの画面に遷移して〇〇が確認できるといった粒度のもの(デモ手順とも呼べる)
- 開発チームはタスク(XX画面を実装するなど)を洗い出し、詳細な見積もりを行い、その期間で本当に終えられるか見極めを行う。タスクと見積もりはバックログと呼び開発チームの成果物となる。
Scene No.08 スプリントは順調かな
- デイリースクラムは、スプリントゴールを達成できるかを検査するイベントであって、問題を見つけること(問題がないか検査すること)が目的であり、誰かへの進捗報告会ではないことに注意
Scene No.09 これって間に合うのかな？
- タスクボードは、あるスプリントのプロダクトバックログの項目とそのためのタスクを全て、未着手(ToDo)、着手(Doing)、完了(Done)に分けて貼り出すというもの
- スプリントバーンダウトチャートは、各スプリントの営業日に対する残タスクの見積もり時間合計の実績をプロットしたもの
Scene No.10 だいたい終わってまーす
- スプリントは、スプリントレビューとスプリントレトロスペクティブ(振り返り)で完了する
- スプリントレビューでは、率直な意見やフィードバックをもらうためにデモがとても重要なので万全の状態で臨む(動かないものにはフィードバックできないため)。画面キャプチャの切り張りではNG。
- 完成の定義は開発チームのチェックリストのようなもので、一例として下記のようなもの。スプリント開始前にスクラムチーム全体で合意しておく。
- デモ手順の通りに動作する
- publicメソッドのテストコードが存在する
- 最新の仕様がwikiにまとめてある
- 完成の定義は、リリース時で求められる品質基準とは一致していなくてもよいが(例：セキュリティ、パフォーマンス、ドキュメント検証等)、後回しにしておくと痛い目に合う。
Scene No.11 あともう1日あれば…
- タイムボックス(例：スプリントの期間)は変えないのが重要(最終的に実現したいプロダクトバックログの項目が完成するタイミングを予測するためにスプリントのポイントを使って計算するため、延長してしまうと他のスプリントと比較できないため)
Scene No.12 少し早く終わったぞ！
- プロダクトバックログは、工数に余裕があり少しだけ(例：2ポイント)追加したいといった状況があるが、その場合はバックログの項目を分割するようにする。そのときに分割しやすさだけを考慮し画面だけ作成するといった項目を追加するのはNG(スプリントレビューで動くものを見せてフィードバックをもらうため)。
Scene No.16 うまく伝わっているのかな？
- 開発チームに実現したいことの意図を共有するのが重要(開発の中で細かな実現手段を自分たちで判断しやすくなるため)
- プロダクトバックログにデモ手順の隣に「ストーリー」として下記を記載する
- 〈どういったユーザーや顧客〉として 〈どんな機能や性能〉がほしい それは〈どんなことが達成したい〉ためだ
Scene No.19 今後のことが分からない？
- プロダクトバックログは誰でも記入可能であるため、順序の見直しや見積もりの最新化といった手入れ(リファインメント)を行うのが重要。スプリント期間中に少なくとも1回(スプリント半分経過後あたり)は実施するようにするのが良い(順序の見直しはPO主導で、見積りは開発チーム主導で)。
Scene No.21 あれ？間に合わない…
- スクラムがこのままではゴールに届かなさそうなとき開発を進める上で調整可能なものを調整する
- 品質 ← 一定レベルにする必要がある
- 予算 ← 即効性がない(部内の承認がある、人員追加でも立ち上げ期間を要する等)
- 期間 ← 少しなら調整可能なことはある
- スコープ ← 最も調整が現実的。スコープの順番の変更、項目削減、項目順序は変えずに実現手段のみ変更といった形で調整する。
Scene No.22 この作業は苦手です…
- スクラムでは、開発チームは自己組織化していて、機能横断的であることが求められている
- 自己組織化：自分たちで状況に応じて役割を決めていくこと
- 開発を進めていると、様々な状況があるため(例：POと議論、設計の方向性決め、技術選定、議事録やマニュアルの作成)、それぞれで得意な人がリーダーシップを発揮し困っている人を助けるのが重要
- 機能横断的：開発チームだけでスプリントを円滑に進めていけるようになっていること
- スプリントを進める上で必要なことを一人ひとりではなく開発チーム全員でうまく協力できていれば十分だが、開発チーム全体が持つスキルや経験で期待されるゴールが達成できそうかを話し合い、スキル不足の場合やメンバーのスキルに偏りがある場合はスクラムチーム外の関係者と相談する
- スクラムでは分担とスウォーミング(swarming、1つのバックログ項目に複数メンバーで協力して取り組むこと)を使い分けるのが重要
- スウォーミングは完了までのリードタイムの短縮、手戻りを減らす、知識移転が進むといった利点がある
- スウォーミングの方法として最近はモブプログラミングが人気
- 自己組織化：自分たちで状況に応じて役割を決めていくこと
