成功的根本—集成的ALM工具

现代商业流程越来越紧密集成：运输、制造和财务紧密结合为客户交付增加的商业价值，从而减少了费用。在过去40年里，自动化让商业流程得到进一步发展，它将各专业工具和实践集合成为一个整体价值链。客户往往希望只需提供完他们的信息一次；并随之假设你们的技术支持了解他们及他们产品的一切，并期望随之的交易是直接的，并私人化。尽管如此，用于创建和维护这些自动化系统的流程却比它们支持的系统来得更加分化和无系统。典型的软件交付项目会无数次地去获取需求，并在多个地方描述测试，但它们却与某一特定的构建里的具体内容并不相符合，因此项目往往需要大量分析来获知谁在做什么以及为什么做。软件生命周期管理（ALM），软件交付流程要比它所支持的商业流程不成熟得多。但是软件流程已经从辅助的商业流程升级为不可或缺的，它要求软件公司快速并直接地向客户交付高质量的产品。这意味着软件交付组织或团队必须开始考虑如何更好地集成他们的交付规则，设计出一个整体的、集成的ALM方法。

集成价值难以评估，但如果没有它，项目则无法成功

你曾多少次经历过这样的会议：每个人都在困惑地讨论着一些类似相同、却又不完全相同的东西？或者在会议的前３０分钟大家都在忙于弄清会议的内容？而且如果会议包含了来自不同部门、地域或组织的人，问题则会更加严重。现代软件交付团队是由来自多个不同地方的人组成，其中包括：开发部门，项目管理部门，商业部门，以及外包的测试机构。每个组织都采用自己特定的工具集，以及自己的实践和流程，而且这些全都根据自己团队内部，而非在端对端上进行优化。组织间的协作往往是项目当前运行团队的责任，比如：当项目主要由开发团队来运行时，开发团队负责分享故事和任务。当测试是主要关注点时，缺陷和问题则是沟通桥梁。而当单一团队在驱动某个阶段时，往往忽略了之前所有的工作，并排除其他团队的工作内容；团队间的空缺则由特定流程、电子表格和wiki来填补。其结果就是徒然的、让人气恼的会议；更重要的是，需要解决的问题往往被忽略了，从而导致了差劲的软件，不断增加的缺陷，以及昂贵的项目延迟。将所有人“集成”起来往往因为以下几个方面被否定掉了：

• 所有权--规定谁来负责某一领域的提高是简单的，但又有谁来负责两个领域间的交互呢？比如：应该由谁来负责提高开发和测试间的关系呢？没有明确的所有权，提高是非常难的。
• 地域上、组织间、以及政治上的边界--实际上，任何一个大型组织的组织架构在被管理和政治边界控制的同时，都在不停地演变。而想要打破这些障碍则非常难，因为我们所追求的东西如同协作一样无法具体掌控。
• 度量--软件交付一直被标榜为拥有差的度量，就连有限的度量通常也只关注某一特定领域，比如只关注测试，开发或计划其中一个。集成由于其自然特性难以度量，但没有一个明确的度量，又很难去关注或提高它。
• 惯性--改变从来不简单--它总是不确定，还有由于对来自领导层的低效改革的负面体验，大部分员工对它都怀有偏见，

管理和合规需要依靠一个综合的观点

不论组织多大，意识到任意时刻发生了什么，针对对象，时间以及涉及人员对于审计和合规是至关重要的。随着工作不断分配到各个部门，软件产品，流程，及具体人员，对任意一个或一组行为进行协调改变都将变得越来越难。举个例子：一个针对系统各项的安全需求涵盖了代码，测试，工作项，缺陷，可用软件，以及操作票等方面。如果该需求在中途发生了改变，一般很难度量到底是什么时候以及为什么发生了，更别说解决它所带来的影响。如果改变仅存在于代码中，那就会造成合规问题。就算组织不用遵守特定的政府规定，也应对影响、可追踪性和流程控制的有一份明确的度量来管理他们的流程。而可追踪性会被以下几点削弱：

• 用于存储信息的工具互不衔接。每个工具都存储着各自的中间文件，通常围绕着历史和版本管理有自己明确的机制。但是随着工作不断往不同部门延伸，中间文件间的联系却断开了。
• 可追踪性管理是笔巨大的费用。文档记录两个事物间的关系并不特别费时，但是随时更新那些具体度量和链接却很困难。
• 可追踪性元模型。项目中，当我们努力地在规定期限前提交软件的时候，创建文档看起来并不具有优先级。跨团队/工件间的文档纪录则更难找理由来贯彻执行。由于没有花费足够的时间来理解工作产品和文档因素间的关系，很难提供可追踪性，更别说去判断是否需要它们。每个项目都是不一样的，加上对敏捷方法的应用，项目可能会根据不同的问题领域或团队执行自己的流程。

最终都落实到数字

