传统观念上的成功是指基于给定的财政预算，按照需求规格按时交付产品。[Standish]中给出了一些经典的定义：
成功的（Successful）
“按时完成，费用不超出预算，而且所有特性和功能都符合原先的设计规格。”
不太成功的（Challenged）
“已完成而且可以运行，但费用超出了预算，没有如期完成，[拥有]的特性和功能少于原先的设计规格”
失败的（Impaired）
“在开发周期的某个时刻项目被取消了”
尽管非常流行，这些定义还是有问题的。某些项目即使一分钱也没赚到，它仍然可能是成功的。另一些项目即使带来了数百万美元的收入也仍然不算很成功。
CIO杂志对这种古怪的情形作了如下评论：
那些满足了所有传统成功标准——时间、预算和设计规格——的项目，最后仍然可能是失败的，因为它们不能吸引目标用户，或者因为它们最终不能带来更多的商业价值。
……同样，按照传统的IT标准被认为失败的项目最终却可能反败为胜，原因是：尽管存在费用、时间和规格方面的问题，但系统最后却被目标用户所喜爱，或者带来了预想不到的价值。举个例子，曾有一家金融服务公司，开发一套新系统时工期延迟了六个月，费用也超出了原来预算的两倍多（最终的花费达570万美元）。但这一项目最终却造就了一家适应性更强的组织（在13个月之后），因而被认定为一个相当成功的项目——这家公司通过账户冲销节省了3300万美元，而且降低了时间价值比，提高了容量，从而使生产环境中并发收集策略的测试数增长了50%。*
成功不只是如期完成对于成功来讲，除了如期完成，应该还有更多的要素……但它们是什么呢？
我小时候非常喜欢玩耍。后来我喜欢上了编程所带来的挑战。当我使一个程序成功运行，就会有一种胜利的感觉。回想那时，即使是一个不能工作的程序，也仍然是一种成功，只要我从编写它的过程中获得了乐趣。这时我对成功的定义主要围绕着个人回报。
随着经验不断增长，我的软件变得更加复杂，我常常无法全面跟踪它究竟是如何工作的。我不得不在完成某些程序之前结束它们。我开始相信可维护性是成功的关键——这一思想在我参加工作并与其它的开发团队一起工作时得到了验证。我为自己能写出优雅的、可维护的代码而感到自豪。此时，成功对我来说意味着技术优秀。
某些项目的代码尽管写得很好，但项目还是失败了。即使执行过程无懈可击的项目也仍然会让用户打呵欠。我开始认识到我的项目组是一个更大的生态系统的一部分，这个系统包含几十个，几百个甚至几千个人。我的项目需要满足那些……尤其是为薪水支票签字的人。实际上，对于那些为工作提供资金的人来说，软件的价值必需超过它的成本。于是，成功意味着向组织机构交付价值。
这些定义并不矛盾。三种类型的成功都很重要（见图1-1）。没有个人的成功，你将很难为自己及其他员工提供激励。没有技术上的成功，你的代码最终将被它自身的重量压跨。没有组织的成功，你的团队可能发现公司不再想要它了。
组织成功的重要性
软件开发团队更喜欢容易获得的技术和个人成功，因此组织成功常常被他们忽视。然而毫无疑问的是：即使你并不为组织的成功负责，更大的组织仍然会从这个层面上来评价你的团队。行政和高管不太会关心你的软件是否优雅、可维护，甚至也不会关心它是否被用户所喜爱；他们关心的是结果。那是他们项目投入的回报。如果你不能达到这种类型的成功，他们会设法让你达到。
不幸的是，高级经理人员通常并没有时间和精力去为每个项目分别实施一套有细微差别的方案。他们挥舞的是大刀，而不是解剖刀。他们希望由项目团队去关注各种细节。
当团队开发的结果不能让经理们满足，就是挥舞大刀的时候了。成本就是最明显的目标。砍掉成本有两种最简单的方法：设置非常紧迫的交付期限来缩减开发时间，或者将工作外包给一个劳动力成本更低廉的国家。或者两种方法同时运用。
这些都是笨拙的方法。过于紧迫的交付期限最终将延缓进度，而不是加快进度[McConnell 1996]（220页），而离岸外包则拥有隐性成本[Overby]。
紧迫的期限和外包的威胁听起来是不是很熟悉？如果是，那就说明你的团队到了重新为成功负起责任的时候了：不仅仅是个人和技术的成功，还有组织的成功。
图1-1 成功的类型：
|
组织最重视的是什么？
尽管某些项目的价值直接来自于销售，但组织的价值却不仅在于销售收入。项目可以通过多种方式来提供价值，而且你不能永远使用金钱来衡量这些价值。
除了收入和成本节约，价值还会来自以下方面：*
· 竞争优势差异（Competitive differentiation）
· 品牌影响（Brand projection）
· 提高客户忠诚度
· 满足监管要求（regulatory requirements）
· 原创性研究（original research）
· 策略性信息（strategic information）
|
* 本文摘自《敏捷开发的艺术》一书。