昨日のエッセンシャルスクラム読書会では、在庫の話をしました。これで3章までオシマイ！
在庫
要件定義→設計→開発→テスト→リリースってするより、フィーチャー単位で開発して細かくリリースする方が僕らの開発には合ってる。
仕掛かり中でリリースできていないものって｢在庫｣だから、できるだけ抱えない方がいいよね。
手持ちを少なくして、細かくリリースすると、想像じゃなくて実際のユーザーの反応を見ることができるし。サービスとして小回りがきく。
例えば、先月まではこのまままっすぐと思ってたけど、今の状況を見たら右に行くほうが良さそう！とか。そういうときに、仕掛かり中の作業があると、それが終わるまで動きづらい。
全部上手くいけばこれが最適なんだ！っていう理想的な効率よりも、もしうまくいかなかったときに回避できるように、現実的なリスク対応をしとくすね。そして、大体なんか起こるすね。
ドンと出すしかない
ドンと出さないといけない場合が多いんだけど、そんなときはどうするの？という質問。
本当に切ってリリースできないんかな？切ったらどうなるかって考えてみたかな？ドンと出して！って言われたけど、実は切ることができて、切った方が儲かりそうだったりしないかな？という回答。
ま、ドンと出す場合でも、フィーチャー単位で開発する方が、モノが見えるので良いですよ。
進捗は実際のモノで
計画駆動でよくある、全体の90％できてます！は、モノで言うとゼロで。何もリリースできないってことだもんね。
じゃなくて。10個ある機能のうち、3個リリース可能な状態です！進捗は30％です！の方が良いよ。
モノを見てもらう
これで初めてステークホルダーから、意見を貰えることって多いので、実際のモノを見てもらうの重要。
全部開発終わりました！見てください！→ここ、もうちょっとこうしたほうが良くない？→Σ(|||▽||| )
コーディング完了？
このクラスはあなたの思った通りにバグなく動く？っていう質問に、はいって答えられる状態でコーディング完了って言いたい。
作業者の稼働
作業者の待ち時間はムダだ！稼働を100％にするんだ！より、80％くらいにしとくほうが、結局コスト低くて済むよね。
ドキュメント
プロセスのためではなくプロダクトのためのドキュメントを書こうよね。
面白かったー
