SCRUM BOOT CAMPまとめ（アジャイル開発）

# はじめに
今回も書籍を読んだまとめ記事として投稿させていただきます。
参考にさせていただいた書籍は「[**SCRUM BOOT CAMP THE BOOK**](https://www.amazon.co.jp/SCRUM-BOOT-CAMP-BOOK%E3%80%90%E5%A2%97%E8%A3%9C%E6%94%B9%E8%A8%82%E7%89%88%E3%80%91-%E3%82%B9%E3%82%AF%E3%83%A9%E3%83%A0%E3%83%81%E3%83%BC%E3%83%A0%E3%81%A7%E3%81%AF%E3%81%98%E3%82%81%E3%82%8B%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E9%96%8B%E7%99%BA/dp/4798163686)」です。
はじめて「スクラム」をやることになったら読む本として紹介されているこちらの書籍を基にアジャイル開発の説明や実践方法をまとめていきます。

## アジャイル開発とは
* 関係者は目的の達成のためにお互い協力し合いながら進める
* 一度にまとめてではなく少しずつ作り、早い段階から実際に動作するものを届け続けて評価を繰り返す
* 利用者の反応や関係者からのフィードバックを継続的に得ながら、作っているもの自体や計画を調整する
* 主な手法にスクラム、エクストリーム・プログラミング、カンバンなどがあるが、これらのアジャイル開発手法に共通しているのは「**事前にすべてを正確に予測し、計画することではない」ということを前提にしている点**である
* どのくらいの期間や人数で仕事をするかを決めて、重要なもの、リスクの高いものほど先に作り、そうではないものは後回しにすることで成果を最大化していく

## スクラムとは
* 要求を価値やリスクや必要性を基準に並べ替えて、その順にプロダクトを作ることで成果を最大化する
* スクラムでは固定の短い時間に区切って作業を進めます。固定の時間のことを**タイムボックス**と呼びます
* 現在の状況や問題点を常に明らかにします。これを<font color="Red">**透明性**</font>と呼びます。
* 定期的に進捗状況や作っているプロダクトで期待されている成果を得られるのか、仕事の進め方に問題がないかどうかを確認します。これらを<font color="Red">**検査**</font>と呼びます
* やり方に問題があったり、もっとうまくできる方法があったりすれば、やり方そのものを変えます。これを<font color="Red">**適応**</font>と呼びます。

※スクラムのルールは「[**スクラムガイド**](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf)」で定義されています

### 最低限のルール
5つのイベント（会議など）、3つのロール（人の役割）、３つの作成物など最低限のルールのセットで構成されています

#### イベント
* スプリント
* スプリントプランニング
* デイリースクラム
* スプリントレビュー
* スプリントレトロスぺクティブ

#### ロール
* プロダクトオーナー
* スクラムマスター
* 開発チーム

#### 作成物
* プロダクトバックログ
* スプリントバックログ
* インクリメント

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1834935/2b7b1fe4-1edd-bc48-a43e-304c41bf9751.png)



## 3つのロール（役割）を現場にあてはめる
ロールは単なる目印であり、チームに適した役割分担にする必要がある。
ただし、プロダクトオーナーとスクラムマスターの兼任はバランスが崩れやすくなるため、絶対にダメ。
#### プロダクトオーナー
何のために何をどういう順番で作るのかを決める人。
実際の利用者から高い評価をもらえたり、顧客や自分たちのビジネスに貢献するために必要なことをやっていく。
ただし、使える予算や期待されるリリース日といった制約の中でそれをやらなくてはいけない。

#### スクラムマスター
プロダクトオーナーと開発チームがスクラム開発をうまく進められるようにする人。
スクラムでスクラムで決められていることをみんなにただ守ってもらうだけでなく、スプリントレビューを進められるように支援する人。
もし何かうまくいかないことがあって仕事が円滑に進んでいないのなら、それを取り除く役割。

#### 開発チーム
プロダクトオーナーが実現したいと思っていることを、実際に作る人たち。
どうやって作るかは開発チームに任されている。
コードを書くだけでなく、要求を聞き出したり、見積ったり、設計、画面デザイン、テストをしたり、必要な作業をすべてこなしていく人。

