在软件开发中，死亡游行项目通常是指具有固定发布日期，固定功能和固定资源的项目，从而导致管理部门对开发人员加班和加班的疯狂要求。

我们认为死亡行军计划是什么，它是如何实现的？

解决方案

维基百科有一个很好的定义：

In the software development and software engineering industries, a death march is a dysphemism for a project that is destined to fail. Usually it is a result of unrealistic or overly optimistic expectations in scheduling, feature scope, or both, and often includes lack of appropriate documentation, or any sort of relevant training. The knowledge of the doomed nature of the project weighs heavily on the psyche of its participants, as if they are helplessly watching the team as it marches into the sea. Often, the death march will involve desperate attempts to right the course of the project by asking team members to work especially grueling hours, weekends (sometimes with a straight face), or by attempting to "throw (enough) bodies at the problem" with varying 
  results, often causing burnout.
  
  alt text http://www.weyrich.com/bookcovers/death_march.gif
  
  The term "death march" in this context was discussed at length in Edward Yourdon's book Death March: The Complete Software Developer's Guide to Surviving 'Mission Impossible' Projects (ISBN 0130146595),

我认为，" Deathmarches"来自非技术人员，他们决定项目/功能的任意截止日期，而没有开发人员在估算方面的任何投入。这会造成不合理的截止日期，如果我们将这与客户的宽松要求结合在一起，则我们将成为一个死神。

通常是由于规划和沟通不畅造成的。

通常，这是由于企业致力于客户的功能和需求而他们认为系统/开发小组可以在x的时间内完成工作……而无需实际估算时间，甚至不超过他们收集的需求为客户服务！然后，因为这是一个赚钱的项目，系统高层同意了它，因为"对于公司整体而言"，它是一个好的收入创造者！我参加过大约4到5次死亡游行，通常持续一到两周。我的最后一次死亡游行持续约2个月，包括9-14个小时的工作日。 ：( 不好玩。

根据我有限的经验，我要说，死亡行军项目是任何导致开发人员长时间工作的疯狂项目。这些开发人员通常会在截止日期之前就筋疲力尽。

我已经看到了几种发生这种情况的方法：

• 对项目状态过于乐观。
• 项目外部的时间压力。
• 其他团队成员懈怠，导致几个开发人员承担了全部工作量。
• 我们可以想到的任何其他常规软件开发病理(不切实际的时间表，范围爬升，管理不善等)

我不得不说，第一对我来说是最好的指标，因为它通常是所有其他因素的原因。例如：过度乐观会导致对客户的索赔过大，愿意接受范围蔓延，懒惰等。

我还认为有必要指出，这并非总是由管理人员，设计团队或者未直接参与编程的任何其他方的过错引起的。程序员经常高估自己的能力，还可能编写有漏洞的代码，从而使项目陷入困境。

不幸的是，在某些咨询公司中，标准的操作程序也是由一些熟练的工程师来估算项目的实际工时，然后让经理HALVE在最终报价中赢得该项目的投标，从而确保了为团队带来痛苦的死亡行军。

死亡行军的另一个标志是，随着项目接近"最后期限"，越来越多的人跳船。

Deathmarch项目强调了让IT机构实现这一目标的不相关性。如果感觉时间表和预算胜过功能，技术选择或者业务价值之类的事情，那么IT管理就变得无关紧要了。 IT经理在那里只是为了监督程序员报告的成本中心。

如果该项目没有真正关注业务价值，它将苦苦挣扎，不得不取消该项目("退货"或者"再造")。

发生这种情况的唯一方法是IT管理(a)可能做出了有益的贡献，但没有被企业重视，或者(b)根本没有任何线索。

死亡游行意味着团队没有在建立有价值的东西，而是在建立适合成本和进度的东西。

当询问团队他们对项目的看法时，一个非常重要的指标是项目经理何时估计其完成了70％，业务分析师估计其完成了45-55％，而开发人员则说完成了5-10％。

那是一个警告标志。

我认为之所以能够实现这些目标，是因为规划和估算不佳，业务需求不合理，团队内爆，范围和功能随时间紧迫而变化，以及良好的旧习惯首先是一个愚蠢的想法。

我通常会说Deathmarch确实是系统性的失败……因此，创建Deadmarch的不仅仅是一件事，而是事件的融合。

我要说的是，除了一般不良的项目管理(不切实际的日程安排，管理不善的延误等)之外，Deathmarch项目经常涉及一项被视为某种"银弹"的新技术。通常会加之训练不善和缺乏了解。

但是，在所有情况下，很多团队都需要知道该项目注定要真正有资格获得" Deathmarch"头衔。