案例分享：局部地揭露魔力三角
一组项目中的一个教训提供了深刻的例子，来说明度量对假设的挑战。为了按时交付项目，本例中的团队每天忙得团团转，通常对于一个早期的启动阶段，意味着我们需要按季度交付包括新特性、功能增强和bug修订的版本。有10位程序员负责这个项目。
我有一个关于每个发布版内容的假设。回头看的话，我不确定这些假设都是何时何地冒出来的。我猜这仅仅是因为它们看起来像是常识，它只不过是经常出现的假设之一。通常你认为是基于客观事实和经验的假设，往往只不过是基于别人告诉你的信息。
由于指定了一个严格的截止期限，这个发布版中复杂的特性越多，最终产品的质量就会越糟糕。按这个逻辑，我相信包含过多复杂特性的季度发布版同样会包含很多的bug。我的假设是基于你也可能听说过的那个概念：软件开发的“魔力三角”。它表明，在更多的特性、更紧迫的进度和更高的质量三者之间做选择的话，你只能满足其中两个，而剩下那个将无法得到满足。因为我们已经承诺在一段很紧迫的时间里完成很多特性，所以如果我们添加更多的特性，那么结果将会是更差的质量。有道理，对吧？
为了测量每个发布版的内容，我将每个程序员的任务（特性、功能增强或者bug修改）按最简单到最复杂的顺序，分别按1～4进行评分。软件发布版的平均复杂度由任务的平均复杂度来确定，而工作总量由所有任务的复杂度之和获得。为了测量每个版本的质量，我将发布后出现的bug按相同标准和相似计算方法进行计算。
结果令人惊奇。如表2-1所示，在两年的6个软件发布版中，在对每个版本实际时间数据进行标准化之后，拥有最高复杂度和工作量的两个版本质量并没有更差，这里的质量以发布后的bug数量来衡量。事实上，质量最好的产品反而来自添加了很多东西的版本。并且，如果将所发现问题的数量按照每个版本的工作量取比值的话，两个复杂的版本却有相对较好的质量。
怎么会是这样呢？ 首先，应当注意，尽管我们在某版本中加入了很多内容，但我们很认真地计划和开始每个发布版从而保证我们至少是有成功机会的。虽然这些版本有很高的复杂度，但时间进度更紧迫，风险很高而且没有多少犯错的余地。其次，我们拥有协作良好的杰出团队。最后，我们注意到，由于工作进度已经很紧凑，我们不允许任何重要的特性悄悄混进这些版本中，因此，在每个发布版本的研发开始之前，团队就知道复杂度目标。
一种解释可能是我们的计划太保守，事实上我们有余力在发布版的开发中完成更高的复杂度。或许我们认为的张力并非真的如此。但这无法解释为什么更复杂的版本有更高的软件质量。如果较小复杂度的版本也是同样保守的计划，那么这些发布版的质量应该更高而不是更低。
你还可以找到其他可能的解释。例如，可能某些领域的质量随着时间的流逝进行了改善。我只想说，有许多潜在的解释，并且可以收集和研究更多的数据，来证明或驳斥这些解释。然而，基于我对这个团队工作知识的熟悉，我个人的推测是，其中存在其他更有意思的事情。
这里是我认为数据所说明的。好的团队愿意接受挑战，并且当接受挑战的时候，他们能够应付自如。如果你给他们设置更高的障碍，让他们去做更多的事情，他们会变得更专心、更有积极性，并且实际上他们确实干得更漂亮。因此，在紧凑的时间表中向发布版追加更多的工作量以及更高的复杂度且不损失质量是可能的。事实上，如果团队在压力下反应不错并且得到激励，产品质量甚至能够得以提高。“魔力三角”的概念没有考虑到人类行为的特征。从某种意义上，我认为这刚好反映出计划方法中许多错误的假设，计划方法总是认为基于一个合理的计划和进度表，程序员就能产出始终如一的产品质量，其实这并不必然。
为了更具权威性，我们需要更多的现实数据。但是，最起码，像这个例子说明的，“魔力三角”可能是一个过于简单化的概念，并且其可能导致错误的假设（就像之前的假设一样）。由于我已经了解了这个事实，因此我不会再很快打消追加多的复杂度到一个岌岌可危的发布版的想法，甚至挑战团队之前的极限可能会是一件好事。
