众所周知，在2008年的头几个月里，资本市场中的经济状况并对许多公司（无论大小）产生了影响。今年三月，Gartner 建议首席信息官们必须做好削减 IT 成本的准备，以便应对日益紧缩的经济环境。 1 软件开发项目，尤其是那些探索性质的、动态的、精益的项目（这些正是敏捷性方法的用武之地），在现阶段被冻结甚至延期直到经济状况回暖之后。有些团队已经经历了劳动力的减少，并因此丧失了有价值的域和项目知识。

这些不确定的时期使得软件管理者和执行者萌生了返回舒适地带的念头，这是可以理解的。当遇到威胁时，我们大多会去寻求熟悉和安全，无论是食物还是温床。然而，在软件开发的环境中，寻求舒适不应当包括从敏捷的方法倒退回到更加传统的、分量更重的、面向计划的方法论。不幸的是，我们发现有些 IT 管理者和执行者正在这样做。

敏捷性人员所面临的挑战就是理解管理者和执行者来自哪里，洞察敏捷技术在剧变中所具有的能量，并且准本好同软件管理者展开一场关于保持敏捷性的好处的平稳而详尽论述的讨论。

本文从帮助您展开这类讨论的工具方面解释了敏捷性：

敏捷性交付上好的投资回报（ROI）的潜力。

敏捷性压低所有权的全部成本（TCO）的能力。

信任在处理敏捷性业务案例中的重要性。

我将深入地探索这些主题，并且提出一些保证我们的软件项目能够在一个正确的方向上向前推进的方法。

当情况变得艰难时……

“在艰难的经济条件下，公司关注的是收入的增长。您需要保护收入，更需要控制运行开支。在这方面，IT 通常是疲惫不堪的。在危机时期，公司往往将 IT 视为一种花费，并且它们将其置于首席财务官的成本遏制模式之下。”

成本遏制瞬即被提到管理者的办公桌上，并且增加了他们对敏捷技术的恐惧和怀疑。随着敏捷带来的一系列问题的出现，管理出现了恢复旧的体制的趋势。这些问题包括：敏捷是危险的；业务单元客户要求一个更加可预言的交付模型；敏捷项目和团队太难管理等。在巨大的压力之下，有些公司认为通过敏捷提高回报的前景在“好的时期”是符合它们的风险策略的，但是现在，沉重的方法似乎是更好的一种选择，尽管它们并不能够真正地提供一个更好的解决方案。在同一个富有挑战性的项目环境进行斗争的过程中，有些管理者失去了对敏捷的信心，他们转而寻求增加状况报告、瀑布、以及整洁的阶段序列中所具有的舒适性和被感知到的优势。

敏捷开发人员对这些威胁所作出的反应通常是一组定性的好处。当优先级特性在一个更短的时间段变得可用的时候，终端用户中的客户满意度似乎得到了提高。同业务单元副本的关系变得更加开放、动人和有生产力。当好的软件被交付和使用的时候，团队的士气得到提升。在生产中系统的性能和强壮性更加出色。来自 VIP（非常生气的人）的客户支持呼叫随之下降。

但是，当情况变得艰难时，善于计算的人会削尖他们的铅笔，记住这点很重要。如果您正在经历一场经营管理从敏捷的倒退回到更加传统的、计划驱动方法的思潮，那么您一定希望有能力通过可靠的、面向管理的业务案例，为敏捷性所带来的经济利益辩护。只站在一名敏捷人员的角度思考问题还不够。请您跳出这个圈子，站在更广阔的角度来进行思考。推销您的观点的最好方法，就是向您所要说服的那些管理者和执行者证明，这样做能够获得最大的收益。

敏捷的经济收益能够用三种业务案例获得，每一种都能够强烈说明敏捷胜过传统的方法：投资回报（ROI）、所有权的全部成本（TCO）、以及改善的市场竞争力。任何一个论点也许都足以证明坚守敏捷是明智的；当然，将三者结合起来就更加令人信服了。

