スクラムを基本から学びなおしたいので、スクラムガイド(2017)読んだ - $shibayu36->blog;に続いて、SCRUM BOOT CAMP THE BOOK【増補改訂版】を読んだ。
個人的に印象に残ったのは
- インセプションデッキは単なる話し合いの機会を提供しているにすぎない。みんなで一緒にスライドを作り、認識合わせをすることが一番
- 確かに成果物よりも過程に意味があるフレームワークは多い
- プロダクトバックログの順序をつけるときは、直近の数スプリント分くらいに注力する。早く実現したいものが漏れていなければ問題ない
- 今の自分のチームの優先度付をどうするかについて悩んでいたので参考になった
読書ログ
* スプリントプラニングを開始する前にプロダクトバックログリファインメントと呼ぶ事前準備が必要。プロダクトバックログの上位項目について準備する 338
* 項目の中身を具体的にする、項目の疑問点を解決する、受け入れ基準を明らかにする、項目を自分たちが扱えるサイズに分割する、項目を見積もる、など
* デイリースクラムは問題解決の場ではない。問題が報告されたらデイリースクラム終了後に改めて必要な人を集めた別の会議を設定する。デイリースクラムはタイムボックスを守る 386
* スプリントレトロスペクティブで出たアクションアイテムのうち最低1つは次のスプリントのスプリントバックログに含める 426
* スクラムの流れの図 474 ※
* プロダクトオーナーとスクラムマスターを兼任するのは絶対にだめ 615
* POは作るものをより良くすることに注力する必要があるので、開発チームにもっとたくさん作って欲しいなどのプレッシャーを無意識のうちにかけてしまうかもしれない
* インセプションデッキは単なる話し合いの機会を提供しているにすぎない 711
* 自分たちの向かう先についてみんなで知るためのツール
* 1時間半くらいでみんなでスライド一枚を作り上げるくらいの気持ちで
* 出来る限り一緒にスライドを作る時間を確保する
* 優先順位は分類ごとに一列に並べる 808
* 超重要、重要、ふつう、あればうれしいとか
* 感想) 分類ごとで良い、というのは面白い
* エレベーターピッチを作る時は、メンバーごとに書く時間を取り、全員がかけたら共有しあう 1028
* 認識のずれなどが見える化される
* プロダクトバックログの順序をつけるときは、直近の数スプリント分くらいに注力する。早く実現したいものが漏れていなければ問題ない 1614 ※
* 9人以上の人数で開発する場合、複数の開発チームで協力しながら開発を進めるアプローチを取る 2665
* プロダクトオーナーは一人、プロダクトバックログも1つ
* それぞれの開発チームにスクラムマスターがいる
* プロダクトバックログが大きくなるとプロダクトオーナーの負担が大きくなる。プロダクトオーナーを支えたり横断的に問題解決したりするために、スクラムオブスクラムを行う
* デイリースクラムの後にリーダーだけが集まって検査を行う
