前のトピックが非常に活発な議論を引き起こし、200人を超える人々がそのトピックをお気に入りに追加したことを考えると、プロジェクトの期限を満たすツールと方法の議論を続けましょう。 今回の次の一連の推奨事項は次のようになります。
- 締め切りが本当に厳しいことを確認してください
- 非現実的な期限にプロジェクトを引き受けないでください
- 「クリーピングウェーブ」法を使用した計画
- プロジェクト評価を定期的に確認する
- プロジェクトを経験的に評価する
- 初期評価にチームを参加させる
締め切りが本当に厳しいことを確認してください
多くの「超緊急」プロジェクトの最も驚くべき瞬間は、期限があまり厳しくないことです。 その結果、チームへのプレッシャー、機能性の犠牲、そして最悪の場合には品質がもたらされます。 チームまたはプロジェクトマネージャーは、期限が客観的であることを確認する必要があります。たとえば、影響を受けることのない製品を発表するイベントの日付です。 締め切りが厳しくない例としては、詳細な分析を行わずにプロジェクトの条件を早期に見積もる場合があります。これは経営者によって表明されます。期限を変更するためには、レビューが必要です。
非現実的な期限にプロジェクトを引き受けないでください
別のアンチパターンは、チームが非現実的な期限でプロジェクトを実施するというコミットメントであり、多くの場合、これはプロジェクトの開始前に明確になります。 問題は、チームがプロジェクトのそのような強制的なテイクを「上から」の順序と見なし、期限の責任が正式なままであることです。 プロジェクトが正常に完了しなかった場合、チームは「期限に間に合わせることができないことを事前に警告しました」と言います。 通常、このタイプのプロジェクトに最適なソリューションは、最初のリリースで販売される機能の量を大幅に削減することです。
「クリーピングウェーブ」法を使用した計画
大規模プロジェクトでは、有能で実際の作業計画を立てることが非常に重要です。 Michael Wolfが計画を立てた地図を例に取りましょう。 実際、全体的に同じ規模であり、このため、プロジェクトの最初から問題が始まりました。 この場合の正しい方法は、ローリングウェーブプランニングです。最初のセクションでは、より詳細なプランを作成し、より大きな縮尺のマップを使用して、そのエリアの写真と後で説明するセクションを確認します。縮尺の小さい地図で検討してください。
PMBoKのフレームワーク内のプロジェクトアクティビティの場合、このアプローチは、プロジェクトの最初の段階でのJISでの作業のより詳細な分解を意味します。 柔軟な方法論では、同じアプローチを使用します。重要度の高いバックログ要素を小さな「ピース」に分割して保存し、重要度の低いバックログ要素を大きなエピックの形で保存します。 つまり チームには、1つまたは2つのスプリントの詳細なバックログがあります。
一方、プロジェクトのすべての機能をペイントしていないという事実により、要件（デザインレイアウトなど）のかなりの部分が単に「悪くなる」という事実は言うまでもなく、Big Upfront Designのアプローチと開発の開始を長時間避けることができます番です。
プロジェクト評価を定期的に確認する
ウォーターフォールアプローチを使用する場合、作業の各段階の終わりに完了日の推定値を修正する必要があり、クリティカルチェーン方式を使用する場合、プロジェクトバッファーを使用してそのような評価をより迅速に行うことができます。 反復方法論では、次の反復の終わりにそのような再評価が推奨されます。
実際、プロジェクトの初期段階で行われた推定には、通常、非常に多くの不確実性が含まれています。 時間が経つにつれて、この不確実性が明確になり（一部のリスクが除去され）、評価をより正確にすることができます。 上記の古典的な例は、「不確実性の円錐」です。
プロジェクトを経験的に評価する
チームの速度に基づく評価は非常に正確であるため、可能な限りすべてのプロジェクトで使用する必要があります。 いくつかのスプリントを実行し、チームがどの程度の機能（ストーリーポイントなど）を行うかを決定し、プロジェクトの合計完了時間を計算します。 このような事実に基づいた計画により、かなり正確な見積もりが可能になります。
初期評価にチームを参加させる
多くの場合、非常に早い段階でプロジェクトを評価する必要があります。 前述のように、このような評価
参照資料
ソフトウェア開発の複雑さを評価する際の10の大罪