6.3 ケイデンスがプロセスを決める
6.4 小さいことは良いこと
内容
作るものを小さくするほうが良い理由は
- 理解しやすい
- 見積もりやすい
- 実装しやすい
- テストしやすい
結果、早く作れて早く顧客に価値を届けられる。
リリースサイクルが長ければ長いほど1機能ごとに完成するまでのプロセス効率は悪くなる。
人員の変動の可能性が出たりして、引き継ぐためのドキュメント作成の必要性が高くなり、正式なテストフェーズや統合フェーズを必要とするようになり、結果、ウォーターフォールとやってることは変わらなくなる。
また、価値提供の効率も悪くなる。
全10機能を10ヶ月で一度にリリースすると、機能は価値を提供するまでに10ヶ月かかるが、1ヶ月ごとに1機能をリリースすれば、早くからリリースされた機能は早い段階から価値を提供できる。
ウォーターフォール開発は開発効率をコード行数で表すが、そもそもソフトウェアは顧客にどれだけ価値を与えたかで計測できなければならない。
ベロシティ、コード行数が圧倒的にすごくても顧客に価値を与えていなければ意味がない。これらは顧客への価値を計測するための二次的な参考値にすぎない。
学び
- 顧客への価値を計測することが重要
- 生産性だけにフォーカスしても意味はない
学びを活かすアイディア・行動
- KPIを意識することが重要と思うが、具体的な行動は思いつかない
