同期安定化プロセスのメモ

クスマノの本「ソフトウエア企業の競争戦略」をもう一度読み直した。
この本には、マイクロソフトの開発プロセスである同期安定化プロセスについて詳しく書かれている。
考えたことをメモ。

【元ネタ1】
Y2’s blog ? Blog Archive ? 本: マイクロソフト・シークレット(上)

次に開発プロセスです。開発プロセスについては、クスマノ氏が「同期安定化プロセス」と読んでいるマイクロソフトの手法についての説明です。
しかし、読み進めていると、実はこれがほぼScrumやXPなどのアジャイル開発プロセスが進めている方法と同一であることがわかります。
この本が出版されたのが1998年、アジャイルマニフェストが公開されたのが2001年とのことで、実はアジャイルマニフェストを作成した人々は同期安定化プロセスを参考にしたのではないかと疑います。

少し具体的にあげると、
・定期的なビルド -- アジャイルやスクラムでのDaily Buildやイテレーション
・開発工程の分割 -- スクラムのイテレーション
・プログラム管理者と開発チーム -- スクラムのスクラムマスターとチーム
・設計書より成果物を優先 -- アジャイルでも同じ
・見積もりは開発者に行わせる -- スクラムでも同じ
などです。

マイクロソフトが編み出した同期安定化プロセスとアジャイル開発の類似性は、知っている人には知られている。
曰く、夕方5時にデイリービルド。
曰く、プログラマはテスト担当者とペアになって作業する。
曰く、開発目標は定めるが、頻繁に変わる設計書よりも動く製品を優先する。

つまり、複数のサブチームの成果物をデイリービルドで「同期」を取り、その度にテストして「安定」を図るのが同期安定化プロセス。

アジャイル開発も同期安定化プロセスも、結合テストを早期に行っていると言うのが最大の特徴ではないか？

SW開発はいつも、多数のモジュールをバラバラに作った後にビッグバン統合を実施し、結合テストを行って、初めて重大な問題に気付く。
単にコンパイルエラーが見つかるだけでない。

インターフェイスが合わなかったのは、設計書に記載が無かったからだ。つまり、設計漏れ。
動かしてみて顧客に見せたら、違っていると言われた。つまり、要件漏れ。
実際にビルドしようとすると、ビルド環境の構築作業が間違っていたり、ライブラリのバージョンに相違があったり、テストデータが足りなかったりしていたからだ。つまり、ビルド作業漏れ。
そういう重大な問題は早期にキャッチしたい。

しかし、実際のSW開発では早期に結合テストを行うことができない。
特にWF型開発ではそうだ。
何故だろう？