针对软件开发的精益管理——如何利用DevOps

　　DevOps 是一种精益应用程序

　　DevOps 旨在更好地集成 IT 操作和软件开发，从而提高对业务更改的联合响应能力。这些业务更改可能包括对某个问题单做出响应或者提供业务所需的新服务。DevOps 旨在完成以下目标：

• 缩短某个更改请求变成可接受响应的时间。
• 减少实现更改服务而浪费的时间和精力。
• 在从操作到开发再到部署的整个阶段中实现更加流畅的请求。
• 平衡企业解决需求的能力。

　　这和采用精益计算原理（称为精益技术）的目的相同。可以将精益技术描述为一种思维方式和一组技术集合，它们可用于管理和改善端到端周期时间（或交货时间），并充分利用某个企业的能力来优化整个流程的资源流（库存）。Lord Kelvin 提供了一个人们所熟悉的短语 “测量就是为了发现”，通过测量来了解精益可视化技术（如 价值流程图（value streaming mapping），包含产品流测量）带来的影响。流测量包括对库存进行端到端（黑盒）和分步（白盒）测量，测量流程时间，以及成品花费在存货阶段（等待处理）的时间。

　　最近，IBM 进一步扩展了 DevOps 最初的定义范围，包括了以下原则：

• DevOps 代表企业实现持续软件交付的能力，使企业能够抓住市场机遇并缩短客户反馈时间。
• 它跨生命周期并跨企业地扩展了精益和敏捷概念，在所有环节实现了更丰富的反馈周期。
• 在整个企业范围实现精益转换能够支持更高效的交付，持续的反馈则有助于更有效地确定工作方向。
• 采用 DevOps 帮助企业在实现交付速度和可靠的结果之间取得平衡。

　　从这一点来看，可以推断出以下结论：

• DevOps 旨在精简扩展后的包括软件在内的生命周期，比如：
• IT：从问题识别到成功解决。
• 实现持续工程：从嵌入式软件规范到成功的集成。
• 产品开发：从最初的理念到成功推向市场。
• 服务交付：从提出业务要求到令客户感到满意。
• DevOps 就是将精益原则和实践应用到这些方面。

　　过去，精益原则一直应用于制造业、后台流程和物流业。这些流程具有更好的可预测性，与 DevOps 所支持的流程相比缺少变化。对软件（Poppendieck 和 Poppendieck，2013）和一般性知识工作（Odegard，2013）应用精益原则并不是什么新鲜事物。本文对已有的实践做法进行了扩展，将 DevOps 作为一种以工件为中心的业务流程，这样就可以将精益实践和测量顺利应用到 DevOps 流程。

　　在应用精益实践和原则时，必须增强流测量以检测瓶颈和低效率事件，从而找到机会进行改进并采取措施。以工件为中心的一个关键优势是可以很容易地指定和增强流测量。

　　以下小节介绍了这种以工件为中心的观点以及为什么应用于 DevOps。您将了解到如何应用它以指定流测量。本文最后概括性介绍了两种关键使用模型：项目指导（program steering）和持续改进。

　　DevOps 是一种以工件为中心的流程

　　您可以通过两种方式呈现一个流程：

• 以操作为中心：将按照执行流程以最终创建产品所需的操作以及它们的顺序描述流程，可以通过流程图或 IDEF 图 进行描述。
• 以工件为中心：用最终的产品和它们的生命周期描述流程。最终的产品被作为状态机对待，它们将进行状态转换。通过状态转换获得成品，以这种方式指定每一个流程步骤。

　　所有流程都会让最终的产品完成它们的生命周期。以工件为中心的观点将描述要做的工作，而以操作为中心的观点则会描述完成工作要做的步骤。例如，在定义一个软件开发流程时，以工件为中心的观点将会描述完成一个代码模型需要做些什么；比如必须减少代码、构建代码并成功通过系统集成测试。程序员需要完成从 “设计” 到 “创建” 代码模型的工作，而不是具体告诉他们要采取哪些步骤来完成从 “设计” 到 “创建” 的转换（打开一个 IDE，创建一个文件，编写代码，进行一次代码审查，运行单元测试，统计 bug 等等）。程序员（事实上包括所有知识工作者（knowledge workers））都讨厌被告知如何完成自己的工作。实际要做的步骤以及每个步骤所需付出的努力都是无法提前预知的。知识工作涉及太多变化因素，因此难以实际预测每个具体步骤。