一个经常被引用的IDC研究表明公司每个员工每年在查找,却没找到的信息上大概要浪费3，300美元。当然，该数据很大程度上受到信息类型和人力成本影响。比如，一个C级高管为一份报告找些重要数据要比一个临时工查找一封邮件要昂贵得多。但是IDC研究是从整体上关注对正确信息的查找及它对生产力的影响，同时它也忽略了两个组织间巨大的协作价值（传统上两个组织间的信息往往不可见）。举个例子：通过连接开发和测试人员，现有需求可能会被重新评估，从而产生一个更灵活的解决方案。Daniel Moody和Peter Walsh在该论题上进行了一次研究，在他们的研究结果《Measuring the Value of Information: An Asset Valuation Approach》中讨论了信息所存在的不断提升的价值。他们提出：一般情况下，对信息的分享会加倍它的价值—越多的人使用，就会从中获得越多的商业价值。IDC研究同时也忽略了很多企业在法律和合规上的要求。比如：一个系统修改可能会造成安全诈骗，但是如果该修改没有被正确纪录，则可能会造成法律问题及相应的严重惩罚。

总体来说，由于数据没有集成所产生的代价可以划分为以下几类：

• 对正确信息的数据访问--除去依赖于IDC数据，还可能通过其它方式来评估没有正确信息所带来的影响。例如，在一段时间内给团队展示并研究在寻找正确需求，缺陷，代码元素，构建和发布信息上所花费的时间也可以完成这一目的。
• 收集信息--为了暴露问题因子所在，回顾为收集类似缺陷列表，需求状态，或任务栏等信息而创建电子表格或邮件上所花费的时间。
• ‘Ah-Ha’价值--这一点很难提供确凿的数据来证明，但是基本上可以通过回顾被集成的项目以及找出之前做过的某一特定修改或更好的决策来完成。
• 可追踪信息--比如你手头的X信息到底与什么相关联呢？举个例子，如果你有个缺陷，那应该能找到相应的描述具体原因及影响的需求和构建。没有可追踪信息可以被视为一个合规成本；如果可追踪信息不存在，在出现问题或公司无法提供合规证据时，组织就要对它负责任。

为什么要现在创建集成的观点

无可质疑的是软件项目通常都会有大量信息。每个部门都有自己的流程和工具来创建信息。更不用提复合应用了，其中每个应用都基于其它应用，信息的价值和复杂度也随之增加。缺少正确的集成信息所造成的内部损失是巨大的，不仅体现在生产力的流失，同时也体现在对安全关键系统可能造成的法律问题以及由此带来的硬伤。为了更好地管理集成的应用信息，应用程序开发人员应该：

1. 对信息建立全面的理解 —尽管为应用程序开发信息建立信息模型在很多人看来是浪费时间。但是，对核心工件及它们之间联系有个好的理解对建立ALM流程是至关重要的，也是完成该模型的关键。随着软件交付对商业越发重要，相应的管理报告也随之增加。反之，报告可以帮助定义ALM信息需求，为所需人员提供丰富的需求集。
2. 查看软件交付工具来获取重要信息—工具为开发的主要原则提供支持，却极少支持端到端的商业流程。在信息模型中描述的内容应该被支持，这就要求对这些工具捕获的信息及其衍生出来的数据有个清晰的理解。
3. 自动化集成—电子表格，邮件和白板是很好的沟通方式，可以清晰描述不同概念间的互相影响。但是如果对集成没有一个明确的自动化方法，则很难维护或管理这些联系。集成应该根据信息模型的规定建立于各工具间。

总结

现在公司内部大部分重要商业流程都已经被加强和自动化了。这一改进为数据模型，仓储，集成技术以及中间件平台带来了协作。软件交付是个日益重要的业务流程。尽管如此，和传统流程相比（比如：航运，客户关系管理和会计），其相关基础设施和流程规范还很不成熟。将客户信息调整集成到会计范畴并不难，但是需求与测试间的衔接却总是难以协调，取而代之的是对手动流程和团队间隐晦知识的依赖。随着软件的重要性不断提升，系统也越来越复杂，这些应用的生产力和质量却因为缺乏集成的信息而不断降低，随之其直接商业价值也会不断下降。是时候进行集成的应用生命周期管理，它是长期应用、项目和商业成功的关键。

关于作者

Dave West是Tasktop首席产品官。根据他在这方面的能力，目前他紧密地与Tasktop的客户和合作伙伴协作，致力于Tasktop的产品路线蓝图和市场定位。作为公司高层管理团队中的一员，他在Tasktop的商业转型上起着重要作用，该举措也为软件行业带来了重要的进步。作为软件开发和部署行业最杰出的专家之一，West一直致力于众多软件开发流程的提高，其中包括统一软件开发过程和敏捷方法。他经常在各主要行业会议上作为嘉宾发表演讲，同时也广泛发布了众多文章和研究报告，他所著的《Head First Object-Oriented Analysis and Design》备受赞誉，帮助定义了新的软件建模和软件开发流程。他曾领导过IBM/Rational的Rational Unified Process（RUP）的开发。之后他又回到顾问行业，管理Ivar Jacobson Consulting的北美区。在过去四年来，他一直担任Forrester Research的副总裁和研究总监，在那里，他同领先的IT组织和解决方案供应商一起定义、驱动并提高企业中的敏捷方法论和工具的突破。

查看英文原文：Integrated ALM Tools Are Fundamental to Success