投资回报（ROI）

ROI 反映了一定投资所对应的经济收益。它通过计算获得或者损失的资金数额同投入的资金数额的比例而得，通常以百分数的形式表示。对于软件开发来说，收益通常来自软件产品的销售所得。

致力于推进新的收益的敏捷项目非常适合 ROI 的评价。您的项目是吸引新的客户，还是通过交付新产品从而在现有的客户中创造增加的收益？您的公司收益是通过进入新的市场获得的，还是通过增加现有的市场份额获得的？如果您的公司将一部分资金投资于某个正面收益预期的项目的话，那么一个 ROI 评定就很有可能会出现。

清楚地说明敏捷相对于传统的、计划驱动的方法具有更好的 ROI 潜力，这可能有助于您赢得讨论的机会：从观点（敏捷的东西更好）到目标（敏捷能够使 ROI 增长 x%）。当人们想再次回到具有缺陷但熟悉而舒适的传统方法时，一个健全的业务案例对于留在敏捷来说是一个强大的工具。

根据您计划承担 ROI 的深度，这可能有助于接近财务方面进入一个 ROI 讨论的速度。回报的决定因素涉及到毛销售额、净收入、收入酬劳、现金流、以及资金的时间价值等。您并不需要在一夜之间成为财务专家；毕竟，理解会计和财务决算之间的细微差别是需要长时间研究的事情。但是，业务拥有其自身的语言，并且几个小时的浏览就可以帮助您获得基本的要义。

相对于回报来说，ROI 的投资这一边更容易被固定下来，这是由于它归结为建立和维护软件产品的费用。这些投资包括人员、保险金、设备、工具、软件执照等等。当您为一个项目、产品或者团队查看 ROI 的时候，请始终提醒自己各部分的成本应当是适度的。如果人员被应用于多个项目，或者基础构造的成本在多个团队之间摊开，那么这将影响您的 ROI 模型。

我们来看一下一个敏捷的 ROI 模型的三个变体。当我们讨论这三个例子的时候，请注意 ROI 是一个拥有两个可变因素的等式。改变其中一个因素，或者全部两个因素，都会影响输出结果。请您考虑在这三个变体中，那一个和您的项目最匹配，以及这个模型如何稍作调整来适应您的需要。

投资回报变体 1：成本降低，利润不变

在这个例子中，我将从降低成本的角度，详细描绘敏捷的 ROI 收益。设想您的公司以100万美元的价格出售了一个软件产品。这个产品是如何被开发出来的并不重要：交易已经完成，并且回报是一样的。了解到这一点，您的提高账本底线以及 ROI 的机会将显示出敏捷的优秀的运行效率。

敏捷的和计划驱动的 ROI 模型的不同之处是十分微妙的，但是却产生出巨大的影响。区别之一就是您能够断言，例如计划驱动的方法将把您的项目周期从十二周扩展到十四周，增加了两周的时间。这一不同可以用 COCOMO II 这样的模型被正式表示出来 4 ：“交付新的系统功能和改变旧的系统功能的时间是系统复杂性的一个函数，用来影响变化的流程、做出改变的开发人员的技能、以及可以用来自动执行的工具。” 5 另外，您可以根据观察和实验的结果彻底捕获并且回顾需求、项目计划、接受测试标准、以及其他的要求。您可以断言的另一个不同，就是计划驱动的方法将要求一支更加庞大的团队、管理需求和计划的额外资源、同业务单元对应方的正式联系、以及管理外包团队的额外资源等。图 1 中显示了这一比较的细节。

图 1: 成本降低，利润不变

这些断言和不同之处只是用作描述的目的。很可能您自己的建模应用将带来不同的项目构成、成本结构、团队规模等等。但是，如果您是一位敏捷的拥护者，您就很有可能拥有第一手的经验，知道一支小型的团队是如何用更短的时间交付出更好的软件的。一个 ROI 模型就是用来表达这一经验的工具，用来使那些对方法论的争论不完全感兴趣的人们明白这一点。

