私はJava の世界でデス マーチプロジェクトに取り組んできました。このプロジェクトは、通常、複数のシステムにまたがり、ウォーターフォール アプローチに結び付けられていることが多く、管理が不十分で扱いにくく複雑なテクノロジが組み合わさったために、最初から失敗する運命にあります。
Rails と Django は、アジャイル開発テクノロジとしてもてはやされています。つまり、変化に迅速に対応できることを重視しています。
これは、大規模なエンタープライズ システムのデス マーチ シナリオの影響を受けないということですか? それとも、Rails/Django プロジェクトには、Java プロジェクトのように制御不能になるほどの複雑さの余地がまだあるのでしょうか?
デスマーチは、あなたがどの言語を使っていても起こり得る、悪い管理と計画の機能です.
もちろん。私は、死の行進となったいくつかの Django プロジェクトに取り組んだ個人的な経験があります。
世界中のすべてのアジャイル開発テクノロジを利用できますが、会社がアジャイルの概念を完全に取り入れていなければ、デス マーチを回避することはできません。経営陣が特定の日付に製品を納品し、特定の機能セットが含まれていることを要求する場合、フレームワークを使用しても役に立ちません。満足するまで、できるだけ速く作業する必要があります。それが死の行進を意味するなら、それは死の行進です。
問われているように思えるのは、テクノロジーが人間の愚かさを解決できるかどうかということです...
まあ、私の知る限り、まだ治療法はありません。
正直なところ、開発プロセスを容易にするはずのフレームワークの便利さがあっても、管理が不十分な場合は失敗する可能性があります。フレームワークを適切に使用することの問題であるため、彼らは確かに死の行進シナリオの影響を受けません。使用されたテクノロジーが意図したとおりに使用されなかったために、多くのプロジェクトが失敗するのを見てきました。
リンク先のページから:
「...スケジュール、機能範囲、またはその両方における非現実的または過度に楽観的な期待の結果であり、多くの場合、適切なドキュメントの欠如、またはあらゆる種類の関連トレーニングが含まれます...多くの場合、デスマーチはコースを正すための必死の試みを伴います.チームメンバーに特に過酷な時間帯や週末に働くように依頼したり、「問題に(十分な)体を投げつけたり」しようとしたりして、プロジェクトの
私には、いくつかの方法論は死の行進になりやすいように思えます (あなたが言ったように、ウォーターフォールが思い浮かびます)。
なぜ使用されるテクノロジーは、管理がいかに貧弱であるかと関係があるのでしょうか？これは、私には、真剣にばかげた質問のように思えます。テクノロジーが不十分な管理を解決しようとしていると思われる場合は、使用するテクノロジーを選択する前に、他の問題に取り組む必要があります。