アジャイル関連の本をとりあえず一冊読み切った。実務で早く実践してみたい！今回はシーンごとに思い出して書いていこうと思う。
scene12：スプリントが巻いた
テストの拡充だったり、来週分のバックログの先行着手だったりを行う。先行着手の場合は、スプリント内に動くものができない場合は対象物として含めない。
scene13：みんなでスクラムチームだ
スクラムチームの自覚を持つ。つまりデイリースクラムはスプリントゴールまでの進捗を確認する場所なので、参加必須。チーム内でルールを作ると自走して守ることができる
scene14：部長の動きうざすぎ
ベロシティはあくまで目安。安定している状態がチームのベロシティとしての指標値になるべき。見積もりをやたら多めにすればベロシティは上がるが本来の役割ではない。って考えると目標管理で生産性を含めているの悪手だったのでは、、、あげるために無意識的に操作はしてしまうし、、、
scene15：POは大きな決定権を持つ
POは忙しくなりがちだが、チームの一員なので時間を作ってもらってMTGを是が非でも参加してもらう。無理だったらロールを変えるのもありかも
scene16：POと開発メンバー目的の違いによる認識のずれ
POは、「何を作るか」に目的がいく、メンバーは「どうやって作るか」に目的が向いてしまう。そのずれは対話でカバーする。プロダクトバックログのストーリーを「どういった顧客にどんな機能を提供してどんなことを達成させるか」伝える文体で対話の機会を創出する。
scene17：問題の早期発見
チームが機能不全に陥っている兆候があったら周りにヒアリングをとってみて問題のタネを見つける。透明にすることで課題対処ができるようになる。本では技術的負債が見つかっている
scene18：スクラムマスターのやること
スクラムマスターはチーム内でサーバントリーダーシップを発揮する仕事。みんなの困り事を刈り取るために奔走する。技術的に弱いところを自分が学習したりして、チーム内に展開することでチームのボトルネックを取り払う。
scene19：プロダクトバックログは誰でも書き込めるべき
書き込んだものを優先順位を常に最新化することで本当に必要なものかどうかを見極める。
scene20：手戻りをなくすにはスプリントプランニングで曖昧さを排除する
手戻りが発生する要因は三つの曖昧「案件の仕様」「機能理解」「技術」が原因。見積もりの段階で三つの曖昧についてチームで擦り合わせることで理解することができる（はず）
scene21：スコープは出し入れすることで納期に間に合わせる
納期に間に合わないかもしれないみたいな場合は、スコープを調整できないか交渉するしかない。
scene22：苦手な作業はチーム内でカバーしあえ！
チーム内で得意不得意があると思うので、星取表など使って得意な人と一緒に作業する。ペアプロなどで一緒にやることで苦手な部分を身につける。
scene23：失敗を許容する
無理ならNoという、「約束は小さく、成果は大きく」
scene24：リリース作業用のスプリントを用意する
scene25：本書はうまれたてのスクラムです。