- 余白=リファクタリングとか、便利ツール導入とかする余裕
- 直感的には、本筋でいえばPOとの議論を経てプロダクトバックログに積まれるべきなんじゃないか
- 「透明性」「検査」「適応」ってことで
- SCRUMとXPを組み合わせる場合、リファクタリングはプロダクトバックログやスプリントのタスクに入れた方がよいですか。それとも各自が定常的に実施すればよいですかでは最初は積んで習慣化していこうということになっていた
- ボーイスカウト・ルール | プログラマが知るべき97のこととして定着させていこう、みたいな感じかな
- 一方で、本を読んでいると、定期的に改善のための時間を取りましょう=仕組み化しましょう、という話がよく出てくる気がする
- どの本だっけ？INSPIRED を読んだ - 下林明正のブログとかLeanとDevOpsの科学 を読んだ - 下林明正のブログとか エンジニアリング組織論への招待 を読んだ - 下林明正のブログとかに記述があったような、無かったような
- POは必ずしもエンジニア出身でないし、エンジニア出身だったとしても実際にコードを書いているメンバーとの知識の非対称性はどうしても生まれてしまう。だから余白の着手順が上にならないことはよくある。そして、余白をつくれずにどんどん身動きが取れなくなってしまう場合が多すぎる。だからここは諦めて仕組み化しよう、みたいな感じなんだろうか(要出典)
- 仮にボーイスカウトルールが徹底されていたとしても、便利ツールの導入みたいな動きは難しそう
- しかし余白の着手順を上げられていないような状況では、仕組み化すること自体が難しそうな気もする
- ベロシティの低下などからアラートが上がって着手しようになるんだろうか
- いまいちこのあたりうまく自分の中で整理できてない気がしてきている。まあ現実的には、余白が必要なのにうまくつくれてないとふりかえりなどで感じたら、先ずはPOと都度議論、難しそうなら何らかの方法で仕組み化をする、どれもできなければあとは泥舟、という感じなのかな
- 本当に必要なのか、どれくらい必要なのかの判断が難しい気がする。まあでもそこは案ずるより産むが易しで、諦めて一定コスト割いてしまうほうが建設的、ということなのかも
- 例えばマトリックス型組織なら、エンジニアグループみたいな職能組織が経営層にかけあって全社ルールとして設定する、とかなのかな
追記
以下のような話題があったので追記
- 例えば、ソフトウェア品質のメトリクスをKPIを設定すると余白にも適切に目が向きやすくなるのではないか
- たしかに
- むしろスクラムを導入したほうが余白をつくりやすくなる
- スプリントでどこまでやればよいのか明確になるので、余白をつくりやすくなる、というような話
- これはどっちもありえそうだなと思った。積み込めるだけ積み込みたくなるフォースも発生しやすそうなので、チームによりそうな印象
