论软件生命周期集成

多年来，软件交付被视为辅助的业务流程。尽管软件交付花费了企业大量的成本，但是它始终没有成为企业业务的关注点，因为它不像供应链管理、 财务管理、人资管理那样具有一套严谨的系统架构。

但是，随着越来越多的企业把软件交付作为业务运作的关键环节，创建、实现、开发和维护软件就变得尤为重要。尤其是，伴随着移动技术、云技术以及开放式网络的出现，软件变得越来越复杂。不仅软件创新能形成竞争性优势，而且如果能够比竞争对手更快且以更低的价格交付软件，那将具有真正的商业价值。毕竟，更重要的往往不是谁先有新产品或新服务的想法，而是谁先进入市场提供这种产品或服务。

软件交付串联了多个独立的过程，而不仅仅是一个单一的集成过程。

软件交付不仅是一个数十亿美元的产业，并且是主体业务流程的内在诉求。交付软件的能力能够推动业务创新，也能阻碍业务的创新。软件进入市场的时间、创新能力和质量，将成为决定公司竞争力的要素。相比其他传统的业务流程，软件交付没有成熟的模型，只是不同技术和工具的无序集合。

投资组合规划、项目管理、需求、设计、开发、测试和部署都有各自良好定义的流程和工具，但他们不能有效整合、协作、配合顺畅。同一业务在其整个生命周期中被定义了无数次，从规划设计阶段，到定义、开发、测试，各个组都根据自己的需求和工具重新定义项目构件。电子表格、邮件和维基（wikis）是用来整合所有过程的，这些工具不但又是一笔开销，并且它们通常又会建立另一套系统来记录生命周期过程及其集成。

精益创业 (Lean Startup)、 运维开发 (DevOps) 和敏捷开发（ Agile）等方法会促使组织重新评估他们的开发实践活动，以实现加快节奏和增加反馈的愿望。虽然许多组织已经采用了敏捷模式，并试图应用运维开发 (DevOps)，但这些举措的重点都在于工程团队及他们的实践活动。

业务敏捷（Business Agility）要求通过工程、管理和客户流程这样一个工作流与业务无缝集成，但这与我们今天所见到的情况相去甚远。

以下两部分勾勒出我们今天的现实：

不相关联的专业越来越精简，但不太精益

Henry Ford 和工业革命告诉我们，将分工和部门的层次结构做专业的划分，是提高效率和集中度的最好方式。一旦问题变得更复杂，组织也会随之变得复杂以解决问题。随着 IT 队伍规模的扩大，他们的流程、管理结构和层次结构也会相应增长。随着时间推移，学科发展超出了开发人员的能力范围，创建了独立的工作组，譬如需求、设计和测试组。敏捷开发（ Agile）将这种独立工作组视作项目开发失败的关键原因，并要求建立跨职能团队。而现实是，即使在同一个团队，不同的角色会用不同的方法、不同的措施和工具去解决同一个问题。

即使在敏捷（Agile）团队中，开发人员和业务分析人员也会使用不同的工具，鼓励不同的工作方式。传统的测试工具将从测试的角度来描述问题，而开发工具会从开发人员的角度来看待问题。这些工具通过引入不同的词汇、控件和处理步骤将软件交付分割成若干个过程。过程改进通常是在功能单元的层次，而不是跨越整个软件开发和交付过程。

试想，有一个工厂将生产过程中的每个步骤进行了优化，但该厂产品仍然质量低且过于昂贵。这是精益创业（Lean）生产革命之前，汽车制造商的经验。Henry Ford 的传统生产模式在管理过程变化、产品复杂性和产品灵活性方面存在缺陷，而这些都是现代汽车制造所要求的。精益创业（Lean）方法的采用，意味着从整体的视角来看待端到端的过程，这在企业层面而非部门或具体职位层面，能让组织减少浪费，增加价值。