　　精益技术通常应用于需要处理相同或非常类似的成品的流程，如制造业。事实上，这些流程的目标是最小化产品输出的差异变化。以操作为中心的观点很适合此类流程。如果您要生产某种灯泡，那么每个灯泡都是相同的，因此每个流程步骤都可以提前指定。如果要处理问题单或业务请求，由于每一个问题单或业务请求都是不同的，因此实际操作步骤也会因此不同。有时，工作人员需要查询日志，装入内核转储（kernel dump），努力重现问题，添加一个新的跟踪并运行新的测试脚本，亦或者什么都不需要做。因此，要对 DevOps 应用精益原理，您必须考虑到成品（工件）和流程的差异性，需要采取以工件为中心的观点。

　　对以工件为中心的流程采取价值流程图

　　其中一种重要精益转换技术就是价值流程图，如图 1 所示。在 学会观察：通过价值流程图来提高价值和消除 MUDA（Rother，Shook，Womack，& Jones，1999 年）一书中，您可以了解价值流程图（VSM）在实现转换时的应用及其指标。您可以通过许多方式使用 VSM：

• 使用 VSM 帮助所有相关人员原样呈现成品流程。
• 使用流程测量找出在哪些位置浪费了时间和精力，并设置基准和目标。
• 使用流程内（in-process）测量来判断是否能够通过提高效率来打破瓶颈，比如实现自动化或消除无价值的行为，或增加处理能力。
• 利用这些信息确定一个具有更加流畅流程的潜在 VSM。
• 计划并实现必要的更改，从当前 VSM 迁移到目标 VSM。
• 持续进行改进。使用测量来监视流程并按计划做出调整。

　　图 1. 一个简单的价值流程图

　　图 1 是一个简单的价值流程图例子。它显示了流程步骤和每个步骤的时间。通常，每个流程步骤都关联了执行流程所需操作的详细描述。比如，用于制造流程的操作描述可能是以下步骤：

1. 从库存中取出零件。
2. 检查零件的毛边。
3. 将部件放到钻床钩子中。
4. 以 15 毫米为间隔，钻出洞 1 和 4。
5. 更改为 22 毫米间隔。
6. 钻出洞 2 和洞 3。
7. 拆除零件。
8. 使用钢丝网对洞进行抛光。
9. …

　　图 1 使用了以下符号：

• 最左侧的架状图标显示零件库存，零件将经历整个流程。
• I 图标表示库存的零件数量。
• 虚线箭头为拉出箭头（pull arrow），表示步骤 1 首先由工人从库存中取出一些部件。
• 其他箭头为推送箭头（push arrow），表示完成一个步骤的员工将工作推进到下一步骤。

　　要对以工件为中心的流程应用价值流程图，首先要识别出流程工件。每个工件具有自己的生命周期，即工件从开始到完成需要经历一些不同的状态。

　　例如，一个简单的业务请求状态模型包括以下阶段：

• 提交
• 批准
• 开发
• 部署
• 客户评估

　　关键点在于对于以工件为中心的工作，流程步骤涉及到状态转换的过程。

　　具体地讲，价值流程图中的流程块表示将工件从一个状态推进到下一个状态所做的工作。对于这种情况，流程步骤与操作描述并没有关联，而是与完成状态转换的标准规范有关。

　　采用这种方法有两个优势：

• 它描述了要做的工作，而不是如何完成工作。
• 它真正地捕捉了价值。价值大致是在工件遍历其生命周期的过程中产生。

　　有了这种映射后，库存 就是指给定状态下工件的数量，而时间 则根据工件转化为给定状态所需时间的统计趋势测定。这些测量将在下面的小节中介绍。

