📚SCRUM BOOTCAMPを読んでみた

スクラム開発を本格的に始めたので、スクラムの基礎、概念を学ぶため『SCRUM BOOTCAMP』を読んでみました。
今回はまとめたものを書き留めておきます。

対象読者

• 対象はこれからスクラムを始める人やスクラムを始めたばかりの人。

アジャイル開発

アジャイル開発は開発の思想。
主な特徴は下記の通り。

• 関係者は目的達成のためにお互い協力し合いながら進める
• 一度にまとめてではなく少しずつ作り、早い段階から実際に動作するものを届け続けて評価を繰り返す
• 利用者の反応や関係者からのフィードバックを継続的に得ながら、作っているもの自体の計画を調整する

アジャイル開発に共通しているのは「事前に全てを正確に予測し、計画することはできない」ということ。

スクラム

スクラム開発はアジャイル開発手法の1つを指す。
主な特徴は下記の通り。

• 要求を価値やリスクや必要性を基準にして並べ替え、その順に開発していくことで成果を最大化する
• 固定の短い時間（タイムボックス）に区切って作業を進める
• 現在の状況や問題点を明らかにし、常に透明性を保つ
• 定期的に進捗状況や作っている成果を得られるのか、仕事の進め方に問題かないかを確認（検査）する
• やり方に問題があったり、もっと上手にできる方法があったりすればやり方そのものを変える（適応）

スプリント

スクラムでは最長1ヶ月までの固定の期間に区切って、繰り返し開発を行う。この開発期間のことをスプリントという。スプリント内で計画からテストまでバックログの項目を完成させるのに必要な作業をすべて行う。固定の期間に区切って開発を繰り返すことによって開発チームにリズムができて集中できるようになる。スプリントの最終日に作業が残っていてもスプリントは終了し、期間は延長しない。スプリントの期間はあらゆる状況を踏まえた上で決定し、短くて一週間、長くて4週間と、週単位で期間を設定することが一般的。なお、状況の変化により現在のスプリントでの作業の意味がなくなった場合は、POの判断によってのみスプリントを途中で中止することができる。

バックログ

起用や要求、要望、修正などプロダクトに必要なものを抽出し、順番に並べ替えたリスト。
バックログはプロダクトにつき1つと決められており、常にメンテナンスして最新に保ち、不要なものは削除。順番は定期的に見直す。上位の項目は見積もりしておく。
見積もりには時間や金額などの絶対値ではなく、作業の量を相対的に表した値がよく使われる。

スクラムでは最低限のルールとして5つのイベント、3つのロール、3つの作成物で構成される

5つのイベント

• スプリントプランニング（Sprint Planning）
• デイリースクラム（Daily Scrum）
• リファインメント（Refinement）
• スプリントレビュー（Sprint Review）
• レトロスペクティブ（Retrospective）

スプリントプランニング

• スプリントプランニングでは、スプリント内で何を作るのか（What）、どのように作るのか（How）を決定する。
• スプリントでは2つのトピックを扱う。
  1.　スプリントで何を達成するかを決めること
  　POが今スプリントで達成したい目的を明らかにする。次にバックログから目的を達成するための項目を選ぶ。バックログの個数はそれぞれの項目の見積もりのサイズや開発チームの過去の実績（ベロシティ）、今回のスプリントで開発に使える時間（キャパシティ）などを踏まえて仮決定する。また検討した内容を踏まえて今スプリントの目標（スプリントゴール）を簡潔にまとめる。

2.　開発チームがどうやって選択した項目を実現するかについて計画を立てる
　バックログ項目ごとに、具体的な作業を洗い出すなどして作業計画を立てる。スプリント期間中は自由に作業を追加・削除することが可能。また個々の作業は1日ないで終わるように分割するのが一般的。
　スプリント内に項目を達成することが難しいと判断した場合は、POと相談し作業量を調整する。注意しなけばならないのは、開発チームはプランニングで合意した内容を完成されるために全力を尽くす必要はあるものの、計画したことを全て完成させることを約束しているわけではないという点。不測の事態が発生したときに、チームが長時間残業したり、必要な作業を省いたりしてしまう可能性がある。

