レベルエンター山本大のブログ

面白いプログラミング教育を若い人たちに

BLOCKVROCKリファレンス目次はこちら

下見イテレーション開発

先述の通り、ウォーターフォールの利点として見積のしやすさだと思う。
「見積」とは、プロジェクトに対する将来の予測や予言ではなく、プロジェクトを進めるための「計画」に他ならない。

私が「計画」という言葉から連想するのは、「旅行」だ。

旅行を例にとって、次の開発プロセスを模索してみよう。
旅先で何が起こるかがはっきりわかっているというサプライズのない旅行は、現実世界の旅行としては面白味に欠ける旅だが、プロジェクトにとっては非常にありがたいものである。

現実世界の旅行で、そのような安全な旅をするためにどうしたらいいだろうか?
例えば、予め同様のルートで下見をしたチームが「水先案内人」となって後続の大きなチームを率いていくことではどうだろうか。

つまり「繰り返し」ではなく「下見」である。

小規模の先行チーム(開発・顧客含む)が、先に1つの完成形を構築する。

プロジェクトとはその定義からして「独自性」の高いもの(PMBOKによる)だから、顧客側、開発側の双方が、予めどこにどのような危険があるのかを知るためには、やはり進んでみるしかないように思う。

【デメリット】
・期間の制約が大きいプロジェクトには向かない。
・複雑な仕様によるリスクらが下見段階では見つけられない。