　　要创建价值流程图来更加忠实地描述 DevOps 团队如何工作，需要一个更详细的状态模型。对于价值流程图，有两种工件状态：

• 流程状态：经历一次状态转换，具有多个指定资源的其中一个。
• 等待状态：处于积压状态，等待团队挑选并被分配一个资源，从而实现状态转换。

　　以这个 DevOps 为例。设想一个业务分析师决定是否存在新 Web 服务需求。分析师将特性提交给 IT 组织，后者为它分配一个优先级并置于积压状态并等待开发。在某些时候，开发经理将选择该项工作，这样整个软件流程就会开启。在这个例子中，这被当作完全封装的子流程。最后，开发出带有该特性的新应用程序并等待 IT 部署。现在这项工作处于 IT 积压状态。当 IT 选择了这些工作后，它会再次进入等待状态，这一次将等待来自分析团队的客户反馈。这个示例的最终状态就是该特性被交付给客户并完成评估。

　　对于一个软件应用程序的新特性，这个例子可以具备以下流程状态模型：

• 提交以分配优先级（等待状态）
• 进行考察（流程状态）
• 获得开发许可（等待状态）
• 工作（流程状态）
• 完成（等待状态）
• 部署（流程状态）
• 部署（等待状态）
• 客户评估（流程状态）
• 完成客户评估（最终状态）

　　在本例中，价值流程图类似于图 2 所示。

　　图 2. DevOps 的价值流程图示例

　　在这个价值流程图需要注意的地方是：

• 流程块与状态转换是对应的。
• 库存或积压表示等待状态中的工件。
• 团队从他们的积压工作中取出工件并推入到下一个团队的积压工作中。
• 推入操作可以并且经常来自于上游。例如，在部署阶段未通过测试的一个新特性将被重新推入到开发积压工作中。

　　注意，使用价值流程图并不以任何方式暗示这是一个瀑布流程。然而，您可以使用价值流程图表示不同流程之间固有的低效性。例如，在一个典型的瀑布流程中，工件将被堆叠到一组积压工作中，等待进入下面的阶段。例如，收集所有代码等待进行系统测试。价值流程用于理解工作在流程中的进行情况，不管团队使用什么流程。

　　测量

　　如图 3 所示，在价值图中可以找到两种测量：

• 流测量：解释工件如何经过状态转换。这些测量包括端到端 (lead) 时间，流程中每个状态的时间（底部的线），以及字母 I 开头的每个状态（符号）中工件的数量。
• 流程状态测量：描述团队在实现状态转换过程中的效率。这些测量将检测是否因为处理能力不足或流程效率低下而引发瓶颈问题。 流程块中的黄色方框提供了有关流程低效性的测量。

　　图 3. 价值图上的测量

　　流和流程测量是一前一后使用的。流测量用于找出需要关注的流程。流程块测量则确定如何改进这些流程。例如，如果您在某个流程步骤发现了一个瓶颈，考虑是否有足够的团队处理能力。看看是否能够通过提高流程效率、实现自动化等避免不必要的浪费，从而解决这些瓶颈问题。

　　流测量

　　精益组织侧重于最小化库存，明确地管理积压工作，然后将工作量与团队处理能力进行匹配。这些做法的优点在 产品开发流程原理：第二代精益产品开发（Reinertsen，2012）一书中进行了介绍。这些做法已经在制造业、后台系统记录或物流系统中发展成熟。流测量提供了必要的信息来应用这些实践，从而实现精益目标。

　　有两种类型的流测量：

• 工作量：各个状态下的工作量趋势。这些测量揭示了流程中存在的瓶颈。
• 时间：工件花在各种流程状态或流程状态集合中所花时间的统计趋势。

　　工作量测量

　　工作量测量相对比较简单。它们是指在每个等待和流程状态中工作项的数量。图 4 显示了一个图形示例。

　　图 4. 给定状态下工作项数量的趋势

