6 プラクティス２ 小さなバッチを作る
6.1 小さなウソをつく
6.2 柔軟に進める
内容
タイムボックス、スコープボックスという枠を使って進める。
作業単位ごとに結果が見えるように自分たちにとって正しいサイズにする。
タイムボックスは時間内にタスクを入れる。
スコープボックスは時間ではなく機能単位で作る。
大きなタスクよりも小さなタスクの方がリスクが小さくて済む。
タスクの見積もりが確実になることはないため、１年間で見積もりの誤りを隠しながら積み上げて大きくするよりも、小さな間違いを露見しながら軌道修正しながら進もう。
生産性を上げるために人を増やすことをするが、一概に正しいとは言えない。
例として、子どもを産むのに９ヶ月かかるが、９人集めれば１ヶ月で産める、とはならない。
ソフトウェア開発で大量の要求をさばかないといけない場合も、人数が増えたからといって大量の要求がスムーズに決まり、課題がスムーズに解決するとは限らない。
多くの場合、人を増やすとコミュニケーションラインが増え、複雑化し、速度が落ちるか止まるかする。
リリース日が決まっているのであれば、スコープを絞るべき。
学び
- 要求は人が集まれば解決するものでもない。必要最低限の有識者が課題を解決しながら決まるため、不用意に人数を集めるとリスクになる可能性が高い。
- 人を増やすよりも、有識者になるための情報共有する仕組みが必要
学びを活かすアイディア・行動
- 定期的な勉強会で有識者を作る