## スクラムをする上で重要なこと
#### どこを目指すのかを理解する
チーム全員がスクラムチームに期待されている2つのことを知っておくことが重要
* どういうことを実現するのか（ゴール）
* 絶対に達成したいことは何か（ミッション）
#### プロダクトバックログを作る
プロダクトバックログとは、実現したいことが全て書かれている一覧である。
いつ頃終わるかの見通しを立てるためにプロダクトバックログで先の計画を立てる必要がある。
最初からさまざまな視点で洗い出すことで重要な項目が漏れないようにしておくことが重要。
プロダクトバックログを見ることで全体の大まかな流れがわかるようにしておく。
#### 見積もりをしていく
見積もりは推測であり、素早く行う。
詳細にするのは直近のものだけにしておくほうが良い。
#### 見積もりをより正確にしていく
個人で見積もったものに対してチームで話し合う。
多くの目でチェックし、さまざまな意見をまとめていくことで、より正確なものにしておく。
#### この先の計画を立てる
以下の計算式でこの先の計画を立てていく。
* 絶対に必要な項目の見積もりの合計 ÷ ベロシティ = 必要なスプリント数（期間）
* ベロシティ × 期間内に実施できるスプリント数 = 実現できるポイント（どこまで実現できそうか）
#### 詳細な計画を立てる
確実に前に進める計画を立てていく。
ベロシティを参考にすることで計画した作業量が適切かどうかが判断できる。
スプリントプランニングでは確実に終わらせられる計画を作る。
#### 素早くリスクに対処する
どこかに問題がないかを検査するために、毎日の「デイリースクラム」が重要になる。
目的を理解して行い、ただの進捗報告会にしないようにすることが大切。
#### 状況をうまく把握する
問題になる前に見つけて対応する。
タスクボードを使えば、タスクの状況が把握できる。
#### 何が完成したか明らかにする
完成の定義をあらかじめチームで話し合った合意のもと決めておく。
その上で何が本当に完成したか明らかにすることが大事。
#### 先を予測しやすくしておく
タイムボックスで決められた時間は絶対であり、延長してはいけない。
もし延長してしまうと、他のスプリントとの比較ができなくなってしまう。

以下はタイムボックスの一例である。
* スプリントの期間は1カ月以内
* デイリースクラムは15分以内
* スプリントプランニングは8時間まで（スプリント期間が1カ月の場合）
* スプリントレビューは4時間まで（スプリント期間が1カ月の場合）
* スプリントレトロスペクティブは3時間まで（スプリント期間が1カ月の場合）
#### 次にやることを明確にする
スプリントで予定していたものが早く終わった場合に、次にやることを明確にしておくとよい。
プロダクトバックログ自体を頻繁に更新しやすくしておく。
#### みんなの自律を促していく
自分たちのルールを守っていくのは自分たちである。
ルールはみんなが見えるような場所に貼っておくと守りやすい。
自分たちの責務について理解しないとうまくいかない。
#### ベロシティを上げていく
人を増やしてもベロシティは上がらないが、人が増えなくてもより作業をうまく進められればベロシティは上がっていく。
ベロシティはあくまで目安になるので、惑わされないことも大切。
#### 問題を見つけやすくする
スクラムイベントでは大切な情報が得られるようになっている。
ロールで担当する部分を分けているので、どこに問題があるか見つけやすい。
#### 意図を明確にしておく
スクラムでは、プロダクトオーナーが開発チームに実現したいものをなんとしてでも伝えなくてはいけない。
実現したいことの意図を書き、頻繁に話し合って伝えていくことが一番大切
#### スクラムチームを支援していく
スクラムチームを常に良い状態にしておくのがスクラムマスターの役割。
スクラムチームを観察して、どこがうまくいっていないか見つけたり、問題が生じないように支援していく必要がある。
#### より良い状態にしていく
達成したいゴールを脅かすような問題はチーム全員が把握しておくことが大事。
障害に対しては順序をつけてどれを優先的に解決するかを明確にしておく。
#### 先のことをいつも明確にする
プロダクトバックログに関しては以下の作業を行う必要がある
* 重要なことを見逃さないために順序を見直す
* 見積もりを最新化する
* ゴールを達成する上で最適な順序になるように見直す

見積もりし直すことで、最新の情報がわかり、先のことが明確になる
#### 手戻りをなくしていく
実現したいことがあいまいだと色々と問題が出てくるし、手戻りが発生してしまう場合がある。
直近のスプリントの分だけ、あいまいなことをなくしておけばよい。
大きな手戻りはちょっとした工夫で防げる

* 実現したいことは先に深く理解しておく
* 決めるべき仕様を決めておく
* 技術的にどういうふうに実現するといいか確認しておく
#### ゴールに近づいていく
ゴールにたどりつくためにはスコープの調整が必要になる時がある。
実現方法を工夫するのはスクラムチームにとってやりやすい調整の仕方である。
#### さまざまな状況に対応する
開発チームがどういうスキルを持っているのか理解して、全員でさまざまな状況を克服できるようにしておくのが大切。
一人ひとりが得意な作業だけをやっていてもダメ。誰かが困っていたら他の人が助けて、チーム全体でのｃ協力が必要。
#### より確実な判断をしていく
失敗からどんどん学んでいこう。
チーム全員が責任を持って取り組んでいけるように少しずつ築き上げていくことが重要。
#### リリースに必要なことをする
リリーススプリントでは、リリースの基準を満たすための作業を洗い出し、やり残りがないようにチェックして取り組んでいく。
残っている作業をなんでもリリーススプリントに回すのではなく、やれそうなことは後回しせずに取り組んでおく方がよい。