　　时间测量

　　时间测量更加有趣。每个工件在每个状态或若干状态集合中可能花费不同的时间。这种差异是软件固有的；不是因为缺少流程控制而导致的。在制造业中每个成品都是相同的，差异可以指示出需要进行控制的区域；软件行业的成品与制造业不同，需要预计时间和工作量差异。

　　考虑到这一点，向软件开发应用流程原理的关键因素之一就是队列中达到的成品存在持续的变化。实现状态转换所需的努力程度也存在差异。

　　由于要测量来自特定填充的工件在给定状态下所花费的时间长度，因此需要对填充时间进行统计测量。在制造业，由于成品都是类似的，所以一个标准统计项就是平均时间。团队会跟踪工作项处于积压或半成品状态下的平均时间。

　　在制造业中，工件都是一样的；因此，时间分配通常被认为接近一个差异很小的通用值。更确切地说，时间分配被建模为一个标准（也称为 Gaussian）分配，具有很小的标准偏差。在本例中，分配的平均值非常适合。在制造业工作流中，产品非常相似。然而，在创建软件时，每个应用程序都是不同的。对于软件，时间分配通常并不标准甚至是狭隘的。我们在 IBM 的研究发现软件的时间分配类似于图 5 所示。

　　图 5. 典型周期时间统计。箭头指向 T₈₀ 点。

　　尽管这种分布看似让人吃惊，但是可以合理预测接近左侧轴线的峰值。大多数工作项在一个很短的时间内解决，但是一些工作项可能长期处于某个状态。一个好的测量选择就是选择 80 个百分点：T_80。也就是说，当前状态中 80% 的工件花费的时间小于或等于 T_80。 其他花费比这更长的时间，因此位于分布的尾端。通过使用 T₈₀ 点，您可以测量工件花在积压或转换期间的时间趋势。

　　考虑一个更微妙的问题。因为每个成品是不同的，因此用于它们的工作时间也不相同。工作项被推入到下个团队的积压项是偶尔进行的。成品到达积压项的时间间隔也是变化的。一种比较适合的数学模型就是 Poisson Distribution。这种情形有别于制造生产线，后者在工作站之间的产品流比较稳定。对于软件而言，特定工作站的处理能力是固定的，您可以预测积压的大小来显示差异。差异通过生命周期显现并导致图 5 所示的柱状图。

　　要捕捉时间趋势的统计数据，一个不错的选择是 T₈₀ 点历史，如图 6 所示。

　　图 6. 时间趋势图

　　测量循环

　　软件开发的一个重要特性就是成品在产品流中经常向上游移动。例如，某个代码模块可能没有通过特定级别的测试，因此被推回到开发转换流程的积压工作项中。这一操作并不会影响如何测量工作量或端到端时间。端到端时间包括工件花在各个状态中的时间的总和。

　　然而，问题是如何处理各个状态的持续时间统计。您是否为工件分配了状态时间，最近一次重新进入某状态的持续时间，或它在整个生命周期内花在该状态下的总的时间？答案是都很重要：每个时间都用于不同的用途。第一个用于当前的流程调整，第二个测量返工，用于整体的流程改进。

　　流程块测量

　　精益实践人员将测量流程块之间的工作流，并且测量团队的效率和处理能力。

　　以下测量适合以工件为中心的工作：

• 人员可用性（AOP）：指定人员实际花在状态转换上的时间百分比。
• 设备可用性（AOE）：指定设备（例如服务器）用于状态转换相关处理上的时间百分比。
• 工作内容时间（WCT）：实际用于状态转换上的工作百分比。
• 非增值时间（NVA）：用于其它对成品没有推进作用的事务的工作百分比。

　　前两个测量可以看出团队在处理状态转换时的效率。后两个测量可以看出团队的处理能力。

　　信息架构和向下钻取

