厳しいスケジュールとスケジュールのプレッシャーはTCOと納期にどのように影響しますか？

ソフトウェアエンジニアリングマネージャーである友人の父親は、「オーバーランのスケジューリングの最大の原因はスケジューリングのプレッシャーである」と強調しました。

研究はどこに立っていますか？適度な量のスケジューリングのプレッシャーが爽快ですか、それとも私が述べたマネージャーは正しいか間違っていますか、それとも「スケジューリングのプレッシャーが大きいほど、納期が長くなり、TCOが増えるのか」という問題ですか。それは、理想的にはソフトウェアエンジニアリングがスケジュールの圧力なしで機能するものの1つですか？

ソフトウェア工学の文献へのリンクがあれば幸いです。

オーバーランをスケジュールする最大の原因は、スケジュールのプレッシャーです。

同意しません。オーバーランのスケジューリングの最大の原因は、現実を反映していない、過度に楽観的なスケジュールです。人間の性質上、ある程度のスケジューリング圧力は絶対に必要です。スケジューリングのプレッシャーを少しもかけずに発生する問題のほんの一部は興味深い問題であり、「最良のものは十分なものの敵です」。私たち技術者は、製品を世に出すために解決する必要がある問題ではなく、私たちが関心を持っている問題に取り組むことをはるかに好みます。締め切りをなくし（スケジュールのプレッシャーとも呼ばれます）、興味深い問題に取り組み、製品に悪影響を与えます。

別の問題は、製品が「十分に良好」である必要があることです。完璧である必要はありません。エンジニアや科学者は、一部の特殊な状況ではあまり有効ではない単純化された仮定を理解しています。グラフィックデザイナーは、他の人には見えないエイリアシングの問題を目にしています。プログラマーは、製品の動作に影響を及ぼさないイボをアーキテクチャに見ています。「最高のものは、十分な善の敵である」ということです。これは、実際には問題ではない問題と一緒に生きなければならないことを意味します。

スケジュールのプレッシャーがないと、製品の所有コストが非常に高くなります。オーバーランの原因は悪いスケジュールです。これにはさまざまな形式があります。必要な作業を過小評価し、依存関係を説明できず、すでに遅れているプロジェクトに人々を追加する。ほんの数例を挙げると。

時間、品質、リソース、機能の数はすべて関連しています。それらの3つを修正して、最後の1つをスケジューリングプロセスの出力として取得できます。

質問が定式化される方法は、時間があなたの変数であり、他の3つ（品質、リソース、および機能の数）がすべて固定されていることを意味します。質問は、時間を修正して^*視点を少し変更し、品質を変動させることでメリットが得られる場合があります。

あなたの質問はこれになります：「タイミングの制約は品質に悪影響を及ぼしますか？この質問への答えははっきりと「はい」です：研究により、人々は数学関連の問題へのプレッシャーの下で悪化することを確認しています^**彼らはこれまで広範囲に実践したことがない（つまり、50回以上試みた）ので、あなたの友人の父親は正しいです。

^**ここで、プログラミングは数学を行うのと似ているという暗黙の仮定があります。この仮定は公正だと思います。

スケジュールのプレッシャーが大きいほど、納期が長くなり、TCOが増加しますか？

まあ、テクニカルリードと話し合わずにマネージャーがスケジュールを立てる場合は、その傾向があります。事実に基づいていないスケジューリングまたは見積もりが失敗する傾向があることは非常に明白な真実です。

さらに、エビデンスに基づくスケジューリングを回避するマネージャーも、プロジェクトの次の失敗に向けて動いています。このトピックについては多くの研究があり、測定基準に基づくスケジューリングが正しい方法です。

右から左のスケジューリング。

管理職の誰かは、彼が有名なリアリティ歪みゾーンを持つスティーブジョブズだといつも思っています。製品開発の担当者が教育するまでは、技術者以外の管理者は、フランスの初期の映画「ルヴォヤージュダンラルーネ」（「月への旅」）がロケットサイエンス向けだったのと同じくらい洗練されたスケジュールについての見方をすることがよくあります。

問題はしばらく前からありました。Fred BrooksがMythical Man-Monthでのガットレス推定について語っています。バリーベーム氏は、管理に対する理論Wアプローチの提案でそれについて語っています。最近では、Steve McConnell（Code Completeの作者）が、「不人気なスケジュールを守る方法」で、原則的な交渉問題の概念に焦点を当てています。

アジャイルは、プロジェクトの範囲を目立つ場所に押しやります。アジャイルマニフェストは「契約交渉を超える顧客のコラボレーション」を求めています。また、説明責任を負う人々に力を与えることを願っています。計画ゲームは、要件や新しい発見の変化によってオーバーランされている、彼らはずっと前に作られた約束に開発者を強制する非技術的な利害関係者を避けることができます。

組織がアジャイルを拒否する場合、達成額に基づいてスケジュールを再ベースライン化するための見積もりの​​調整に関連する優れた方法があります。稼得価値は予測に関する実際の問題のいくつかではうまく機能しないと思いますが、それはプロジェクトの速度に関する妄想と、何らかの形で事実であると私たちが持っている見積りの反発を払拭するのに役立ちます。

