スケジュールの最近のブログ記事

結論からいえば、スケジュール延長が遅い時は、必ず少なくとも2週間は無駄になると覚悟したらいい。つまり、スケジュールを2週間延長しても、読者にとって何にもならないということだ。もしそれが読者への最良の提案でも、それを呑むな。スケジュールと資源の余裕（スラック）は、問題を増幅させるためではなく問題を解消するために、許容しなければならない。読者がもっと早くに延長すれば、こうした影響は軽減される。事実人びとは、おそらく予定日の2か月前ならばわずかな延期は気にもとめない。

「ワインバーグのシステム変革法」

テストの省略や後工程への遅延を許すな。工程周期の終りのほうへ押しやられたものはなんであれ、スケジュールのために犠牲にされる。

「ワインバーグのシステム変革法」

期限が十分先なら－－例えば半年か１年先なら－－だれも、目標の実現が不可能であると言う現実に立ち向かおうとはしない、ということである。

「デスマーチ」

プロジェクトはどうして一年も遅れるようになるのか？・・・一度に一日ずつ。

「人月の神話」

１日の遅れにもやっきにならなければならない。この程度の遅延こそが、まさに破局の要素なのだ。

「人月の神話」

マイルストーンの決定に関し、関係する規則は一つだけだ。それは、マイルストーンを具体的かつ明確で測定可能なイベントとして、ナイフの刃のような鋭さを持って定義しなければならないということである。

「人月の神話」

遅れているソフトウエアプロジェクトへの要員追加は更に遅らせるだけだ。

「人月の神話」

マイルストーンをヒットする可能性が6つのコンポーネントそれぞれについて90パーセントである場合、マイルストーンをヒットする可能性はトータルでは53パーセントでしかない。全てが90パーセント確実だったとしても、このように厳しい状況なのだ。木を見て森を見ずという諺を思い出そう。

「ソフトウェア開発のダイナミズム」

遅れた後は、何がなんでも次のマイルストーンをヒットしろ。

「ソフトウェア開発のダイナミズム」

絶対やっては行けない最悪の愚行は、現在の遅れの日数を見積もり、その日数をスケジュールの終わりに加算することだ。あなたが確信すべき事は随一、この問題をもう一度徹底的に考えてみる必要がある、という事実だけだ。

「ソフトウェア開発のダイナミズム」