论软件生命周期集成

论软件生命周期集成2014-08-18 infoq Dave West 译：江舒多年来，软件交付被视为辅助的业务流程。尽管软件交付花费了企业大量的成本，但是它始终没有成为企业业务的关注点，因为它不像供应链管理、财务管理、人资管理那样具有一套严谨的系统架构。

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

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

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

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

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

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

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

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

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

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

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

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

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

在端到端的过程中，缺少所有权。如果一个组织没有做整体考虑，这样的话，整个过程的所有权就将被分割到若干的小组中。例如，质量组做测试、业务分析组做需求，而报告由PMO来完成。这样的分割让所有人都没有了从整体上改变的意愿了。

没有清晰的系统架构和路线图用于提升水平。个人和团队实施新技术和相关实践，以使他们的工作更简单，在相关的软件交付实践过程中，他们大量采用了独立的实践和工具，但没有清晰的路线图或是与技术相关的计划，这笔投资将是没有计划性并且是不明智的。

缺乏过程自动化。在大多数软件开发和交付团队中，仍然存在着过多的手动步骤和过程。想想看每周状态报告，这些报告是跨部门决策和组织中枢的关键。而做这些报告需要大量的电子邮件、登记签到电话，并且需要创建电子表格，这样既不准确，也不完善。事实上，手动步骤由于存在重复性任务，对此的改进，将是过程实现自动化的一个显著指标。