コードを書き始めるのが早いほど、時間がかかるという言い方があります。スケジュールの圧力は、方法論の変更を強制する効果をもたらす可能性があります。時々、それは滝から「地獄のようなコード」までです。これは品質に悪影響を与える可能性があります。労働者が最善を尽くすことができず、同僚や将来のメンテナーが最悪ではなく最悪でそれらを見ているときの士気は言うまでもありません。このような環境では、ある程度の混乱は、ソース管理、毎日のビルドとテスト（または継続的な統合と単体テスト）、コードレビュー、経験豊富で高度なスキルを持つチームを使用して制御でき、スタッフを後から追加する誘惑に抵抗します。プロジェクト、および古いスタンバイ、残業。

また、方法論の変更がウォーターフォールから反復的な増分に変わる場合もあります。私の経験では、経営陣はアジャイルを受け入れるのに時間がかかりました。しかし、しばらくしてから、アジャイルをより支持する新しい管理がありました。タイムボクシングは予算編成のようなものです。限られたリソースの最適な使用について考えることを私たちに強いることがあります。 スクラムには2つのタイムボックスがあります。1つはチームメンバー間のフィードバック用に毎日、もう1つはバーンダウンリストを介してスプリント用に毎月です。

クリエイティブコモンズライセンス-http://en.wikipedia.org/wiki/File:Scrum_process.svgを参照

ソフトウェア工学の文献は必要ありません。学部生からの概念的な確率と統計だけで十分です。

見積もりはそれだけの見積もりです。正確ではなく、保証されていません。どんな見積もりでも、あなたはそれをアンダーランしたり、鼻にぶつけたりする可能性と、オーバーランする可能性があります。

確率101：p（アンダーランまたは正確にヒット）+ p（オーバーラン）= 100％。

見積もりに基づくスケジュールは、まったく同じ特性を持っています。

不確実性を完全に取り除くことはできません。常にオーバーランの可能性があります。それは小さいかもしれませんが、イランがあなたのオフィスビルを破壊する可能性はありますが、それはまだそこにあります。最善の方法は、すべてを見て、不確実性をできる限り減らすことです。一度これを実行すると、運が良ければ、不確実性が小さく、各側で50％の確率でスケジュールが立てられます。

考えてみてください。スケジュールを引き込むと、スケジュールを下回る、または正確にヒットする可能性が低くなります。合計はまだ100％になる必要があります。その確率はどこに行きますか？回答、それはオーバーラン確率に入ります。

General Dynamics / Fort Worth Divisionはこれを難しい方法で学びました。彼らはF-16C / D開発の最初の見積もりを行い、それをフードチェーンに送りました。誰かが勝手に一年を切り捨てて空軍に送った。直接的な結果として、GD / FWは飛行試験に1年遅れ、空軍は満足していませんでした。（「1年遅れ」は、改訂されたスケジュールに従っていたことに注意してください。つまり、元のスケジュールはRIGHT ON TARGETでした。）

集中力を維持するのに役立つので、プロジェクトのある程度のプレッシャーは問題ないと思います。

ただし、プレッシャーが現実的でない場合、または経営陣と技術担当者間のコミュニケーションが適切に機能しない場合、はい、プレッシャーをスケジュールすると品質が低下したり、配信が遅れたりするリスクがあります。

経験豊富な開発者は、彼/彼女が完璧なソリューションではなく、十分に優れたソリューションを生み出すことが期待されていることを知っています。そのため、そのような開発者によって与えられた見積もりは、特定のプロジェクトにとって何が十分であるかについての彼らの理解をすでに反映しています。

十分に良いの定義に影響を与える多くの要因があります。

たとえば、プロジェクトは何ヶ月続きますか？プロジェクトが1年間続く場合は、プロジェクトの最初にその特に難しいモジュールのプロトタイプをすばやく作成できます。その後、数か月間、他のより日常的なモジュールの開発の副活動としてテストおよびデバッグすることができます。（そのモジュールが十分に良好になるまで数か月以上熟成させることができるので、最初からそれを正しく試す必要はありません。）私はこの戦略を非常に効果的だと思いますが、あなたを信頼し、あなたに任せるマネージャーが必要ですプロジェクトを数か月間開いたままにします。別の（信頼できない）マネージャーが、できるだけ早くそのモジュールを完了するように要求する場合があります（後で修正する必要があるかどうか、およびこのアプローチが最終的に全体ではるかに多くの時間を要するかどうか）。

別の例：プロジェクトは、リリースが1つだけの製品用です。次に、それを迅速に実行し、広範なテストに依存して、製品が期待どおりに機能することを確認できます（迅速かつダーティで十分です）。一方、製品のリリースが2つまたは3つになる場合は、その後のリリース用にコードを大幅に書き直さないように、設計に時間をかけることをお勧めします。（この場合、3つのリリースの合計開発時間が長いため、迅速かつダーティでは不十分です。）

結論として、経営陣と技術者の間のコミュニケーションの悪さ、手元のプロジェクトにとって十分なものについての共通の理解の欠如は、過剰なスケジューリング圧力につながり、品質の低下/納期の遅れにつながると私は思います。

初めて正しく実行するのに十分な時間はありませんが、後で修正するのに常に十分な時間があります。