随着互联网变成公众生活中不可缺少的部分，

软件系统的应 用比当年多出了百倍，而质量成本依然是软件项目的杀手。

软件产品的需求比以往更加 难于控制，需求蔓延（requirement creep）是软件开发中最常见的风险之一。IT行业 技术变化之快远超其他行业，学习新的技术、方法是软件工程师常态工作的一部分。

根据这些问题，在这次会议上首次提出了“软件危机”的问题。会后不久，Winston Royce根据制造业的实践，提出了一个至今依然影响软件业的开发模式—瀑布式软件开发生命周期，希望能够借鉴其他行业的经验，

解决软件开发中的问题。

但 40多年后，危机并没有消失，依然威胁着软件公司的生存发展。

近20年来，越来越多的软件工程实践者开始了深层次的反思：问题出在哪里？解决问题 的方向又在哪里？

在反思的同时，一些有勇气的软件工作者开始了新的探索。他们在软 件开发过程中，尝试了新的实践，并不断总结交流，形成了我们今天看到的敏捷宣言、 敏捷原则、敏捷实践以及敏捷方法与传统方法结合的实践。

重新审视项目成功的标准

传统项目管理铁三角

在预算范围内，按期向客户提交需求范围要求的产品是长期以来IT企业判定项目成功以 否的标准。这个著名的项目管理铁三角（需求范围、成本、进度）直到今天仍定义着大 部分软件项目的实施目标。我一直觉得这个铁三角有一个致命问题：它们到底是 项目追求的终极目标，还是项目实施的约束条件？项目的价值似乎没有在这3个度量指 标中明确体现。

我看到很多项目为实现不合理的进度目标辛苦努力，其他很多重要的东西被忽略，特别 是没有关注项目要获取的价值，似乎价值这个东西随着进度目标的完成自然就会实现。也有些项目沉迷于具体的需求项，而看不见这些需求项到底给用户带来什么价值。一个 令软件业同行不得不面对的事实是超过50%的软件产品功能基本没有被用户使用过，换 句话说，对软件项目团队辛辛苦苦实现的一半以上的功能，客户并无兴趣使用，它们没 有给用户带来什么价值。这就应了一句老话：每条需求都有成本，但并不是每条需求都 有价值。推想一下，又有多少没有完成的项目，因为追求一些没有价值的需求，导致了 过多延期和预算超支，使得企业只能放弃它们。

图1-1定义了传统项目管理铁三角：需求范围（特性、功能）、成本（资源、预算）和进 度（时间）。成功的项目应该依据客户需求（范围），在不超出预算的前提下，按时提 交项目。“传统铁三角”定义的项目成功三要素有两个重要隐含假设。项目定义的需求范围真正反映了客户的真实需要，通过使用这些需求功能，用户可以实 现其价值目标。项目计划是正确的，实际和计划不符意味着错误。在这两个假设下，和计划不符的都会被视为问题，项目管理工作就是消灭计划的偏差。让我们认真思考一下上面的假设，它真的总是正确吗？按时完成，没有超出预算提交了 需求范围的功能，一定就意味着项目是成功的吗？如果这3个目标没有实现，项目就一 定是个失败的项目吗？

请你回顾一下以前你们公司发布的产品，在这3个目标方面都做得好的产品中，有多少 卖得好，为公司带来了价值？有多少用户并不买账，产品并未对扩大市场占有率有任何 正面贡献？而在没有按时完成，没有实现所有项目计划阶段定的需求范围，预算有超出 的项目中，有没有卖得好、客户喜欢的产品？这其中有没有为公司带来新的机会的项 目？

举个例子：

《泰坦尼克号》是一部国内观众熟悉的电影。也许有些内幕你可能不太清楚，它的预算 严重超支（整个电影的制作费用超过2亿美元），进度一再延期，剧情有无数的变化调 整。如果按传统三要素来度量的话，这绝对是个非常失败的项目。但面对全球20亿美元 左右的票房，导演和演员地位火箭式的蹿升，你能说这是一个失败的电影项目吗？

