スケジュール: 2007年9月アーカイブ
結論からいえば、スケジュール延長が遅い時は、必ず少なくとも2週間は無駄になると覚悟したらいい。つまり、スケジュールを2週間延長しても、読者にとって何にもならないということだ。もしそれが読者への最良の提案でも、それを呑むな。スケジュールと資源の余裕（スラック）は、問題を増幅させるためではなく問題を解消するために、許容しなければならない。読者がもっと早くに延長すれば、こうした影響は軽減される。事実人びとは、おそらく予定日の2か月前ならばわずかな延期は気にもとめない。
「ワインバーグのシステム変革法」
テストの省略や後工程への遅延を許すな。工程周期の終りのほうへ押しやられたものはなんであれ、スケジュールのために犠牲にされる。
「ワインバーグのシステム変革法」
期限が十分先なら−−例えば半年か１年先なら−−だれも、目標の実現が不可能であると言う現実に立ち向かおうとはしない、ということである。
「デスマーチ」
プロジェクトはどうして一年も遅れるようになるのか？・・・一度に一日ずつ。
「人月の神話」
１日の遅れにもやっきにならなければならない。この程度の遅延こそが、まさに破局の要素なのだ。
「人月の神話」
マイルストーンの決定に関し、関係する規則は一つだけだ。それは、マイルストーンを具体的かつ明確で測定可能なイベントとして、ナイフの刃のような鋭さを持って定義しなければならないということである。
「人月の神話」
遅れているソフトウエアプロジェクトへの要員追加は更に遅らせるだけだ。
「人月の神話」
マイルストーンをヒットする可能性が6つのコンポーネントそれぞれについて90パーセントである場合、マイルストーンをヒットする可能性はトータルでは53パーセントでしかない。全てが90パーセント確実だったとしても、このように厳しい状況なのだ。木を見て森を見ずという諺を思い出そう。
「ソフトウェア開発のダイナミズム」
遅れた後は、何がなんでも次のマイルストーンをヒットしろ。
「ソフトウェア開発のダイナミズム」
絶対やっては行けない最悪の愚行は、現在の遅れの日数を見積もり、その日数をスケジュールの終わりに加算することだ。あなたが確信すべき事は随一、この問題をもう一度徹底的に考えてみる必要がある、という事実だけだ。
「ソフトウェア開発のダイナミズム」
遅れは問題ではない。遅れに慌てふためくことが問題なのだ。
「ソフトウェア開発のダイナミズム」
遅れを利用して効率的な対応を促進しよう。遅れそうだという意識が人の目を覚まし、チームは新しい洞察力、フレッシュな情報、もう一つの見方、以前には想像すらしなかった可能性を模索しようとする。
「ソフトウェア開発のダイナミズム」
遅れはモラルの問題ではない。後れは失敗でもなければ非難されるべき事でもない。知的資産を作る作業における避けがたい結末なのだ。
「ソフトウェア開発のダイナミズム」
結局はそれほどの根拠がないはずの最終期限を守りたいがために、チームメンバーが製品をだめにしてしまうのを見逃してはならない。
「デバッギング ザ デベロップメント プロセス」
切迫感ていうのは終わりのほうで痛切になるのに、始めはあまりピンとこない。失った時間の価値は捉えようがない。プロジェクトのメンバーやマネージャーは、問題があっても何日も何週間も平気で寝かせておく。ところが、プロジェクトの初期に稼いだ1週間は、いよいよ駆け込みでおたおたしている大詰めの1週間と同じだけ大切である。
「デマルコ 大いに語る」
品質とスケジュール目標のトレードオフが出来ないと感じると、管理者は人々の交流の質を犠牲にしたいという気になりがちだが、そうすればすぐに品質とスケジュールの両方に代償を支払わなければならない羽目になる。
「ワインバーグのシステム行動法」
他の全ての原因よりもカレンダー時間の切迫が､ソフトウエアプロジェクトにその失敗の現実を直視させる。
「ワインバーグのシステム思考法」
おそるべき推察：無茶なスケジュールを達成するように決められたプロジェクトは、妥当なスケジュールで開始されたプロジェクトに比べ、完成までに時間がかかると思われる。
「デッドライン」
一日を無駄にする方法はいくらでもある…・しかし、一日を取り戻す方法は一つもない。
「デッドライン」
プロジェクトの初期に無駄にする一日も、末期に無駄にする一日も等しく打撃になる。
「デッドライン」
うまく進行するプロジェクトにおいては、20ないし30%の時間が計画立案、要求仕様、アーキテクチャ設計にかけられている。
「コードコンプリート」
スケジュールが遅れることそのものより悪いのはただ1つ、スケジュールが送れているということ自体に気がつかないことである。
「ラピッド デベロップメント」
普通以上の残業を当てにしてはならない。それらはこれまでうまく働かなかったし、この先も同じであろう。普通以上の残業を当てにしたスケジュールを計画すると、開発者はスケジュールが送れた場合に、残業をしても追いつくことができなくなる。
「ラピッド デベロップメント」
楽観的過ぎるスケジュールは、少しの遅延では終わらない。平均的な小さなプロジェクトの見積もりでは、100%以上の遅延になる。平均的な大きいプロジェクトでは、1年の遅れになる。
「ラピッド デベロップメント」
ほとんどの研究者の間では、0.75または0.80以下のスケジュール圧縮率を実現するのは不可能であると意見が一致している。
「ラピッド デベロップメント」
実際の最短スケジュールは、最も正確な計画されたスケジュールから生まれる。
「ラピッド デベロップメント」
1991年に300を超えるプロジェクトを調査した結果によると、スケジュールの遅れを取り戻せたプロジェクトは殆どなく、その後更に遅れが拡大する場合が多い。
「ソフトウェア プロジェクト サバイバル ガイド」
スケジュールの遅れというリスクを最小限に抑えるには、計画に残業時間を組み込まず、プロジェクトの開始時に人的、物的資源を確保しておくべきである。
「ソフトウェア プロジェクト サバイバル ガイド」
不可能な目標によって意欲をかき立てられる人もいる。しかし、開発者は自らが現実的であることを誇りにしているので、手の届かない目標はかえって意欲を失ってしまう傾向がある。
「ソフトウェア プロジェクト サバイバル ガイド」
プロジェクトの初期段階には、予算とスケジュールを厳密に設定するか一連の機能を厳密に設定することはできるが、同時に両方を厳密に設定することは無理である。
「ソフトウェア プロジェクト サバイバル ガイド」
成功するプロジェクトチームでは、上流の問題は上流で修正できるような手段を講じている。その手段とは要件とアーキテクチャを徹底的に注意深く見直すことである。
「ソフトウェア プロジェクト サバイバル ガイド」
プロジェクトの最初の段階で工程に時間と労力を傾注しておけば、プロジェクトの後半に大きなメリットとなって戻ってくる。
「ソフトウェア プロジェクト サバイバル ガイド」
