相对于ERP（Enterprise Resource Planning）和CRM（Customer Relationship Management）而言，软件应用生命周期（ALM: Application Lifecycle Management）是比较新的概念。过去几年间，这方面的研究日新月异，相关的讨论也逐渐热烈。本篇文章主要是和大家分享，笔者在过去十几年，对于 ALM行业演进的亲身感受；并分享在挑选ALM工具时所应关注的几个产品特点；希望达到抛砖引玉的效果。

1995年我在美国从事IT工作时，曾以咨询师的身份加入一个几十人的研发团队。当时Jeff是我们的项目经理，所做的项目是用来 给汽车厂维修汽车 时，做报修估价用的。刚加入团队的时候，我问Jeff：“这个项目什么时候可以完成？”Jeff回答的很自信：“一年半的时间，你就可以看到这个至今为止 全国独一无二的产品推向市场。”很快一年半的时间过去了，我看着团队人数由最初的15人增加到45人，但项目并没有完工的迹象。我又问Jeff：“产品要 推向市场了吗？”Jeff回答：“项目完成的时间很难估算的。大概还需要半年时间吧！”但是半年过去了，项目还是没法发布。紧接着又过了一年，Jeff宣 布说：“产品新功能在开发期间不断增加，以至于很难把握项目的进度。但竞争对手的产品也快完成了，我们不能再等了，只有强行把产品先推向市场了。”由于产 品发布完成，不久后，我便离开了该团队。

市场不断地反馈对该产品的新功能需求，该公司在一年后，重新找到我，希望我为产品添加新功能。该团队人员因我早年参与了项目的设 计，问了我一些跟产 品历史有关的问题。我说：“当年我们写的某设计文档可以回答这些问题，Tom应该有这文档。”当我去跟Tom要这文档时，他说，该文档当时被交接给 John了。John却说，Dianna后来对文档做了修改，且放进团队的服务器了。但我们几人不论如何，都找不到那文档了。那文档就这样消失了！

我第三次再回到该公司时做的是该产品的维护工作。产品经理告诉我：“虽然该产品是最早推进市场的，但现在全美的市场占有率，却排在另两个竞争对手之后。主 要原因是两个竞争对手的市场嗅觉灵敏，他们总是能比我们更先知道什么新功能是客户最需要的。而我们只能在别人的产品发布后，才匆匆忙忙地把新功能抄袭到我 们的系统里。”我问他：“为何我们没能先发现市场所要的新功能？”他答道：“修车厂的管理人员，由于和客户打交道最多，得到的信息也最真实，是最早嗅到市 场所要新功能的一批人。他们通常会打电话把需求告诉我们。但需求的数量成千上万，我们很难判断哪个重要哪个不重要。而且，由于接电话的人专业能力不足，写 下的需求往往失真，也很凌乱。需求反馈的周期也因此被拉长”我听了后建议该产品经理，专门设计一个网站，用来收集和分析客户的需求。可以让修车厂的管理人 员，客户和项目组的成员都参与到网站的信息反馈，帮助项目组了解客户最需要的新功能。该经理欣然地接受了我的建议。但这么晚才做此调整，可能已没法挽回局 面了。

上面我所经历的故事，其实在90年代，是一个普遍现象。即便是在美国这样IT高度发展的国家，人们对研发过程管理也是没有任何概念 的。市场上一般的 工具就是编译器、开发平台和自动测试工具。因为没有研发过程管理工具，项目常常到最后失控。1995年，The Standish Group调查了全球352家软件组织的8000多个软件项目。调查结果表明：31%的项目在完成前被取消，浪费800多亿美元；53%的项目消耗了 189%的预估成本，平均时间是原始估算值的222%。只有16%的小企业和9%的大企业按时交付了软件产品。

软件业经过了这十几年，软件应用生命周期管理的领域已发生了巨大的变化。过去这些年，软件的大小呈级数增加。现在一个项目团队有上 百人已不是很稀奇 的事。随着项目的变大，一个团队对其人力资源、文档、代码，乃至于经费、时间等等的管理，必需借助一套科学且具体的方法。而对这些因素的管理，若要到位， 则必需借助使用恰当的工具。正因为这一系列的变化，使得需求管理、项目跟踪或发布管理之类的管理工具在90年代开始被一个个地推到市场。到现在各种工具已 算相当全备了。我以为，若要选一套合适的应用生命周期的管理工具，一定要注意它是否具备下列特点：

