SCRUM BOOT CAMPを読んでみた
まとめと感想
1. ロールを現場にあてはめる
1. ロールはPO・SM・開発チーム
2. ロールはチーム内での責任範囲を明確にする。
3. 兼任はしない。
4. 具体的に何かが足りていないなら、チーム全体でどう補っていくか考える。
感想：ウォーターフォール開発での責任転嫁リレーが好きではなかった。チームで考えるスクラム開発は好きかもしれない。
2. どこを目指すのか明確にする
1. ゴール（どういうことを実現するのか）やミッション（絶対に達成したいことは何か）を考える
2. インセプションデッキを作成する。全員が参加し意見を出し合う。
感想：バランスが大事だと思った。全員で話し合うのは大事だが、叩き台が無い状態では収集がつかなくなるし、一部の人で決めたものを一方的に伝えるだけでも意味がないし。
3. プロダクトバックログ（PBI）を作る
1. PBIは実現したいすべての事が書かれている一覧。重要度は様々。リリース時期や、そこまでに何を実現するか、現在の進捗状況など、PBIを見れば把握できることが重要。
2. PBIはフォーマットは決まっていない。機能・要望・要求・修正事項などの項目がある。もしくはユーザーストーリーとして項目を作成する場合も。
3. PBIは変更されることが前提だが、変更が大きすぎると、計画も大きくズレてしまうため、最初に実現したい重要な項目に漏れがないことを確認するべき。
4. 開発チームはPBIの並び順に沿って開発していく。PBIの項目は重要度で優先順位を付け、並び替える。優先順位はプロダクトオーナーが責任を持つ。
5. スクラムチームは絶えずPBIの状況を把握し、必要であれば見直しをする。
6. PBIの作成は大事だが、今後継続して修正することも考慮し、一度に時間をかけすぎないことも重要。
感想：
- PBIは機能単位で記述してある？ フロントとバックで同じPBI？ フロント終わってないのに、完了のチェックマーク入ってる？
- PBIはスクラムチームから干渉可能？（現プロジェクトの場合）
- 何かあればPBIへ干渉するべき
- 過去にタスクを選択する際に、PBIの優先順位に沿っていないことがあったので、気を付けたい。
4. 見積もりをしていく
1. SBIの項目から実際にどんな作業があるか着目する
2. 開発チームで作業を相対見積もりする
3. 作業自体は不確実なものなので、フィボナッチ数列の値を使うなどし、細かな誤差は気にせず見積もる
4. 見積もりはあくまで推測なので、先々まで細かく時間をかけて見積もりをすると、推測が外れた場合に見積もり時間が無駄になる可能性がある。
感想：
- スクラム開発のPBIの見積もりは、開発の見積もり自体が不確実という前提に進めようとしていて、非常にフレームワークとして柔軟だと思った。また、少しやってみたら具体的に上手く行くところ行かないところが出てくるから、それを改善していきましょう、というスタンスが、すごく現実的だし前向きに取り組める感じがして良いなと思った。
5. 見積もりをより確実にする
1. 開発チームでプランニングポーカー
2. 開発者それぞれが発言し対話を通して認識のズレを合わせたり、見落としていた部分を洗い出すなどする。
3. 見積もれないことが分かることも大事。
感想：
- 自分の分からないところを見積もるのは大変だが、やっているうちにお互いの作業の理解にもなり良いと思った。
6. この先の計画を立てる
1. ベロシティが分かれば先の見通しが立つ。
2. ベロシティは決めるものではなく、測るもの。逆算思考ではなく、積み上げ思考。
3. 慣れるまでの期間はベロシティがなかなか上がらないこともある。
4. PBI以外にも、リリースまでのマイルストーンを図にするなど、先のことが分かるように整理しておくとよい（リリース計画の作成）
感想：
- ついベロシティを上げるために、タスクの進捗をごまかしたい邪念が出てくる笑。でも不確実なプロジェクトを前に進めていくために、1つ確実なベロシティを測定していくことが重要。その上でスプリント毎にベロシティを改善していく話し合いをしていくことが大事なんだと理解した。
7. 詳細な計画を立てる
1. スプリントプランニング
1. どのPBIを達成できるか、ベロシティを基にPOと開発チームで決める。
2. PBIからタスクに落とし込み、タスクの見積もりを行う。タスクと見積もり→スプリントバックログ（SBI）
3. 先まで考えすぎない。時間をかけすぎない。確実に実行できそうな具体的で詳細な計画を立てることが重要。それができれば先の予想も確実になっていく。
4. スプリントゴールをしっかり意識できるようにする。スプリント終了時のデモ手順をあらかじめ決めておくのも有効な手段。
感想：
- スプリントプランニングの際に、ゴールのデモを考えるのはすごく有効な気がした。
- スプリントゴールをかなりストレッチした目標に設定してしまっていたので、今スプリントのベロシティを基に、達成可能なラインにしていきたい。
- 現状のPBIがちょっと荒すぎる印象。。。
8. 素早くリスクに対処する
1. 毎日時間を決めて、デイリースクラムを行う。スプリントゴールを達成するために、昨日やったこと・今日やったこと・障害や問題点を伝え合う。
2. 目的は、スクラムマスターへの報告ではなく、問題の洗い出しを行い、スプリントゴールを達成するために修正を行うこと。
感想：
- デイリースクラムの目的に認識のずれがあった。ただの進捗報告にならないようにしたい。
9. 状況をうまく把握する
1. スクラムでは透明性が大事。いち早く問題にチームで気づき、微調整する。
2. タスクボードや、バーンダウンチャートなどで停滞しているタスクや問題に気づけるようにする。
感想：
- 透明性が大事。
- 現状進捗の共有はしているが、日々タスクの残工数を更新してはいなかった。
10. 何が完成したかを明らかにする
1. スプリントレビューでは何が完成して何が完成してないか説明する。また開発チームでデモを行い、フィードバックをもらう。
2. ソフトウェアは動くものを見てはじめて評価できるため、デモは重要。また、そのフィードバックはPBIの作成時点では分からなかったものが出てくるかもしれない。
3. 完成の定義はスクラムチームで話し合い、更新しながら進めていく。
感想：
- 今後スプリントが進んだでデモも見せた時に、フィードバックがたくさん出てくるイメージが沸いた。。その時に建設的な話ができるように準備をしていきたいと思った。
11. 先を予測しやすくしておく
1. タイムボックス（それぞれのイベントの時間やタイミング）をしっかり守ることで、先の予測ができるようになる
2. タイムボックスを守れないことがきっかけで、準備不足が分かったり、そのイベントがそもそも何をするものなのかを考えることができる。
感想：
- スクラムをやってみて、イベントの前に準備が必要っというのは分かってきた。今後もスプリントを重ねていくなかで工夫できることをやっていきたい。
12. 次にやることを明確にする
1. もしスプリント中にタスクが早く終わってしまったら、リファクタリング・自動テストなどを進めてもいいし、次のSBIに着手してしまっても良い。
2. PBIは常に意識し、整理しておく。PBIの編集は誰でもやってよいが、優先順位を決めるのはPO。
感想：
- PBIの内、どこまでをフォーカスして把握しておくのかが難しいと感じた。あまり先まで考えすぎてもいけないし。1・2スプリント先くらいまでかな。。。？
13. みんなの自立を促していく
1. スクラムイベントは最小限の枠組み。足りないことは足していくべきだが、ルールが詳細化しすぎると誰も守れなくなる。バランスが大事。
感想：
- チーム毎にルールを変えている理由が分かった気がする。メンバーの性格によって作るべきルールも変わってくるかも。そこが腑に落ちたのはよかった。より対話を大事にしていこうと思った。
14. ベロシティを上げていく
1. ベロシティには安定性が重要。上がり続けていてもダメ。良いスクラムチームは安定感がある。
2. ベロシティを上げたり安定させたりするために、どうすれば作業がスムーズにいくか考える。
3. ベロシティは短期間で劇的に変わるものではないし、あくまで目安となる数字である。
感想：
スクラムチーム外からリリースの前倒しなど要求されることは、あるあるだと思うが、ベロシティを基準にしたり、今後予期せぬ対応が出てきたりすることを想定して対処しないといけない。
15. 問題を見つけやすくする
1. スプリントプランニング・スプリントレビュー・スプリントレトロスペクティブはスクラムチームの全員が参加する。POは何をどこまでやるか、そのゴールを達成できたか確認する必要があるし、SMは潤滑にイベントを進める必要がある。またこのイベントは情報共有の場にもなっているため、どのメンバーにも重要。
感想：
本ではPOのタスクをみんなで支援しようとあるが、今の現場ではそれは現実的ではないかも…ただイベントの実施などに関してはなるべく柔軟にやっていきたい
16. 意図を明確にしておく
1. PBIをタスクに落としていくだけではズレが生じる。PBIをユーザーストーリーのフォーマットで伝えることで意図が明確になりやすい。ユーザーストーリーを基にデモを決めるのも良い。
感想：
ユーザーストーリーはすでにあるが、デモはそれを踏まえたものになっていなかったので、ちょっともったいない。改善していきたい。
ユーザーストーリーがPBIと並べて見れるようになったらいいのになぁ（どこに記載あったっけ）。
17. スクラムチームを支援していく
1. 問題が起きたら対処する。例えばコードの質が悪く作業効率が下がっているなら、リファクタリングのタスクを入れるなど。
2. 対処療法として問題にあたるだけでなく、そもそもなぜ問題が起こるのか、根本的な部分の解決も必要。例えばコードの品質を保つルールを作るなど。
感想：SMがチームにとってすごく重要。問題を敏感に察知して、それを上手く引き出す質問を投げかけるなどは、結構スキルも必要な気がする。
18. よりよい状態にしていく
1. スクラムチームに問題はつきもの。把握→対処のプロセスで進んでいく。
2. 問題が発生したらすぐに対処する。これはタスクを進めるより大事な事。
3. SMは障害を管理する。優秀なSMだと一覧にすると障害の数が50個以上？！
感想：
スプリント中にタスクを追加しても良い？？
19. 先の事をいつも明確にする
1. PBIは常に更新される。固定された人だけが管理せず、みんなの意見を出し合う。
感想：
改めてメンバー1人1人が参加していくことが大事なんだと感じた。ブレーンストーミング的な意味がある。
20. 手戻りを無くしていく
1. あいまいなまま進めようとするほど、手戻りが発生するリスクが高まる。
2. スプリント前にあいまいな箇所を確認しておくのがベスト。
感想：
改めてイベント前の準備って大事だなと思った。
21. ゴールに近づいていく
1. 達成すべきゴールは常に変化する可能性があるので、最新情報を確認する。
2. ゴールに近づくために2つのことを考える
1. よりチームの開発を円滑にできないか
2. 予算・期間・スコープを調整できないか（品質は調整できない）
感想：
もしリリースに間に合わない場合はスコープを調整するのが現実的だが、大きな組織になるほどそこの調整は難しくなりそうな印象。
22. さまざまな状況に対応していく
1. 自己組織化したチーム→状況に最適な人がリーダーシップをとっていく
2. 1人1人が優秀な開発チームより、助け合って進める開発チームの方がスクラムとしては良い開発チーム
感想：
自己組織化を目指す上でのリーダーシップの取り方がなるほどと思った。
メンバーは優秀であるにこしたことはないと思うが、コミュニケーションが適切に行われ、お互いを補完し合うようなバランスの取れたチームを目指したいと改めて再認識できた。
23. より確実な判断をしていく
1. 実際の作業に関係のない人の意見はあくまで参考意見。
2. コミットメントは重要。だからこそ責任の持てない約束はしない。
感想：
鶏と豚の例え話が全然良く分からない笑
24. リリースに必要なことをする
1. リリーススプリントを作成する
感想：
リリーススプリントで沢山課題が出てくるイメージが容易にできる…
結局漫画ではリリース前にずっと深夜対応している笑
25. 実践編で伝えたかった事
1. スクラム開発はあくまでフレームワーク。改めて下記メリットがある。
1. どこが上手くいってないか特定しやすい
2. 上手くいっていない問題を解消する機会がある
3. 上手く進めるためにやり方を変える機会がある
4. やり方を多少変えても影響が少ない
感想：スプリントレトロスペクティブを書かなかった理由が微妙。問題解決の場ではなく、よりよく進めていくための方向性決め、と説明すればよかったのでは？あとプロダクトの説明を省いたことについても、そこけっこう大事なのでは？と思った。
スクラム開発はだんだん身についてくるものでもあると思うので、今後も本を読み返したり、さらにアジャイルサムライを読んだりして、精進していきたい。