这也势必会引导清晰的过程所有权、体系结构、自动化、体系结构的建立——而这些概念在软件开发行业还很缺乏。

在软件开发中，我们仍然有：

• 在端到端的过程中，缺少所有权。如果一个组织没有做整体考虑，这样的话，整个过程的所有权就将被分割到若干的小组中。例如，质量组做测试、业务分析组做需求，而报告由 PMO 来完成。这样的分割让所有人都没有了从整体上改变的意愿了。
• 没有清晰的系统架构和路线图用于提升水平。个人和团队实施新技术和相关实践，以使他们的工作更简单，在相关的软件交付实践过程中，他们大量采用了独立的实践和工具，但没有清晰的路线图或是与技术相关的计划，这笔投资将是没有计划性并且是不明智的。
• 缺乏过程自动化。在大多数软件开发和交付团队中，仍然存在着过多的手动步骤和过程。想想看每周状态报告，这些报告是跨部门决策和组织中枢的关键。而做这些报告需要大量的电子邮件、登记签到电话，并且需要创建电子表格，这样既不准确，也不完善。事实上，手动步骤由于存在重复性任务，对此的改进，将是过程实现自动化的一个显著指标。

端到端的报告及其可追溯性仍然是一个梦想

现代企业都是基于数据做决定的。从日复一日的运作，到企业规章和法规的遵从，企业都是依靠复杂的仪器和报告能力。软件交付的过程，就像其他的业务过程一样，需要追踪和报告。但和其他业务过程不同的是，软件交付过程没有一致商定的过程或数据模型。除非组织要建立一个安全的决策系统，否则，在描述软件交付过程中产生的流量、影响、生产率、质量和价值的报告上，没有必要达成一致意见。

这是一个有趣的难题。没有达成一致的报告，是因为我们不知道用什么来衡量吗？或者我们不用报告，那么要用什么来衡量呢？

正如我们之前所指出的，在软件交付生命周期内所使用的工具是相互隔离的，并且其中有大量的手动过程，这是自动化所要避免的。手动创建状态和可追溯报告需要花费很多时间，并且需要多人参与。在大型项目，或是地理上分布很广的项目上，这所需要花费的时间，最终降低了信息的价值。例如，常见的情况是，和一个外包测试合作伙伴共事，使用有缺陷的电子表格工作。这个有缺陷的表格在每日工作结束时发送，但版本往往由不同的团队在不同的时间更新数次，这会导致许多会议。这些会议往往由“我们根据哪个版本的电子表格工作？”开始，并会导致对每个版本差异的讨论。

现在，让我们来看看在软件交付生命周期的连接。

软件交付业务流程需要自动化

随着软件的价值和重要性的增加，很显然，下一步就是把它视作一个关键的业务流程。像接近其他过程——如销售，采购及分销——一样进行软件交付过程，你以不同的方式执行软件交付，不仅包括它所包含的过程，还有价值、报告和分析。这样你将会有一种端到端的整体视角，而非独立地关注每个学科。最终，过程的价值不存在于每个学科里，而是存在于用户或 业务所用到的软件里。

软件交付的工作流应该从建立开始到实施结束

软件交付包含许多过程，包括软件生命周期（SDLC）管理、项目管理、需求管理、质量管理、操作和服务管理。对于许多组织来说，这些过程有准则、模板、工具和过程组件。事实上，许多过程包括很多相同的组件，如缺陷、要求和任务，以及敏捷（Agile）的故事和诗歌。不幸的是，这些过程如何互动，许多组织都没有整体的流程模型或形式化描述。

事实上，即使在争取连续交付的组织中，一个“连续”的事情就是交付最后的工作产品：代码和应用。但在项目工作流中，仍然存在从一个项目功能组件到另一个项目功能组件之间的不连续性。