投资回报变体 2：成本不变，利润增加

在第二个场景中，您负责一支规模固定的团队，因而投资也是固定的。无论采用什么方法，您都将花费某一数额的投资。这一情况对于大型的公司来说十分普遍。

您的经验告诉您，相比计划驱动的方法，敏捷将会生产出更大的收益。这一论点的基础就是敏捷关注的是交付有效用的软件，并且将客户最需要的特性作为高优先级处理。您已经通过一些销售人员、也许甚至是一些客户运行了这一点，并且通过一个更能够满足客户需要的软件产品，创造出增加的销售数量的机会。

如图 2 中所示，我们首先以 ROI 变体 1 中给定的同一个团队构成开始。项目的成本是固定的，所以您必须通过增加收益来提高 ROI。基于您的市场调查，您相信一个关注客户需求的敏捷较之计划驱动的项目将增长 20% 的回报，获得更多的客户订单以及更高的价位。

图 2: 成本不变，利润增加

投资回报变体 3：成本降低，利润增加

许多已经采用敏捷的公司正在开辟软件开发的新天地。他们的关注点是新的应用程序、服务和组成部分，而不是将大量的遗留程序带入 21st 世纪。他们通过提供有竞争力的产品扩大份额市场。

这些项目非常适合用来描述敏捷所具有的优秀的 ROI 潜力。当您论证敏捷能够如 ROI 变体 2 中所示的那样交付更好的回报，并且如 ROI 变体 1 中所示的那样具有更好的运行效率和成本控制的时候，您就达到了 ROI 等式两边的收获。

考虑图 3 中所描绘的模型。它既考虑到模型 1 中的团队规模变化，也考虑到模型 2 中的收益。敏捷所能交付的 ROI 是十分突出的，并且将促使风险管理者重新考虑是否要撤退到传统的、方法驱动的方式。

图 3: 成本降低，利润增加

当投资回报处于危险之中时

关于 ROI 的讨论还必须检查风险是如何影响决定和结果输出的。当我们建立一个 ROI 模型时，我们可能忽视这样一个事实：对于应用的预测也是一项投资，并且这项投资也将成为风险的因素之一。

管理风险并不是银行家和风险资本家的专利。所有投资者都应该考虑风险的因素。您将面对租用还是购买的抉择，或者是购买一辆新车还是二手车的抉择，您会仔细检查同您的投资相关联的潜在方面。您必须具有管理风险的能力，从而理解并且保持对风险的容忍度。所有的这些能力都是充分利用时间和弱化不利因素的基本原则，并且您能够将这一经验带入到软件 ROI 的讨论之中。

软件项目如同其他投资一样，是具有风险的。有利的一面是，当我们的项目获得成功时，所有的团队成员都会很开心，并且获得进一步的回报。不利的一面是，当项目遭遇失败时，投资就损失掉了。更坏的情况是，其他项目的机会成本也会因此被丧失殆尽。

敏捷关注于开放和有效地同客户进行沟通，伴之以迭代地交付，从而使得项目的成功率达到 70% 6 （某些公司所报告的成功率甚至更高）。相比之下，相关研究显示采用传统方法的项目的失败率可以达到 60% 甚至 85%。 7 所以，即使敏捷的和计划驱动的方法在建模中具有相同的 ROI，敏捷更有可能获得成功这一事实也是获得 ROI 的一个关键因素。

我们还必须了解有些软件项目是注定要失败的。我们有可能将注意力完全放在我们所做的工作上面，而忘记了自己是一个投资者。但是，好的投资者都有能力将这类项目转化成一种重要的，但是很有节制表述的敏捷的好处：他们知道如何降低他们的损失。

通过敏捷，您通常能够更快地指出您的项目可能并没有前途。在不确定的环境中，这一点对于管理者来说十分重要。敏捷为他们提供了更好的工具，将方向修正量引入到项目之中，或者避免彻底的损失。瀑布模型经常被认为是更具预见性的，但是不幸的是，这种预见性往往只有在项目的后期阶段才会变成可能。没有人在软件项目开始时就计划失败，但是谨慎确实比勇猛要重要一些。敏捷为管理提供了这种谨慎。