デイリースクラム

• デイリースクラムは開発チームのための会議。バックログの残作業を確認し、このまま進めてスプリントゴールが達成できるのかを毎日同じ時間、同じ場所に集まって検査する。実施時間は朝である必要はない。
• デイリースクラムは開発チームの人数に関係なく15分間のタイムボックスで行い延長はしない。進め方に決まりはないが以下の3つの定型の質問に答える形で進めることが多い。

1. 自分が機能行ったことは何か？
2. 自分が今日やることは何か？
3. 障害となるものはあるが？

デイリースクラムは、問題解決の場ではないことに注意。メンバーが問題を報告した場合は、デイリースクラム終了後に改めて問題解決に必要な人を集めた別の会議を設定するなどして、デイリースクラム内では解決しないようにする。

リファインメント

バックログの上位の項目については事前準備が必要。例えば、項目の中身を具体的にする、何ができたら完成なのか（受け入れ基準）を明らかにする、など。これらの項目を見積もる活動のことをリファインメント呼ぶ。リファインメントをいつどのように行うかはスクラムでは定義していないが、スプリント開始直前だと準備が間に合わない可能性があるため、時間に余裕を持って行う。リファインメントに使用する時間はスプリントの10％以内にするのが一般的。

スプリントレビュー

スプリントの最後に、PO主催でスプリントの成果をレビューする。POはスプリントレビューに必要な利害関係者（ステークホルダー）を招待する。スプリントレビューの最大の目的はプロダクトに対するフィードバックを得ること。
　レビューでは、開発チームがスプリント中に完成させたインクリメントを実際に披露する。プレゼン等による説明ではなく実際に動作する環境を見ながら確認できるようにする。そして、実際に操作しながら参加者に内容を説明したり、実際に触ってもらったりして、フィードバックを引き出す。レビューでデモすることができるのは完成したものだけ。

そのほかにレビューでは以下のようなことについて報告・議論を行う

• スプリントで完成しなかったプロダクトバックの項目について説明する
• スプリントでうまくいかなかったことや直面した問題点、解決した方法について議論する
• POがプロダクトの状況やビジネスの環境について説明する
• プロダクトバックログに追加すべき項目の有無について議論する
• プロダクトの開発を進める上で問題となる事項について議論する
• 現在の進捗を踏まえて、リリース日や完了日を予測する

レトロスペクティブ

スプリントレビューのあとにスプリント内の最後のイベントであるスプリントレトロスペクティブを行う。
上手く行ったこと、今後の改善点を整理し、次回スプリント以降のアクションアイテムを決める。アクションアイテムは最低１つは次のバックログアイテムに含める。ただ、一度にたくさんのことを変更しようとしないこと。スプリントの期間に関係なく毎週レトロを実施する例もある。

全員参加が必須なイベント

• スプリントプランニング
• スプリントレビュー
• スプリントレトロスペクティブ

各イベントのタイムボックス

• スプリントの期間:1ヶ月以内
• デイリースクラム:15分以内
• スプリントプランニング:8時間まで（スプリント期間が1ヶ月の場合）
• スプリントレビュー:4時間まで（スプリント期間が1ヶ月の場合）
• スプリントレトロスペクティブ:3時間まで（スプリント期間が1ヶ月の場合）

タイムボックスが守れないということは、スクラムチームが未熟なことのあらわれ。

3つのロール

• プロダクトオーナー（PO）
• スクラムマスター（SM）
• 開発チーム

プロダクトオーナー（PO）

プロダクトオーナーはプロダクトの責任者。主な役割は下記の通り。プロダクトの責任者になるため、プロダクトに必ず1人は必要。

