SCRUM BOOT CAMPを読み返した
4月から正式にMackerelチームのディレクターになったこともあり、チームでスクラムっぽい開発体制を引いているのでSCRUM BOOT CAMPを改めてざっと読んだ。
色々理解できてなかったことが浮き彫りになった。以下読書メモ。
- スプリントバックログ爆発問題
- スプリントバックログはだれでも書き込み可能にしたほうが良いらしいようだ
- issue使うのは悪く無さそうだけどあふれる問題はある
- ベロシティをどうやって計測する?
- 見積もりと実際の乖離をどう可視化するかがわからん
- プロダクトバックログを細分化しないと見積もれない問題
- プロダクトバックログを細かいタスクに分割して見積もるのはやってよいらしい(やってた)
- 詳細にするのは数スプリント分でもいいらしい
- 正確に見積もれないことを認めるの大事
- 見積もりはスプリント会議でやって良いのか?その時点でベロシティ計測だと遅くない?
- どうも遅いらしい
- スプリント会議前に俎上に上げるプロダクトバックログは見積もられている必要があるらしい
- ここは誤解してた
- スプリント会議では、時間単位でもっと具体的な作業見積もりをする
- じゃあどこでプロダクトバックログのストーリーポイントの見積もり(プランニングポーカー)をするのか?
- バックロググルーミングのときか?
- これ、かなり時間かかるはずなのに、明確にいつどれくらいのタイムボックスを切ってやるかの言及が無い(?)
- 他社の人に聞いたら、見積りの時間はちゃんと取って、例えば月一とかで入れてるとのこと
- 詳細にするのは数スプリント分にするとプロジェクトトータルのポイント数は見積もれないのではないか?
- 数カ月先とか見積もれない
- 半年以上のプロジェクトとか無理そう
- まあ自社プロダクトだったら、半年分のマイルストーンがあればまあいいかという感じもある
- 振り返りでインセプションデッキを定期的に見直すとかしても良さそう
- 差し込みタスクをどう捌くか?
- カンバンとの併用が王道っぽいがチーム少ないと難しそう
- カンバンと併用すると見る場所が増えて整理がより大変になる?
- エッセンシャルスクラムには次のような記述もある「
スクラムとカンバンをどちらも使うことができるかもしれない。たとえば、スクラムを新製品開発に用いて、カンバンを割り込み駆動のサポートと保守に使うといった具合だ
」
- 作り出さないと分からないものをどう見積もる?
- バーンダウンチャートで実施済みを棒グラフで併記するの良さそう
- 振り返りでちゃんとストーリーissueクローズまでやると良さそうだなー。というかやるべき
- 現状のチームではスプリントゴールを決めて合意をとれてない
- KPTのやり方見直す。なんか本を読む
- 妨害リストを意識する
- チームに兼務の人多いけど、それもちゃんと「妨害リスト」に入れておいたほうが良さそう
- 教育コスト問題
- 新人教育とかも妨害リストに入れるべき?
- バックロググルーミングちゃんとやってなかった…
- スクラムはシンプルって書かれてるけど結構複雑だよなー
すごくレベル低いことがバレバレですが、突っ込みどころとかあれば突っ込み下さい。