由于软件交付将为产品提供代码、服务和 APIs 的供应商们越来越多地集合起来，所以形势就变得越来越严重。随着 Web 服务和 API 驱动的开发，供应链往往松散，再加上控制有限，并且没有一致的过程或 ALM 工具集。另一个例子是外包测试。这些测试组难以成为项目的一部分，因为他们分属不同的组织和不同的地区。但他们的信息必须融合在同一项目内以确定项目的真实状态。

分析和报告至关重要

如果你问一位 IT 项目经理小组，对于软件组织而言，什么是关键的度量指标？你会见到一系列非常不同的度量方法，例如缺陷数量策略（number of defects to the strategic）、状态随时间改变等。不仅应用程序开发专家需要定义正确度量办法，他们还需要看到状态是如何随时间改变的。对于许多工具来说，时间或基于时间的数据不难发现，只要用那些关注于即时工作流的工具就行了。

软件生命周期的整合将“L”置于应用程序生命周期管理中

对于管理应用程序开发和交付过程而言，不需要清晰划分每个阶段的要素，一些组织没有一个生命周期的全局视角，是因为他们的基础工具是由不同的产品组成的，旨在提高更广泛的组织中的一个（或两个）职能团队的效率。

对许多组织而言，应用程序生命周期管理意味着采用一种工具，或者一种工具套件。这将允许跨越不同学科的信息正常化，并支持常见的报告和分析。厂商给市场和销售人员灌输这样的思想：当你使用某某工具，那么所有的开发问题将迎刃而解。然而对许多组织来说，现实更加复杂，而非一种工具能够解决。添加移动技术、云、开源代码、横向工具等等，到新兴的平台上，将永远很复杂。必须集成现实中所采用的各种异构工具。

尽管如此，“一体化”并不是两个系统间点对点的简单连接。整合组织广泛使用的工具，正是出于软件过程改进的需要。

• 一种能够跨越所有学科的常见数据模型，以调和它们所生产的组件的差距。
• 将工作流添加到模型中。由于应用程序生命周期管理（ALM）实践的做法是跨工具，并且工作在工具之间切换。就过渡而言，捕获从一种工具到另一种工具的切换，这非常重要。举个例子，如果门票从服务台转向开票部门，那么捕获这个过渡，是理解从操作到创建队列的关键。
• 对项目、产品和版本的理解。在很多组织中，应用程序、产品、项目和版本往往交替使用，导致混乱。对其确切含义，全行业没有共同的认识。每一个公司需要创建自己对每个概念的明确定义。有效的应用程序生命周期管理报告，需要对双方资产和时间元素的任何数据模型，有一个明确的定义。
• 资源 /用户和团队。一旦进入了项目组合管理、开发和运营的世界，就了解了对报告和分析工作而言什么是重要的，且谁在为之工作。对许多组织来说，用户名的结构、团队标识，甚至于部门代码，每个团队都用得不一样。介绍一个可以跨工具边界的、一致的方法给用户用于报告分析，也有助于确保治理和控制更有效。

启用这个跨学科的软件生命周期集成和工具，将为组织提供必要的基础设施，让他们在其关键的业务流程——软件开发和部署上，实现自动化分析和报告

对于许多组织而言，是否有综合性的软件交付实践决定了项目的成败。此时应该将精益思想（Lean thinking）应用到软件交付的实践中，并创建和维护从构想到到实现的软件流，消除断点，实现实时协作。同时要创建一个端到端的软件交付实践规范。该规范必须为连接软件交付实践提供必要的材料，为软件交付实践专业人员提供创建集成体系结构和测量方法，以使软件交付更迅速，并消除实践过程中不必要的麻烦。

作者简介

Dave West 是 Tasktop Technologies 的首席产品官。他对 Tasktop 的变革起了重要作用，这推动了软件业的前进。他引领了该公司产品线的政策方向，并帮助 Tasktop 做了市场定位。他是一位前 Forrester Research 行业分析师。点此联系Dave。

参考英文原文： The Case for Software Lifecycle Integration

感谢侯伯薇对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。