没有时间表，没有UML，没有等等，但仍然是一个项目成功？

Question

findings来自NICTA对400个项目展的研究

1. 大多数没有时间表的项目都是成功的
2. 需求方法的选择并不重要; UML“没有帮助”。
3. 在美国（但不是其他地方），开发人员只有在需求不佳时才参与项目评估。

并且意外还在继续。

我渴望知道的是，

1. 怎么回事？
2. 如果确实如此，那么为什么需要时间表，UML，..等等。

Answer 1

定义成功是主观的。

计划表或UML图只是软件开发的副产品。它们不是软件本身。如果生成的软件满足客户需求，那么到达那里需要哪些副产品并不重要。

“过程”可以作为盔甲。它会保护你免受某些事情的侵害，但与此同时会让你更加笨重。您需要在可预测性和灵活性之间取得平衡。

人们不是让软件完成的过程。

Answer 2

可悲的是，没有什么大惊吓，叫我艾恩兰德，但我一直认为世界上1％的人正在推动另外99％的前锋。

怎么回事？好吧，我在阅读这篇文章时看到的是：人们在处理任何事情时都很糟糕，但最终因为必须这样做才能完成。这真的只是文件证据表明人们在评估风险方面非常糟糕，而最好的项目管理是接受并准备失败的。任何其他观点都是妄想。

如果选择将成功定义为将项目推出门外（这甚至不是我听过的最糟糕的定义）那么管理层就很容易声称（或相信）世界上一切都很好。毕竟经济压力只是为了把钱存入银行，只有非常小的和非常大的公司才有任何投资兴趣让事情更好地工作。

为什么需要时间表等？那么你就可以对抗风险并建立一个有效率的公司。你可以在没有这个的情况下过世（世界上没有正义），但是你增加了大规模失败的风险，而且从长远来看，这会杀了你。

  

33％的项目表示他们没有   风险，但62％的失败

真的说的一切。人类，嗯？

Answer 3

怎么回事？

这完全取决于你如何定义成功。我将成功定义为“利益相关者对结果感到满意。”

通常，利益相关者衡量结果的方式如下：

1. 他们是否得到了他们需要的可交付成果（程序/系统）（这可能不是他们最初规定的那样）？这还包括功能和质量方面（错误，速度和整体外观）。
2. 他们是否及时获得了可交付成果？是否真的需要按时出现？
3. 他们是否支付了他们对交付品的期望？时间可能涉及到这个？还要记住，成本估算的准确性也很重要;太少可以和太多一样糟糕。 “太多”是显而易见的。 “太少”也意味着你错误地估计了这个项目，而且无论是谁资助你现在都有他们必须处理的预算盈余（而在大型组织中，如果你把钱留在桌面上，这通常意味着你将把它放在下一个年）。

Re：发现＃1）没有计划敲出＃2，可能还会＃3（因为资源时间也有成本）。没有时间表=无限制的预算（直到有人控制钱包字符串计算出发生了什么）。如果您的项目结束，并且用户得到了他们需要的东西，那么它就是成功的。但是根据相同的测量标准，Duke Nukem Forever在2009年5月8日之前取得了成功

此外，负责人往往不敢承认项目是失败的，甚至只是部分成功，因为它可能会严重影响他们及其未来的职业生涯。因此，即使它超过预算500％，也迟到3年。他们总是将其定义为成功。

Re：发现＃2）最重要的是你有一个计划。该方法只是您组织内的一种通用语言。 UML（统一建模语言）实际上只是用于表达计划的工具集合。无论你使用SCRUM，XP还是POW（普通老瀑布）都没关系，你仍然需要进行规划，它只会改变您进行规划的时间和频率。如果您没有计划担心，计划（或非计划）可以随时进行;由于缺乏计划而返工并不重要。

