スケジュールを先に決めて、それに基づいて開発を行っていくスケジュール駆動開発の場合、
一般に炎上しやすくなると思う。
というのも、(一般論として)スケジュールは、みんな守ろうとする。
その場合、
・よく分からないけど、大事な部分
・よく分かっていて、簡単な部分
とあると、「よく分かっていて、簡単な部分」を先にやれば、その間はスケジュールを
守れるので、「よく分からないけど、大事な部分」を後回しにして、簡単な部分を先に
行う。これがGUIとかになる。
しかし、後回し(=先送り)にしたら、問題が解決するというケースは少なく(理解が
進んで問題が解決するケースも無いわけではないが、少ない)、多くは、その問題は残った
ままとなる。つまり、よく分からない、大事な部分は、スケジュールの後のほうに濃縮される。
これらはよく分からないので、計画通り行かない。それがいっぱいになれば、計画通り
行かないものが積み重なるのだから、スケジュールを守れない確率は、劇的に高くなる・・・
・・・のみならず、この時点では、簡単な部分は、すでにできている。
そこに、よく分からないけど、大事な部分をやったら、実は思い違いで、簡単な部分も
修正が入るとなると、その修正部分の工数が増加するので、スケジュールは守れなくなる。
ここで、スケジュールは破綻し、大事な部分の見込み違いが続くと、炎上する。
なので、スケジュール駆動にすると、(大事な部分を後回しにして、そこで問題起こすと
いままでやった部分の修正もしないといけなくなるので)炎上しやすくなる。