「ウォーターフォール」よりも現代の柔軟な（アジャイル）方法論に固有の、開発プロセスの現代的な組織の原則を考慮してください。
おそらくこれは批判にある程度重点を置くが、それに焦点を合わせないでください。 むしろ、これは比較レビューです。各アプローチには長所と短所があります。
この投稿は、以前の出版物（ パート1 、 パート2 ）の続きです。
プロジェクト管理における権限の配分と、アナリスト、プロジェクトマネージャー、アーキテクト、開発者などの役割の開発プロセスについていくつかの質問があります。
開発した製品の品質を確保するというタスクに関して、私が共有したい点をいくつか紹介します。
1.アナリストはそれぞれの用語でドメインモデルを作成し、開発者は独自に（特定のプログラミングパラダイムで）プログラムします。
誰かが最初と2番目の間に「橋を架ける」ことが必要です。
これらの人々は建築家であり、少なくとも3種類の建築家が必要です。
- システムアーキテクト全体（システムアーキテクト、システムアーキテクト）。
- ソフトウェアアーキテクト（ソフトウェアアーキテクト、ソフトウェアアーキテクト）;
- データベースアーキテクト（DBアーキテクト）。
このリンクが省略された場合の動作については、 パート1の段落1をご覧ください。
2.「ウォーターフォール」の時点で、アナリスト、プロジェクトマネージャー、アーキテクトは、ラインスペシャリストと専門部門の長から成長し、最高はタスクマネージャーになりました。
しかし-これは非常に重要です-これらの人々はすべて専門のスペシャリストとマネージャー、すなわち 実際の仕事に従事し、それが何で構成されているかを知っていました。
たとえば、部門長（またはチーフエンジニア）は、プロジェクトマネージャー（現代PMのようなプロジェクトではなく、プロジェクト）のポジションを同時に保持できます。
3.柔軟な（アジャイル）テクノロジーの支配の現在の時代では、これはそれらに直接関連していませんが、このアプローチが優勢です：
- アナリストは開発者になれなかった人ですが、アナリストも勉強していません（そして今どこで彼らに教えていますか？-彼らはおそらく学習していますが、プロセスは始まったばかりで、現在のアプローチはすでに10-15年前後です）。
- 開発者にはそれぞれ「安価なコーダー」の役割が割り当てられており、彼らはその質によって分析を行うことができないか、許可されていません。
- そして、ここで上記のアーキテクトが必要です。 アーキテクトは最初と2番目を組み合わせる必要があります。 自分の役割と選択したスタッフの質に応じて、自分でこれを行うことはできません。
4.それで、最も興味深いのは、これらの建築家はどこにいるのでしょうか？
知識のある人々が説明しているように、支配的な開発モデルは、より安価な開発プロセスに基づいて選択されるため、安価な分析と安価なエンコーダが使用されます。
「親愛なる建築家」はこのモデルには適合しません。 その考え自体は正しいです。役割（分析者-設計者-コーダー）の明確な分離を使用して、より良い開発プロセスとより良い結果を得ます。
主要な高価なリンクを捨てなければ、得られます。
通常、このリンクは（結局、問題の最初の声明はプロセスのコストを削減することです）、結果は対応するものではありません。
私の観察と推定によると、この場合、カスタム（ボックス化されていない）開発の場合、プロジェクトの平均ライフサイクルは3年です。