Robin Dymond , Jurgen De Smet.
ヨーロッパで開催されたAgileイベントの映像を発見。＞映像はこちら
シチューみたいになっちゃっているシステムを改善した時の話。
- バリューストリームマップなしでLeanはありえないので、マップを作った
- 13年もののレガシーコードで460人規模の開発者。5ロケーション、26チーム、リファクタリングなし。テストももちろんなし。ビルドに5時間という地獄絵図だった
- この複雑さを、組織構造とR&Dで改善した
- このセッションでは、「開発部」を「R&D」と表現していて、すべての案件は、沢山のチームから依頼が来るが、結局R&Dセクションに集まってくる組織構造にしていた
- 改善が理解されないのはあたりまえだったが、それでも改善
- 中でも複雑だったバージョニングを簡易化することが大きかった
- 問題点として、1つのリストにたくさんのバックログ
- 問題点として、プライオリティが決めにくいこと
- 問題点として、みんなを納得させること
よくありがちな問題。彼らは何をしたか？
- エンタープライズレベルのバックログを作る
- そのためには、不確実性の少ないものをプロダクトバックログの優先度で高くして対策
- そのためには、ジャストインタイムで要件を分解して対策
- そのためには、プライオリティ変更がシステムに与える影響を考えるようにする
これらによってマネジメントは理解を始める。
- なんといってもCIは重要。
- CIは少ないコストで品質を高めることができる
- デモMTGや計画MTGで、ロケーションの違いを埋める努力をする
- 動いているものはやっぱり強い
テクニカル的には
- 開発インフラの複雑さを解消させる
- アーキテクチャ依存の構造をなくす
キーとなる要素は
- 教育はキーとなる
- 継続して学ぶ組織構造