所有权的全部成本（TCO）

IT 行业的领袖人物 Howard A. Rubin 博士提出了一个重要观点，衡量技术成本必须从上和下两个方面共同进行：

“从顶部开始，您必须理解您的技术成本——技术产品和服务的成本——就好像您是一家制造公司一样。您必须理解技术的成本结构，它对您的利润的影响如何，以及您的技术投资对增长、收缩和市场份额的影响是什么。并且您还必须将您对于技术的成本结构和性能结构的理解直接整合到公司的财务之中。”

他继续说道：“从底部开始，您必须对技术和技术组织本身有非常多的理解。这远不止是知道开发一个应用程序需要花费多长时间那么简单。它意味着您需要将技术视作一个日常用品，按照单位的成本价格来计算。” 8

管理者和执行者自顶向下地检查所有权的全部成本（TCO）。但是为了将敏捷的收益从 TCO 的整体观中分解出来，我们需要自底向上地工作，并且正两种方法最终在一点上汇合。

TCO 是用来分析“保持轻量”系统（即无论是通过客户交互作用还是通过内勤系统，激励现在商业的生产 IT 系统）的最普通的模式。随着软件进入其开发周期之中，从新的开发进入到成熟的系统，经济环境也相应地从 ROI 过渡到 TCO。

正如前面我们所讨论的那样，敏捷通常被视为一组用于新的开发的技术，但是它同样能为 TCO 和成熟系统提供切实的收益。软件维护被基本的敏捷概念所包裹：从优先考虑的候选库中开始工作，或者改变次序，并且交付工作软件的增量发布。团队动态在此处也是适当的：许多软件维护团队在一起并肩工作了若干年，养成了一套轻量的、反应迅速的方法。维护成熟系统的条件通常对于敏捷方法来说也是成熟的。

关于所有权的全部成本的详细介绍

接受敏捷性对于“保持轻量”系统是适当的这一观点，那么它是如何在一个 TCO 分析中工作的呢？同许多其他行业相比，软件开发较少的依赖设备，而更多的依赖人员。人员成本通常占项目总成本的50%到70%。通常来讲，敏捷能够简化人员需求，移除我们在传统的、计划驱动的方法中常常见到的人员管理费用。这从 TCO 的方面直接产生了财务收益。

图 4 中显示了两支团队的累积成本，一个是敏捷的，另一个是计划驱动的。团队成分和团队结构已经在上面的“ROI 变体 1”的模型中被给出了。

图 4: 随时间而累积的团队成本，一个用于敏捷的，另一个用于计划驱动的

敏捷对于保持成本和提高 TCO 是绝对有帮助的。在图 4 的例子中，节省成本超过 75 万每年，同采用计划驱动相比降低了 64%。这是真的么？当然是。此处给出的模型是现实世界中维护项目的混合，从瀑布方法提升为敏捷方法。

对团队成分的自底向上的关注，此时更能显示出保持敏捷性的重要原因。建造对于您的系统、团队和人员成本控制有意义的模型。留意在您之前别人所做的工作， 9 并且在您的业务案例中对其加以充分的利用。

还有一点十分重要，缩小团队的规模能够产生超出预想的效果。较小型的团队意味着较少的设备、较少的软件证书、较少的办公空间、以及较少的制冷和保暖开销。敏捷所具有的单元测试、测试自动化、以及持续的集成使得质量和生产率不断提高，而成本却不断降低。较小型的团队意味着较少的移动部分，改善的交流、以及灵活工作条件的更大机会。这些因素使得维护团队好像工作在一个“虚拟的大房间”之中，团队成员分布在世界的各个角落；改善的日常交流能够较少网站访问的数量。每一个好处都有助于提高运作效率，并且有助于成本的节省。

