实现软件生命周期整合（第 2 部分）

一步一步指导你实现整合软件生命周期管理流程

在本文的第 1 部分，我们讨论了软件生命周期整合（SLI）的价值与重要性，以及整合软件交付价值链可以将计划、分析、设计、开发、测试及运维等学科关联在一起的好处。我们同时强调，如果企业想要完全利用软件体系的优势，他们就需要把软件交付作为业务创新中的关键步骤。在这篇文章中，我们将关注软件交付专业人员在关联端到端的软件交付流程时应采取的一些实用步骤。

当你在软件交付流程中进行某些改变时，很重要的一点是，你不仅要关注每个学科各自的情况，还要将它们关联在一起。但是，实现这一点需要进行全盘性的改变，而这种全盘性的改变不仅要通知到每个学科的负责人，还需要这些学科之外的管理者为驱动这次改变承担责任。找到负责人、建立商业案例、并以一种可控和可测量的方式从这次改变中交付商业价值，以上只是所有必须步骤中的一部分。如果没有这种全盘性的改变，软件交付始终是一个问题，它也无法交付行驶在“软件时代”时所期望的商业价值。

在你的组织内实现 SLI 的三部曲

如果软件是业务流程的关键一环，那就必须认真地对待它——必须建立起清晰的关注点、主导权与良好的设计。建立这一流程的实践正逐渐呈现为应用程序生命周期管理（ALM）中的一种新学科，它并不专注于交付软件，而是专注于制造及维护软件的过程。这一点有点类似于航空业的改革途径，它从工业革命中获得了更多的系统性工程实践经验，但它们之间有一点显著的区别：它产生结果的流程与传统的工厂不同，倒更像是电影拍摄场地，在那里清晰的信息被共享给参与项目的所有学科。由于对加快交付软件的需求一直在增长，自动化也在流程中扮演了重要的角色，它联合了不同的学科以及他们各自所使用的工具。它不仅支持更好的协作，同时也使得为管理阶层提供清晰的报告成为可能。

第 1 步：创建自动化集成的案例

和任何改变一样，要在组织内应用 SLI，获得管理阶层的支持与认可是非常重要的。“自动化”或许是建立一个有说服力的案例最容易实现的奠基石了。通过将各种工具自动地关联在一起，企业得以减少浪费，增加价值。开发与测试之间的整合正是证明这种价值的一个很好的例子，开发与测试团队通常会使用不同的工具，执行不同的流程，导致最终的整体流程通常没有关联性、速度迟缓、易于出错，并且经常发生冲突。通过在缺陷与各种支持性的任务协作之间建立起自动化的关联，企业就可以消除对人工流程、电子表格与 email 的需要了。这一商业案例非常简单，由于人工流程很明显需要花费操作成本，当它被自动化所代替之后，这一 SLI 的案例就成功建立了。建立这个商业案例需要达成以下几点：

• 在整体上对当前各学科互不关联的状况以及因此造成的浪费有所了解。在软件开发的过去 50 年间，企业以改进的流程与工具的形式对各个学科进行了优化，这些改变确实对软件交付有所改进，但是同时，开发软件也需要一整个团队（甚至是一整个部门）的努力，而那些在学科层面所做的优化，往往意味着各学科之间巨大的分离性。因此若要改善流程，软件交付专业人员必须集中关注各学科之间的分离性。
• 对浪费情况进行衡量。一旦找出了这种分离性之后，下一步就是以金钱和时间的节约程度对其进行量化。比方如，如果去掉了某个人工步骤，可以节约多少时间、多少精力？一旦计算出详细的可节约的内容，那么就可以调整整合的各种投入了。
• 理解自动化所带来的无形收益。并非所有的收益都可以直接用金钱和时间来表示，但它们仍然存在价值。这些收益包括更好的管理与灵活性。另外，自动化也促进了人们更好的协作、减少错误，并提高了快速找到各种信息的能力，在这些地方无形中节省了时间。以上所有这些收益对整体的流程起到了重要的影响。

关于建立整合的商业案例，请点击这里查看更详细的描述。

第 2 步：建立 SLI 团队

软件交付的业务流程与其它关键性业务流程一样，都需要自主权、正确的策略以及恰当的实施。建立一个包括技术领导与领域专家在内的跨学科团队使得企业能够控制软件交付的价值链。但团队还需要展示清晰的任务以及一系列的目标，以此获得行政管理者的支持，从而有效地驱动软件交付业务流程的改变。SLI 团队应该包含来自不同学科、不同职能领域的人，并且应该包含这几种角色：

