スクラムの経験が半年超えたあたりで読むとちょうど良さそうな本でした。読書メモのみ投稿。
## 二章 スクラムフレームワーク ### スプリントレトロスペクティブ スプリントレビューはプロダクトに対して、レトロはプロセスに対して検査と適応を行う ## 三章 アジャイルの原則 ### 3.1 概要 伝統的な「計画駆動」と比較すると分かりやすい 計画駆動がダメではなく、どちらもプロの道具箱に入っている WFは、計画駆動の一種でしかない 十分に定義され予見可能な場合、計画駆動はうまくいく しかし、ほとんどのプロダクト開発は予見できない ゆえに失敗する ### 3.2 予見と適応 #### 選択肢を広げておく 最終責任時点(LRM) 判断しないコストが、判断するコストを上回るまで判断しない 技術負債へがっつり向き合うタイミングも? 計画駆動は、目的不確実性が排除できていない初期の段階で大量の要件が生み出される。ゆえに危険。 ## 4章 スプリント スプリントゴールは変更しない POと開発チームのコミットメント ## 七章 見積もりとベロシティ 精度より正確性 見積もりをコミットメントにしてはならない コミットメントにすると、実際の見積もりより大きく申告される 「正確性」が失われる ## 八章 技術的負債 負債はインクリメンタルに返す ボーイスカウトルール 「負債返済スプリント」などという言葉が出るなら危険信号 一気に返す状況になるまで放置されたという証拠 金利の高い負債から返す 頻繁に変更が入る箇所 負債を返しながら顧客価値提供も行う まず、質の高い作業にコミット 新たな大きい負債を産まないため ボーイスカウトルールの適用 作業中偶発的に見つけたら、可能な限りその場で返済 作業中の分野に関する返済対象の技術的負債の対応 新たにチケット切って「技術負債返済バックログ」に登録 プランニングで、「今週やる作業に関する技術負債バックログはないか?」と探し、あれば今週のスプリントに乗せる ## 18章 リリースプランニング リリース単位でもバーンダウンチャートつかって進捗を追う スプリントゴールは、予想ではなくコミットメント ## 19章 スプリントの実施 マルチタスクは非効率だけど、常に少なすぎるのも非効率 要はバランス 自分のタスクが終わったら人を手伝う 同時に同じものを触るのとは違う スプリントレビュー 目的は対話。デモは対話のためのツールでしかない レトロスペクティヴ インサイトバックログ やりたいことだけど、アクションには選ばれなかったもの 既存のインサイトと、今回のインサイトを比較してアクションを決める 重要な再度インサイトとして上がるだろうから、捨てるチームもある