改善的竞争力

富有挑战性的经济环境使得公司必须更加注重固定现有的客户群，并且开拓新的客户群。在一个具有高度竞争性的市场中，对客户的需求会增长，而利润会缩小。如果您的公司依赖专卖的软件处理客户业务、驱动客户增长、或者支持客户满意的话，那么管理者将希望直到敏捷如何能够增强竞争力和客户体验。

对这一影响进行建模首先是定性的评估。举例来说，敏捷有没有通过更快递交付至关重要的新功能来帮助固定了关键的客户群呢？也许敏捷的快速转动增强了如阿建的质量，进而提高客户的满意度？

如果您已经做了一个基于 ROI 和 TCO 的健全的财务案例，提高竞争力的讨论也许就是蛋糕上的糖衣，您可以不去管它。然而，通过更多的作业和挖掘，特别是同销售人员和支持人员的协调，您应当能够得到一个改善的竞争力的财务影响的评估模型，并且作为额外的潜在回报加入到您的 ROI 模型之中。

通过信任展开处理过程

“大多数 IT 部门并不具有有效的交流和行销计划。在商业历史上，这些组织还是十分年轻的，他们的策略价值尚不是十分清晰。大多数技术人员还是从技术方面讨论问题。”

一个健全的业务案例是根据常识、财务影响、以及一个交付结果的已证明的流程而断言的。但是，对于一个健全的案例来说，最关键的一点就是：信任。

在一个不确定的经济环境中为敏捷制作案例，我们的关注点除了放在开发上面之外，也需要将同样多的精力放在管理上面。这种关注并不总是自然而来的。软件开发应该是优美的、令人鼓舞的、特别是全神贯注的。另外，我们大多有过这样的体验，只有集中精力和完全投入才能交付出色的软件项目；这种力量使得其他所有事情都变得不那么重要了，包括状态报告和管理流程。

软件开发是一项团体运动。团队中包括开发人员、设计人员、架构师、测试人员、以及发布工程师。团队还包括消费者、业务单元副本、以及计划管理者。团队还包括其他形式的管理：项目管理者、开发管理者、质量保证管理者、以及涵盖产品开发或者 CIO 的下至主管上至 VP 的经理主管人员。

正如今天所实践的，敏捷对于那些接近代码的人最具影响力。离代码越远，影响越小——客户、业务单元副本、以及经理主管人员并不关心敏捷的细微差别，只要它能交付结果就行。

所以在一个不确定的经济环境中，坚持敏捷也可能再次肯定信任关系。作为敏捷人员，我们频繁地向客户和管理层说“请相信我们”。我们不再强调那些客户和管理者测量进展情况所传统使用的工具，例如：项目计划、合同、以及正式的状况报告。如果那些东西限制了我们的处理过程的可见性，那么我们怎么能够建立一个稳固而持久的信任关系呢？

答案是开放处理过程。透明性是赢得客户和管理人员的一个强大的工具，并且根据输入来增强开发流程是他们的职责和权利。明显地，敏捷是面向结果的：区分客户需求优先级的工作软件的增量交付。但是我们不能陷入只关注交付这一陷阱。交付不是过程，而是结果。过程揭示了您如何到达那个结果。

我早期的一篇关于 Key Performance Indicators 11 （KPIs）的和 Goal-Question-Metric（GQM）方法 12 的文章推荐了一些工具，您可以使用它们以一种有目的的软件开发流程参与到公司的全部活动之中。这些工具被用来创建管理的入口，并且遵循精简开发管理标准。进一步地，应用程序周期管理（ALM）产品的集合在不断地增长。 13 它能够应用和自动操作这些工具，使您无需让敏捷团队承担那些耗时的报告任务就能够交付透明度。为了在恶劣的经济环境中最大限度地发挥敏捷的优势，请您向管理者和开发人员开放处理过程，并且赢得信任——不仅靠交付结果，而且靠展示一个稳定的、有组织的交付处理过程。