• 整合的系统（Integrated System） – 现今针对软件应用生命周期中各个阶段的工作管理，虽然可选的管理工具颇多，但它们多半是由不同的公司开发出来，且是各自独立的。这至少造成了以下两个问 题。第一，各阶段的数据不能被共享。举例来说，同样的需求会在需求管理工具中记录，又同时需要出现在缺陷跟踪工具里。若要把这些数据要从一个工具拷贝到另 一个工具，不但在时间上有延迟，同时在费用上也会增加，而且发生错误的可能性也变大。第二，项目执行的流程无法被固化。由于工具是各自独立的，工具间的流 程自然是没法被固化的。如果我们能够找到一套整合的系统，这些问题势必迎刃而解。不但解决了软件应用生命周期中各个阶段工作的管理，而且也解决了阶段性数 据的共享。
• 项目的透明度（Visibility）要高 – 由于项目包含了庞大的数据，参与者往往都在雾里。对于关键的数据，看似存在，却无从提取。就如前面故事里的项目经理Jeff，他无法对项目的成本、所需人 力以及时间等等进行合理的估算。由于缺乏真实的数据支撑，公司决策层对项目的投资报酬率不清楚，对整体策略步履蹒跚。其他如缺陷修复现状、缺陷率、任务完 成时间估算和任务现状等都是项目里提高透明度的一些指标。这些年被敏捷团队所津津乐道的任务时间估算方式是以Burndown Chart来实现的。Burndown Chart通常以时间为横轴,以未完成的工作为纵轴。它显示随时间推移,项目中还剩下多少工作未完成。从而帮助项目管理层掌控项目的执行进展。
• 可追溯性（Traceability）要高 – 理想上，项目成员在生命周期管理系 统中，可将相关的文档（包括需求及参考资料等）、测试用例及代码等建立链接，并有办法从其中的任意一个节点，追溯到其他 的相关条目。如果生命周期管理系统的各个子系统不是整合的，那这种追溯事实上是不可能完善的。在上头的故事里，Tom、 John和Dianna把重要的设计文档丢失了，就是因为只是单纯的将文档放在服务器上，而没有保存到管理系统中管理，造成无法追溯。在实际的项目执行 中，最常发生的例子可能是，研发人员要修复某个缺陷，他常常需要找出原本的设计文档及其他相关缺陷的修复状况。知道了来龙去脉后，他便可以很准确地完成他 的工作。
• 自动化（Automation）程度要高 – 在项目的执行过程中，很多机械性的工 作是可以经由软件系统自动触发的。最常见的例子是，当经理在工作流程中把某研发任务交给某个研发工程师时，一个电子邮 件（或短信）就应该自动地邮寄到该工程师信箱（或手机）里。另一个例子是，某个项目要由10个委员在2周内评估完。在2周截止日前3天，系统也可以发个电 子邮件通知提醒委员们“只剩3天了”。如提前评估完了，相关人员应该收到电子邮件通知，以便安排下一步工作。若过了截止日期，而评估仍旧未完成，系统也可 以发电子邮件，并列出未完成评估的人员。通过引入自动化的机制，势必降低了项目的人力管理成本，同时也提高了项目的执行效率。

除了这些特点外，还有两件事值得一提的。第一，数据的量化和分析是整个平台的基础。比如说，一个项目里有上千个各式各样的需求，我 们如何界定哪个该 做？哪个不该做？优先顺序又是如何？一个可行的办法是，将这些需求划分到可能的几个方案里，由相关人员投票决定要选哪个方案。在被选上的方案中，各个需求 的优先次序再被界定出来；达到项目方案的分析量化。其它可以被量化的至少还包括人力资源管理、变更管理、缺陷管理等等。

另有一个值得一提的新概念是Wiki在需求管理上的应用。Wiki的基本理念是参与者可以自由地浏览、创建、更改文档。这使得团队 协作更加快捷流 畅。但一般的Wiki工具并没有权限控制。在实际的项目操作上，这可能会造成颇为严重的问题。我知道有几个研发团队曾试图采用免费的Wiki工具来编写需 求文档。但经过实践，他们放弃了。主要的原因是，Wiki工具并不能和团队使用的其他管理工具互通，还有就是权限控制的问题。但不论如何，我相信商用的 Wiki工具将会被大量的使用，也会成为ALM管理工具里的需求管理的重要部份。

现今不论是国内还是国外，ALM管理工具还是处于早期发展阶段，供应商也在摸索着找出市场能接受的路子。大致上看来，最早接受此类 管理工具的团队有 以下几类：（1）敏捷团队- 敏捷方法是以快速接受（需求）变更著称的。但过快过多的变更也可能导致项目失控。而且，敏捷团队一般以7到10人为佳。当团队人数多于这上限时，沟通开始 不易通畅，敏捷的种种优点也必淡然无存。使用ALM管理工具来追踪变更，并提供一个团队成员间沟通的平台，可以显著地减少这些问题。 （2）以过程为中心（Process-centric）的团队 – 对过程的控制极为严谨的团队，诸如制药厂和航天电子设备，依赖工具来保证其过程没有偏差。（3）分布式团队 – 如果项目的需求、测试及编码是由在不同地域的人共同来完成的，那他们之间的沟通和协调也是需要有个平台。因此，对ALM管理工具的需求也就大了。（4）嵌 入式系统的研发团队 – 这类团队同时要处理软件和硬件的研发。典型的嵌入式团队可能有设计、软件研发、软件测试、硬件研发和硬件测试等小组。小组多了后，它们之间的协调和沟通的 复杂度呈级数增加，因此也需要有个沟通和协调的平台。

很可能，未来ALM管理工具的发展依旧会围绕这四类客户的基本需求。但有一点我们是知道的：随着客户要求的不断提高，未来在项目管 理中引入ALM管 理工具的角色将不仅仅是战术性的，更可能提升成战略性的。这意味着，当工具里累积了足够的项目，它的数据将成为企业的智囊库，可作为后续项目在周期、成 本、人力及风险管理等方面的重要参考。有前瞻性的公司会用分析结果（如投资回报率）来决定项目的优先次序，并找出公司未来的市场方向。