典型的なソフトウェア開発環境では、プロジェクトの終了はプロジェクトの終了を示します。
最後のステップはオプションですが、参加者にとって非常にやる気になります。:-)
これをスクラムと比較してください。スクラムはバックログのストーリーで実行されることを知っています。したがって、技術的には、すべての反復が特定のストーリーを閉じます。したがって、ここには2つの質問があります。
または、プロジェクト終了期間はT＆Mプロジェクトにはまったく適用されませんか？
回答:
複数の同時プロジェクトに取り組むグループの場合、プロジェクトクロージャはどのように適合しますか？
第一に、「複数の同時プロジェクト」は本当に悪い考えと見なされます。スクラムのポイントは、全力疾走することです。プロジェクトを切り替えて別のスプリントを開始することは破壊的です。一度に2つのプロジェクトを実行することはスプリントではありません。それは混乱です。
ただし、スクラムは非アジャイル（ウォーターフォール）メソッドと違いはありません。バックログがほぼゼロに減少しても、まだ完了です。アジャイルアプローチの代わりにウォーターフォールアプローチがあったかのように行われます。
バックログがゼロ以外の場合もありますが、顧客は喜んでこれ以上望んでいません。これで完了です。通常、ウォーターフォールよりも早く、安価に行われます（すべてを構築する必要があり、アイデアが役に立たないことも判明しました）。
複数のグループを含むプロジェクトの場合、この概念はどのように適用されますか？
複数のグループを持つ非スクラムプロジェクトと同じです。人々について何も変わりません。彼らはまだ良いパーティーが好きです。
または、プロジェクト終了期間はT＆Mプロジェクトにはまったく適用されませんか？
最後に、請求が作品の性質や式典について何かを変えるのはなぜですか？
私は通常、より構造化されたプロジェクト管理フレームワーク内でスクラムの練習のようなアジャイルな方法を見ます。これはまったく矛盾ではありません。アジャイルは配信のために機能し、その目標は適切なソフトウェアをより迅速に配信することです。開発者と利害関係者の間の相互作用に役立ちます。固定期間プログラムの一部として、またはオープンエンドの機能強化に使用できます。
そのため、PMがタイムライン、コスト、その他の依存関係を管理しているため、プロジェクト管理の残りの部分を従来の方法で管理できない理由はありません。完了時には、通常どおり閉鎖イベントがあります。
私は金融で働いており、時々新しい規制が発生したり、新しい取引所が現れたりして、それが具体的に設定された公開日があります。アジャイル手法を引き続き配信に使用していますが、より伝統的なプロジェクト管理フレームワーク内で、納期どおりに配信します。
ワークユニットの見積もりと利用可能な時間枠で達成可能なソリューションの選択は、私たちに良い開発者を与えるものです（私が言うべきことの1つ）。
スクラムでは、すべてのアジャイルテクニックと同様に、チームは一緒にいる間、プロジェクトは行き来する小さなものです。そのため、「プロジェクトクロージャ」の儀式はありません。プロジェクトではなく、別のワックスが減少します。バックログアイテムのフローは、一方から他方に徐々に移行します。チームはほとんど違いを知りません。
実際、チームは2つまたは3つの異なるプロジェクトに同時に取り組んでいる可能性があります。繰り返しますが、彼らはほとんど違いを知りません。バックログアイテムは各スプリントの開始時にチームに入り、チームがそれらを実装します。それらはすべて1つのプロジェクトに属している場合もあれば、複数のプロジェクトに均等に分割されている場合もあります。チームは気にしません。チームは、与えられたバックログアイテムを実装するだけです。
ビジネスでプロジェクトの優先度を変更する必要がある場合、プロジェクトへのバックログアイテムのフローを変更するだけです。
ここで説明しているもののいくつかは、外部トリガーを待つのではなく、ドキュメントやリリースなどが頻繁に発生することで、ほとんどのアジャイルプロセスに含まれます。もちろん、顧客のタイプやビジネスの種類に応じて、常にそうなるとは限りません。たとえば、外部エンティティが所有する大規模システムの単一部分を作成する場合、通常、プロセスを推進する日付があり、その日付は追加のハウスキーピングと、もちろんパーティーを実行するのに適切な時間です。また、顧客が社内の顧客であっても、ビジネスのマイルストーン/主要な成果物/その他が完了したことを認識し、プロジェクトの簿記/パーティーの終了を再度要求する場合があります。もしあなたの会社がリリース計画に携わっているなら、それはあなたに自然なブレークポイントを与えますが、そうしなくても、ビジネス主導の成功の手段を持つことは完全に適切です。つまり、プロジェクトはエンジニアリングプロセスの機能ではなくなる可能性がありますが、プロジェクトの一部となることは確かであり、プロジェクトを祝う/取引することは企業文化の一部であり、今後もそうであるはずです。