Re：发现＃3）我发现这是一个似是而非的陈述;因为我知道这不是真的。我已经看到开发人员参与了各种要求的估算（在美国境内外）。你可能在这里看到的是角色的细分。 “我们不能派那个极客Charley去和客户见面，把Bill送到BA收集要求。他不能做Fizz-Buzz，但他有三件套装。”

与此同时，有一种理念认为，一些管理者必须给出不可能的最后期限以提高绩效;而且担心如果我们让工人告诉他们实际需要多长时间，那么他们会不合理地自动夸大估计数。他们认为帕金森定律适用于所有地方。这是错误的，因为它只适用于官僚机构（如政府和大公司的行政管理），并且从未真正进行过科学测试。它继续存在，因为它很有趣，不是因为它被证明是真的。

为什么需要时间表，UML，..等等。

除非你在一个没有时间和预算限制的奇迹项目中，否则：你需要一个时间表，你需要要求，你需要一个计划等等。

即使你正处于其中一个奇迹项目中，你仍然冒险让更高层的人明智地关闭你。

Answer 4

嗯......关于没有时间表的项目 - 它们应该是成功的，因为如果给你所需的时间，大多数编程项目变得相当微不足道。消除最后期限的压力可能会导致更智能，压力更小的编码。

我还看到一些研究表明方法论的选择无关紧要，但只需要 方法论帮助很多。

我认为我们希望UML，计划和大量计划能够帮助我们的编程项目，因为这是项目管理人员告诉我们的。这很可能源于一种控制一切的现代主义的需要。但最终只需完成编码就可以了，更不用担心哪种类型的线路在哪里。

Answer 5

因此，他们在文章末尾描述了一个成功项目的定义：

  Verner还向开发商询问了什么   他们的标准是项目   成功。他们说：

* They had a sense they had delivered a quality product
* They had a sense of achievement
* They had enough independence to work creatively
* The requirements were met and the system worked as intended

没有关于按时交付或满足客户的要求。疑难杂症。

Answer 6

我曾与一位定义成功的人合作过，“我得到报酬吗？”无论是否失败，他都获得了100％的项目报酬，所以他认为这是100％的成功率。

正如其他人所说，成功是主观的。

UML和项目管理之类的东西只有在项目的生态系统支持它们时才能运行。例如，如果你试图将PM概念推向一个小团队的喉咙，你可能会导致它们失败。

Answer 7

可能会有很多因素，但对我来说毫无疑问，非结构化项目可以成功（而且我的意思是完成并为业务提供所需的好处，而不仅仅是发货或者达到了目的客户开具发票）。

我认为你会发现这些成功项目的共同点是（一个或多个）：

1）相对较小的规模（最多可能10人，不超过12个月的团队）
2）成立和/或保税团队 3）具有相关业务/技术领域经验的项目成员
4）聪明，有动力的人参与了 5）来自管理层和客户的现实期望

如果没有可靠的规划，使用UML或坚实的方法论，所有这些事情都可以存在，恕我直言会产生更大的差异。我建议任何在混乱但支持的环境中工作的开发人员可能会比那些在结构化但政治工作场所工作过的人提出更多积极的故事。

当然，如果你看一下Steve McConnell的12个项目错误列表，那就是IT项目失败的原因（http://www.stevemcconnell.com/ieeesoftware/bp05.htm - 不科学但肯定对大多数开发人员来说都是正确的事情），只有一两个他们真的与过程有关。 UML和更好的时间表不会改善工作环境，解决员工问题，处理政治和不切实际的需求等等。

那么为什么没有这些东西项目就能成功 - 因为它们很重要，但它们不是最重要的因素。

Answer 8

如果那是真的，有人应该告诉PRINCE2的人把它装进去

PRINCE2是根据研究结果创建的，表明大多数项目都失败了（失败基于：1）没有准时，2）没有预算，3）没有规范

在旁注，我不使用UML并且过去了。主要是因为UML无法与客户共享，并非所有程序员都知道。用户故事没有这个问题

- LM