“传统铁三角”的致命问题是前面的两个假设。因为对一个软件项目来说，一开始我们往 往不完全清楚用户真正的需求，产品需求的理解有个逐步演化的过程。哪怕在项目结束 时，很可能我们还不能完全确定实现用户价值的需求集合，这也是产品需要不断升级的 原因之一。另一方面我们如何看项目初期制订的计划呢？我们能假设它的正确性吗？几乎无一例 外，答案是否定的。在做计划时，你要面对很多不确定的东西，如需求范围、实施技 术、团队能力、外在制约等。虽然你参考了组织提供的团队效率数据，但考虑到影响效 率的各种因素及具体团队的特殊性，估算出的进度计划的准确性是让人质疑的。更让人 头疼的是，在开发过程中，很多影响项目进度的因子（如需求、人员、环境等）会发生 变化。把符合一个不靠谱的计划作为项目的主要目标之一，恐怕不是一件很明智的事。明确成功项目的标准意义十分重要，它是软件开发方法的纲。借用一句老话，“纲举目 张”，这是理解敏捷方法的一个很好的切入点。在本章里，我们一起重新审视项目成功要 素，对旧的项目管理铁三角做必要的修正。

新的项目管理铁三角

那么究竟什么应该是衡量项目成功的终极标准呢？我们在前面已经提到了它—价值。Jim Highsmith提出了敏捷铁三角的概念，他提出了3个新目标。价值目标：开发出可发布的产品。

质量目标：开发出可靠、易更改的产品。

约束目标：在特定的约束条件下实现价值目标和质量目标。我十分认同敏捷铁三角的核心理念，这和我多年在咨询、教学中推荐的原则高度一致。对其略做修改，图1-2显示了新的项目管理铁三角。考虑到不同的软件企业的差异性（例 如，并不是每个软件企业都是在开发产品）这里有必要对3个目标做深入说明。

价值+能力目标

将项目的价值最大化是项目管理的主导因素，不同类型的项目追求的价值目标会有差 异。其度量指标可能是：销售额及市场占有率的增加；公司品牌及竞争力的提升；客户忠诚度的提升；技术创新带来的新机会。不同类型的项目会有不同的价值目标，但它们有一个共同点，就是项目价值是站在组织 而不是项目的角度来看的。另一方面，在考核项目时不能忽略人的能力的提升。这也应该是一个项目后评价中的重 要指标。在项目结束后，软件工程师设计、开发、测试各环节的能力是否得到了提升？需求架构人员是否对产品的价值、合理的架构有了更好的理解？管理人员对团队能力是 否更加了解？客户或用户是否对后续产品方向更加清晰？过程人员，如质量保证人员，是否对过程的适用及执行难处有了更好的认识？对 于许多软件应用服务开发商来讲，人会是企业的最重要财富，人的能力成长对公司的发 展至关重要。

2．质量目标

我们不应忽视敏捷对质量管理的贡献，它从实践上强调质量不仅是清除缺陷，不仅是功 能正确。它提出了技术债务（technical debt）的概念，将其作为后期软件维护隐患的 指标，并作为迭代开发的重要质量评估项。敏捷领军人物也提出了许多经过验证的有效 实践来管理技术债务，所以敏捷质量目标不仅是可发布（功能正确），同时也是可维护 的！

3．约束目标

约束目标主要是进度和成本，约束不应该是目标，它是前提。例如，刚性的进度要求， 应该理解成在按期交付的前提下，团队将尽可能实现最大的价值。我对新的项目管理铁三角的解读是：在特定约束条件下，控制产品遗留隐患对交付产品 的使用及维护的影响，关注人员能力提升，尽可能将项目/产品价值最大化。

旧的项目管理铁三角有时会让团队追求错误的目标，如片面追求按时交付，而忽略了是 否交付了客户需要的产品。Donald Reinertsen指出很少有人考虑延期成本， 他认为这是个非常重要的度量项，每个组织都应该考虑。在某一特定时间提交产品固然 很重要，但提交的产品是可以发布的，也就是说它已经实现的功能特性对客户和用户是 有价值的，这一点应该是更重要的。顾名思义，延期成本度量的是产品不能按期提交的 代价。如果它小于通过延时实现的功能带来的价值的话，项目延期应该是顺理成章的 事。如果延时带来的后果是组织不能承受的，在规定时间发布一个新的版本就是必须要 做到的事了。当然在这种情况下，需求范围往往是可调整的变量了。至于将需求范围作为项目的主导目标就更不合适，项目前期用户很难对需求有全面、充 分的理解。如果项目开发周期较长，用户的想法在开发期间发生变化也是一件很正常的 事情。在美国IT行业有个说法：有生就有死，工作就要交税；做软件，需求一定会变。