この短い記事では、プロジェクトの期限を遅らせる一般的な問題についての洞察を提供します。 それらのいくつかは、計画技術と開発技術の間のインターフェースにあります。 プロジェクトの途中以降、各ステップが特に完了に近づかないという事実に直面している場合-計画はまあまあだったことを知っています。 より具体的にはカットの下。
なぜ問題を探す必要があるのか
フレキシブルプランであるかウォーターフォールプランであるかは関係ありません。任意のプランであれば、機能が表示される順序を決定します（内部または中期であっても）。 実際の用語は、1人あたりの機能の量だけでなく、製品の品質（コードでなくても）の関数であり、この場合は制限されますが、量は単調に増加し、品質は単調です。 少なくともhello world、少なくとも検索エンジンを作成します-もちろん品質ですが、機能は無制限に追加および変更できます。
ボリュームと品質を修正する際に、実際の条件が変更される理由はそのままです。「内部キッチン」のみが、どの順序で実行されます。 当然、これはすべて週40時間以内の一部の抽象的なプログラマー向けです。
今、現実に深く入ります。
問題点と対処方法
合成の複雑さに対する分析の曲率
タスクへの不正確な分割は、結果へのその後の統合の困難につながります。 間違った分割とはどういう意味ですか？ これは、実行されたすべてのタスクが最終製品を形成しないパーティションであり、最後に統合タスクが表示されます。 中間の詳細を知らずに彼女の用語を予測することは不可能です。 しかし、彼女はそうであり、彼女はされなければなりません。
道徳 -プロジェクトの終わりに統合リスクを先送りしないでください。 たとえば、APIがある場合は、適切な開発ツール（モックサービス（スタブ、テストデータなど）など）を使用します。
オーバープラン=>残業
計画はシステムより複雑であってはなりません 。 システムはそれに従って実装することはできません 。 これは、あるシステムを別のシステムに「理解」（反映）するために、最初のシステムはそれほど複雑ではなく、この場合、製品は計画よりも複雑でなければならないという事実に基づいています。 それ以外の場合、計画は実装されません。つまり、（計画に従う場合）計画は製品を実装しません（TKなど）。
道徳 -計画を詳述することの十分性の基準は、その用語の広がりの尺度です。 許容レベルを下回っている場合、計画を実行できます。
計画中の研究開発
プロジェクト計画の一部としての研究は損失への直接の道です。 プロジェクトの損失に。 さらに、調査は「私たちは半分を行い、そこに見えるようにする」タイプ、または「プロジェクトにフレームワークの選択を置く」タイプにすることができます。 イベントと決定のツリーの方法に従ってプロジェクトを評価しない場合、このプロジェクトは期限に間に合わない可能性が非常に高くなります。 研究は「適切なフレームワークがないため、自分でやらなければならない」などの解決策を提供できるためです。
道徳 -その結果が合理的に正確に推定できないすべてのものは、プロジェクト計画に含まれてはならず、その条件は支払いの対象となります。
（3）ポイントではないスコア
1つのポイント（日付）で間違いを犯す可能性はどれくらいで、どれがインターバル（日付）にありますか？ 当然、ポイントは光線（左）として理解されますが、それでもカテゴリの「恐竜に出会う」可能性があります：ポイントの前または後（50％の確率は、適用された場合の情報不足です）。 これに基づいて、間隔プロジェクト期間は特定の日付よりも常に正確であり、リスクが少なくなります。 もちろん、誰も契約の間隔を書きません。そこで自信のために右端を書くことができます。 すべてを一度に（係数を持つ3つのポイントの平均ではなく）最大まで評価した場合、競争市場での非効率性は避けられません。
道徳-1つの評価（タスク）を信じるよりも、異なる評価を1つに比較検討する方がよい。
ホイールまたはタスクヘッドゴリニッチのリス
以前の依存関係が完全に作成されなかった場合、各タスクについて、いくつかの新しいタスクが追加されます。 私のトレーナーはかつて言った
あなたのすべては数回アンダーショットされ、トレーニングで3回アンダーショットされました-これらは最初の場所からミリ秒と秒です！
各タスクが最後まで完了していないことを想像してください。次の依存タスクを完了するには、2つを完了する必要があります。
道徳 -マイクロサービスは発明されたが無駄ではなかった。 これは、開発を含むリスクの分離です。 また、プロジェクトの並列処理を最適化するためにタスクを分割しても、プロジェクトの速度が必ずしも向上しない場合があります（タスクを完全に完了する必要がある場合）。
理想的な計画の結論
各ストーリーのすべての道徳を要約すると、理想的な計画はほとんど矛盾しています。
- 計画は、部分から全体ではなく、小から大へと有機的に成長します。
- 計画は、その計画に実装されているものよりも単純でなければなりません（そうでなければ、計画は実現不可能です）。
- 1つのプロジェクトに関して（シリーズについては説明していません）、致命的なイベントは発生しません。
- 間隔評価は、定義によって単純に信頼性を高めます
- 計画に借金はないはずです。将来使用されるものはすべて実行可能でなければなりません。
それは柔軟な技術のマニフェストのようなものに似ています...しかし、滝もそれに異質ではありません。 柔軟なアプローチで計画する方が簡単なポイントもあれば、ウォーターフォールでポイントするポイントもあります。 いずれにせよ、このトピックは、その中の考慮事項とポイントと同様に、戒めではなく、考慮のための情報です。 実際、計画にはそのような微妙さがありますが、製品や特定のプロセスに関してはよりプライベートです。
すべての成功したプロジェクト。