　　在软件和软件开发中，工件的状态通常取决于一些子工件。例如，系统架构师对业务请求进行分析后将生成一些工作计划，这些工作将分配给一个或多个团队。这些工作将进一步细化为用户案例并最终生成代码模块。代码模块被放到编译流程中以进行系统测试和发布。要确定交付的代码与最初的业务请求的匹配程度，您需要了解一些状态，子工件的状态（用户案例、代码模块和测试用例），以及它们与应用程序和发行版的集成。类似地，子工件流程中的某个瓶颈会导致交付业务请求或其中一个计划工作项时出现瓶颈。例如，交付新特性的状态取决于代码模块的状态。您可能会认为只有当所有已确定的模块已被识别并处于开发中，才能认为某个特性处于开发流程中。除非所有模块完成编码并集成到变更集合中，否则不能认为该特性已经完成。

　　出于这个原因，支持工件流测量的查询需要能够捕捉工件信息架构的链接。流程块标注包括了对父工件和子工件的引用。

　　使用测量

　　在企业中，测量得到合理使用并响应循环，引导企业朝着实现目标的方向前进。这些测量可用于支持精益计算的所有方面：

• 精益转换
• 精益项目或项目监视

　　为了支持这些用途，您需要理解它们之间的微妙差异，从而了解需要对哪些内容进行测量。

　　精益转换

　　精益转换包括以渐进的方式应用一组操作实践，比如以下操作：

• 明确地管理队列
• 管理批量大小
• 针对需求平衡处理能力
• 减少非增值工作

　　要成功应用这些原则，企业文化必须发生转变。改变企业文化对于应用精益实践非常重要（Poppendieck 和 Poppendieck，2013）。如前所述，价值流程图及其指标是实现这种转换的常用工具。

　　测量提供了基本事实，这样所有人都可以看到改进空间，比如流程瓶颈，指出哪些时间被浪费了，以及存在过量处理能力的区域。有了这些信息后，团队可以根据这些信息采取相应的措施。事实上，使用测量可以增强团队的工作能力。

　　在本例中，您感兴趣的是企业在最近一段时间内针对一组目标转换的执行情况。实际上，问题在于 “工件 X 从状态 A 转换到状态 B 需要花多长时间”？图 7 阐释了这个概念。这里使用了测量获得企业的垂直视图。例如，如果有超过一个团队管理某种工件的同一状态转换，那么考虑使用综合测量，其中包括对团队积压工作和转换执行情况的测量，从而获得对企业总体情况的了解并对团队进行比较。。

　　图 7. 使用流测量实现精益应用

　　使用这类流程测量后，您可以逐步地应用精益方法，找出需求最大的位置。

　　精益监控

　　在第二个例子中，想象一下精益转换已经开始执行，并且测量框架已经就绪。由于软件固有的变化特性，需要对流程进行持续监控，从而解决瓶颈问题。通过监视流程的大小和时间统计数据，管理人员和团队可以共同做出最小的优化更改，比如切断提交，或临时变换员工角色，比如安排开发人员进行测试工作。对于这种情况，对于每个状态对儿，您需要按天查看工件的数量和存在时间，如图 8 所示。

　　图 8. 对监视使用流测量

　　另一种使用流测量的方法是理解工作的完成状态。判断项目是否完成的最佳方法是评估工件的状态。标准燃尽图非常重要；从其中可以看出哪些工件已经完成，哪些工件正在处理当中。然而，标准燃尽图缺少工件在整个生命周期内的详细状态。这些测量可用于查看哪些工件占用了最多的时间。这些报表的关键特性是能够找到在给定状态花费时间最多的工件，利用信息架构确定子工件的进度情况。

　　结束语

　　据说，要实现精益方法，则需要关注工作而不是员工。将重点放在工作上，而不是放到成品及其状态转换上，这使得您不仅能够对高度重复的、处理相同产品的流程应用精益方法，还能将这些方法应用于存在显著差异的流程。

　　增强状态转换为定义测量指标提供了基础，从而能够实现以下目标：

• 对精益转换进行计划并跟踪结果，满足 DevOps 目标并衡量采用 DevOps 实践的结果
• 监视和引导 DevOps 企业