• ALM架构师。和其它流程一样，ALM 也需要一个定义清晰的架构和路线图。这一点需要 ALM 架构师不仅能够驱动整合策略，并且驱动整体的信息、流程和工具的策略。通常这一角色由来自企业架构团队（EA）的人员担任，这一团队能够分配那些关注于工具链的资源。选择一位来自 EA 的人员的好处是，他们往往与通用 IT 策略部门人员有所关联，并且理解平台及技术路线图。工具经常与平台保持着密切的关系，因此 SLI 与平台技术之间的关联将确保 ALM 路线图中已经考虑到了长期的平台方面的决策。
• PMO/资源经理。就像企业架构为 SLI 与通用技术策略之间建立起链接一样，项目管理经理（PMO）则在流程、资源与治理模型（governance model）之间建立起了联系。PMO 不仅需要整合 ALM，而且软件交付组织的性质通常也是由 PMO 决定的。
• 行政领导。SLI 的核心是企业对改善软件交付能力的需求。这一工作需要由行政领导带领展开，因此他们需要对团队进行直接领导，从而在组织内交付价值。
• 学科领导。无论是测试、需求分析、开发或运维，他们都会在 SLI 中体现存在感。每一个学科都将带着他们各自的观点、对工具的了解以及对各自学科实践的理解。虽然 SLI 通常是由某个小组驱动的，但实际上他们的价值已经整合到了一起，这种流动的软件交付价值链比起单一的某个学科能做到的要好的多。因此，让所有学科都参与其中，就有可能驱动整个价值链的根本性的积极变化。

第 3 步：快速交付价值并进行衡量

我们经常说“空谈不如实践”，而 SLI 也和其它任何驱动改变的努力一样，只有当生命周期的某些部分实现了整合，并且信息以一种自动化的实时方式在各组之间进行流动后才会体现价值之在。因此，对每个刚成立的 SLI 团队来说，快速交付价值是非常关键的。最好的 SLI 创始团队会尝试为整合工作引入一套敏捷流程：定义工作的 backlog 以及清晰的、可衡量的成功标准，并将软件交付结构化至多个能够产生价值的 sprint 中，每个 Sprint 都能够交付可见且可衡量的价值。这种途径使得团队可以以一种增量式的方式理解他们正在解决的问题。举例来说，在测试与开发两者之者也许会以缺陷的形式存在着某种关键的整合。当交付了这种整合之后，就能够衡量它是否成功，并且对两种学科之间的整合方式加深了理解。这一过程通常也会揭示一些本质性的流程上的挑战或者误解，解决它们通常需要改变某个流程映射到另一流程的方式。增量式途径的另一个关键好处是，它允许团队为行政管理人员展示他们创造的价值，并依据反馈对工作方式进行调整。连续的整合会促进不断的成功，带来更多的价值，最终为软件支付实践带来巨大的改善。每个 sprint 或者迭代都应包括以下内容：

• Backlog——整合、报表及分析都应该被分解为一系列的“用户故事”。这些故事会驱动工作的进展，并促进团队专注于以易于管理的、可直接使用的分块形式交付价值。
• 可衡量的价值定义——团队能够以一种系统化、结构化的方式为企业交付价值是非常重要的，这也意味着对每个交付的用户故事，都需要存在一种清晰的衡量系统。
• 沙盒（sandbox）——并非每个 sprint 都需要为生产环境中的系统交付价值，有些 sprint 可以交付至一个沙盒中，它为展示新的整合流程以及它们的工作方式提供了一个独有的环境。整合的本质决定了它将为每个学科内部的流程带来改变。使用一个沙盒环境，SLI 团队就能够为将受到此次改变影响的各学科做一些预先的展示了。

实现软件生命周期整合的时机已至

实现 SLI 的三部曲并不出人意料：建立商业案例、搭建出色的团队，以及交付价值并对其进行衡量。而往往对各学科的集成、对人工流程的替换以及取消对复杂的电子表格和审查流程的需求这几方面所带来的价值令人感到吃惊。由于软件带来的商业价值总体上正在日渐增加，因此对创建并交付软件的流程的关注与重视程度也在日益提高。与之相伴的相关课题还有敏捷交付技术，以及转向移动平台及云端的机会。在此大背景下，许多企业积累了足够的动力，在它的软件交付能力范围内进行改变。但是某些企业的 SLI 团队可能才刚刚成立，要想做出成绩还有一定的困难。这时他们就可以参考敏捷或者 DevOps 这些现有的方法，以鼓励公司消除各团队、部门以及学科之间的鸿沟。

关于作者

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

查看英文原文： Implementing Software Lifecycle Integration (Part Two)