• プロダクトのWhatを担当し、プロダクトの価値を最大化する
  • プロダクトのビジョンを明らかにし、周りと共有する
• バックログの管理者で項目の並び順の最終決定権限を持つ
  • 予算を管理し、おおよそのリリース計画を定める
• バックログが完成しているかどうかを確認する
  • 既存のバックログ項目の内容を最新の状態に更新し、内容を関係者が理解できるように説明する
• 開発チームに相談できるが干渉はできない
• ステークホルダーの協業

バックログの作成や更新はチームメンバーも行うが、POが決定したことを他人が勝手に覆してはいけない。理由は結果に対してPOに責任を持たせるため。

スクラムマスター

フレームワークや仕組みがうまく回るようにPOやチームを支える。スクラムをチームに浸透させるような役割だが、マネージャーや管理者ではないため、タスクのアサインも進捗管理もしない。
また、他のスクラムマスターと協力しながら組織全体に支援を行うこともある。

下記がスクラムマスターの一例

• POや開発チームにアジャイル開発やスクラムについて説明し、理解してもらう
• プランニングやレトロなどの会議の進行を必要に応じて行う
• チームの生産性が高くなるように、POと開発チームの会話を促す
• わかりやすいプロダクトバックログの書き方をPOや開発チームに教える
• プロダクトバックログの良い管理方法を探す

スクラムマスターは、仕事を進める上での妨げとなっていることをリスト化して、優先順位をつけて解決の方法を検討し、必要に応じてしかるべき人に解決を依頼するといったことを行うこともある

開発チーム

主な役割は順位付けしたバックログの項目を順番に開発していくこと。開発チームは通常、3〜9人までで構成される。3人未満の場合はお互いの相互作用が少なかったり、個人のスキルに依存する場合が多くなるため結果が出にくくなる。また10人以上の場合は、コミュニーケーションコストが増えることによって開発の効率が落ちるため、チームを分割しサイズを適切に維持するのが一般的。
　開発チームはプロダクトを作るために必要なすべての作業ができなければいけない。要件定義、設計からテスト、ドキュメント作成まで。これを機能横断的なチームと呼ぶ。分析チームやテストチームのように、特定のことしか行わない専門のサブチームは作らない。開発チームのメンバーごとにできることが違ったり能力差があったりするが、作業を進めていく過程でなるべく個人が複数のことをできるようになることが望まれる。
開発チーム内では役職やスキルなどによる特定の肩書きや役割はなく、あくまで開発チーム全体で責任を持って作業を進める。これを自己組織化と呼ぶ。

ここまでに出てきたPO、開発チーム、スクラムマスターを合わせてスクラムチームと呼ぶ。

3つの作成物

• インクリメント
• プロダクトバックログ
• スプリントバックログ

インクリメント

インクリメントとはこれまでのスプリントでの成果と今スプリントで完成したバックログ項目を合わせたものを指す。開発チームは完成したインクリメントを作成する。インクリメントはリリースするかどうかに関係なく動作して検査可能でなければならない。

プロダクトバックログ

プロダクトバックログは、機能や技術的改善要素を優先順位を付けて記述したもの。常にメンテナンスして最新に保ち、不要なものは削除。順番は定期的に見直す。上位の項目は見積もりしておく。

スプリントバックログ

スプリントバックログは、プロダクトバックログからスプリント期間で行うタスクを抜き出したチームのタスクリスト。チームはスプリントバックログをもとにスプリントのタスクをこなしていく。

まとめ

スクラムを活用して良い結果を生むには、スクラムの5つの価値基準を取り入れて実践していく必要がある

• 確約：それぞれの人がゴールの達成に全力を尽くすことを確約する
• 勇気：正しいことをする勇気を持ち、困難な問題に取り組む
• 集中：全員がスプリントでの作業やゴールの達成に集中する
• 公開：すべての仕事や問題を公開することに合意する
• 尊敬：お互いを能力ある個人として尊敬する