死亡三月项目的特点

Question

在软件开发中，死亡游行项目通常是指具有固定发布日期且具有固定功能和固定资源的项目 - 导致管理层疯狂地要求开发人员长时间工作和周末工作。

您认为死亡游行项目是什么以及它是如何产生的？

Answer 1

Wikipedia有很好的定义：

  

在软件开发和软件工程行业中，死亡游行对于注定要失败的项目来说是一种愚蠢的行为。通常，这是由于在计划，特征范围或两者中存在不切实际或过于乐观的期望，并且通常包括缺乏适当的文档或任何类型的相关培训。对项目注定性质的了解在很大程度上影响了参与者的心理，好像他们无助地看着团队进入大海。通常情况下，死亡游行将涉及通过要求团队成员特别艰苦工作，周末（有时是直面），或试图“抛出（足够）尸体解决问题”的绝望尝试来纠正项目进程。不同   结果，经常导致倦怠。

     

     

在此背景下，“死亡游行”一词在Edward Yourdon的书Death March: The Complete Software Developer's Guide to Surviving 'Mission Impossible' Projects（ISBN 0130146595）中进行了详细讨论，

我认为“Deathmarches”是由非技术人员决定项目/功能的任意截止日期而没有开发人员在估算方面的任何输入。这会产生不合理的最后期限，如果你将这种情况与客户的宽松要求结合在一起，那么你就拥有了死亡之旅。

Answer 2

当询问团队他们认为该项目有多远时，一个非常重要的指标是，当项目经理估计其完成70％时，业务分析师猜测其完成了45-55％，开发商称其为5-10％完成。

那是一个警示标志。

我认为他们可以因为计划不周而出现。估计，业务的不合理要求，团队内爆，范围和特征在紧缩的最后期限内蔓延，以及好的旧的首先是一个愚蠢的想法。

Answer 3

从我有限的经验来看，我会说死亡游行项目是导致开发人员在很长一段时间内工作疯狂的任何项目。这些开发人员通常会在截止日期前烧坏。

我已经看到了这些情况的几种出现方式：

1. 对项目状态的过度乐观。
2. 项目外部的时间压力。
3. 其他团队成员懈怠，导致一些开发人员承担所有工作量。
4. 您可以想到的任何其他一般软件开发病理学（不切实际的时间表，范围蔓延，糟糕的管理等）。

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

我还认为值得注意的是，这并不总是管理层，设计团队或任何其他不直接参与编程的方面的错误。程序员经常高估自己的能力，也可以编写错误的代码来设置项目。

Answer 4

死亡之旅的另一个标志是随着项目接近“截止日期”，越来越多的人跳船。

Answer 5

我通常会说，死亡之旅实际上是一个系统性的失败......所以这不仅仅是造成死亡之旅的一件事，而是事件的汇合。

我想说，除了一般糟糕的项目管理（不切实际的调度，管理不善等等）之外，Deathmarch项目通常涉及一种被视为某种“银弹”的新技术。经常伴随着训练不足和缺乏理解。

但在所有情况下，大量团队需要知道该项目注定要真正有资格获得“Deathmarch”这个标题。

Answer 6

通常它来自业务提交到客​​户端功能和要求，他们认为系统/开发组可以在x个时间内完成...而不是实际要求估计时间，甚至超过他们为客户收集的要求！然后因为这是一个赚钱的项目，系统高层同意它，因为“对整个公司而言”是一个很好的收入来源！我参加了大约4到5场死亡游行，通常持续一到两周。我的最后一次死亡事件持续了大约2个月，包括9-14个小时的工作日。 :(不好玩。

Answer 7

Deathmarch项目强调了让它实现的IT组织的无关紧要性。如果有一种感觉，计划和预算胜过诸如功能，技术选择或商业价值之类的东西，那么IT管理就变得无关紧要了。 IT经理只是为了监督程序员报告的成本中心。

如果该项目没有真正关注商业价值 - 它会在必须取消它的苦难结局（“Descoped”或“Reprioritized”）上磨砺。

这种情况发生的唯一方法是IT管理要么（a）可能有用，但不被业务重视，或者（b）根本没有任何线索。

死亡之旅意味着团队没有建立有价值的东西，它正在构建适合成本和时间安排的东西。

Answer 8

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

Answer 9

通常是通过糟糕的计划和沟通来实现的。