成本，进度，质量：选两个

Question

我们听过这句谚语，"Cost, schedule, quality: pick two."我最近在大政府项目上的经验表明，质量往往受到时间限制的影响。事实上，有时项目经理会选择计划，而对质量几乎没有明显的关注，有时候很少考虑成本。

你被要求妥协吗？您在商业世界中有什么经历？如果您是项目经理 - 也许您是自雇人士或在家中和周末从事项目工作 - 并且您控制成本，进度和质量，那么“选择两个？”您是否有您最不喜欢的开发方法（例如自动化测试）？

最后，对于一个被迫选择时间表和成本高于质量的团队，您建议development methodology哪个？提前谢谢。

我建议我们对合理的评论进行投票。

Answer 1

  

“成本，时间表，质量：选择两个。”

这是传统的陈述，但不是有四个参数而不是三个？有低成本，短时间表，高质量和高数量：如果你可以牺牲第四个，你可以最大化其中三个。

  

你被要求妥协吗？您在商业领域的经历是什么？

当有人问我某些问题时，我的费用是固定的（即我每小时或每年的费率），因此无视费用。

质量有所不同：某些类型的可靠性寻找与软件相关的其他书面设计和文档，而对于其他类型的软件，他们可能会说“只要软件有效，我们不介意您是否编写任何文档”。我总是会遇到隐含的最低质量等级（例如，任何/所有明显的运行时软件错误都必须修复）。

我倾向于坚持短时间表：其他人可能有长期的多年计划，但我通常会“注册”或承诺在接下来的几天或几周内做一些事情：比这更长的时间我估计它并不合适（而且可能没有明确定义）。

因此，牺牲就是数量：我希望人们一次给我一点点，最好是一次一份工作（另见“sprint”和“iteration”）。

  

如果您是项目经理 - 也许您是自雇人士或在家中和周末从事项目工作 - 并且您控制成本，进度和质量，那么“选择两个吗？”

我牺牲了时间表;我不在乎需要多长时间，只要：

• 成本是固定的/零（即我是唯一一个这样做的人，无偿服务）
• 质量可以接受
• 数量（或功能）按计划

我可能会达到我的时间表不合适的程度，即我决定我不能继续处理该项目：此时我牺牲了（剩余的未实现的）数量。规划这种可能性，可能需要记住，完成项目的50％有时比完成100％项目的半成品更好（即更好地完成和使用一半的功能比完成任何事情更好） ）。

  

您是否拥有您从未妥协的开发方法（例如自动化测试）中最喜欢的部分？

1. 源代码非常整洁让我理解：软件只能在计算机上按预期运行，因为我能够首先在脑中运行它。

2. 我还坚持测试软件。它不需要经过单元测试（instead, system-testing is OK），但尽管我的虚张声势关于它在我脑海中的运行，但我不保证任何未经测试的东西。我的老板常说，不是“你得到你所期望的”，而是“你得到你所检查的东西”。

3. 对于长期运行的项目，测试需要自动化。我愿意重构（见上文第1点），因此我需要进行回归测试。如果测试是手动的，那么运行它们的成本将与代码量成比例，因此测试所需的时间将增加为O（n平方），即如果它不是自动化则会太昂贵。

Answer 2

根据我的经验，恰恰相反：专注于质量（尤其是早期）往往会降低成本和进度。从我所看到的情况来看，我会说大多数严重超支的项目主要是因为他们接近他们认为结束的东西，他们发现他们的代码不起作用。在这一点上，他们试图通过调试等大量的额外时间来修复问题，但实际上做得太好了。更糟糕的是，他们必须撤消他们所做的相当多的事情，因为有些部分依赖于其他地方糟糕的设计决策等。

Answer 3

根据我的经验，你总会被要求妥协。它会根据不同的客户而有所不同。

您可以个人拒绝在某些方面妥协，但有时唯一的方法是更改​​项目或工作。

SCRUM和其他方法是管理妥协并使其对您的经理和客户显而易见的方法。它们不会阻止妥协。

最后，请记住这些不是二进制属性。您将平衡在项目的不同方面（数据库与GUI，报告与计算等）可以损害多少“质量”，并在速度和成本之间取得平衡。你不“选两个”。您可以做出数千种不同的决定，以满足您的客户或经理的需求。

Answer 4

SCRUM与adequate SCRUM software。

SCRUM是一种agile Software Development方法，其中项目的所有任务都简化为名为sprints的任务组。这是跟踪指定人员的所有任务的绝佳方式，并且保存项目计划的小时数绝对是非常宝贵的。

放手一搏 - 你不会回头，我敢肯定。

Answer 5

我推荐Scrum。它是一个敏捷的开发框架，专注于迭代开发阶段，在3-4周的开发时间间隔结束时，您可以在每个“sprint”结束时获得有形的产品。然后在每个sprint的最后，你作为一个团队继续前进，可以改进什么，并减轻你可能需要的任何变化。

在政府环境中，人们一直在改变主意，因为他们在最终产品应该是什么样的情况下更好地了解他们对开发人员的期望，因为如果产品主导完全改变的话他或她的思想，开发人员仍然可以有一种成就感，因为他们交出了一份应该可以使用的交付品。

http://en.wikipedia.org/wiki/Scrum_%28development%29

Answer 6

如果您选择时间表和成本，那么担心方法论是错误的。去代码。代码尽可能快。随意做脏兮兮的工作，只要他们允许你制定时间表而不带来额外的开发人员。请记住，如果质量实际上无关紧要，那么可维护性和测试并不重要，因为这些都是质量问题。

不知何故，读到这一点，我怀疑你真的想完全忽视质量：）

Answer 7

我生活在经典瀑布SDLC的世界里，我们有客户驱动的截止日期。所以对我们来说，时间表是首要任务。成本对我们来说并不是那么重要，因为我们在工作开始之前估算并向客户开账单。为了平衡这两者并仍然保持良好的质量，我们开发人员试图高估任何改变所需的工作量，为我们提供足够的时间和资源来完成这项工作。它有点黏，但这是一个很好的解决方法。