广州软件开发公司业务咨询卢先生 手机18998818351 售后服务热线：020-22076940
广州软件开发公司业务咨询卢先生 手机18998818351 售后服务热线：020-22076940
DevOps 旨在更好地集成 IT 操作和软件开发，从而提高对业务更改的联合响应能力。这些业务更改可能包括对某个问题单做出响应或者提供业务所需的新服务。DevOps 旨在完成以下目标：
这和采用精益计算原理（称为精益技术）的目的相同。可以将精益技术描述为一种思维方式和一组技术集合，它们可用于管理和改善端到端周期时间（或交货时间），并充分利用某个企业的能力来优化整个流程的资源流（库存）。Lord Kelvin 提供了一个人们所熟悉的短语 “测量就是为了发现”，通过测量来了解精益可视化技术（如 价值流程图（value streaming mapping），包含产品流测量）带来的影响。流测量包括对库存进行端到端（黑盒）和分步（白盒）测量，测量流程时间，以及成品花费在存货阶段（等待处理）的时间。
最近，IBM 进一步扩展了 DevOps 最初的定义范围，包括了以下原则：
从这一点来看，可以推断出以下结论：
过去，精益原则一直应用于制造业、后台流程和物流业。这些流程具有更好的可预测性，与 DevOps 所支持的流程相比缺少变化。对软件（Poppendieck 和 Poppendieck，2013）和一般性知识工作（Odegard，2013）应用精益原则并不是什么新鲜事物。本文对已有的实践做法进行了扩展，将 DevOps 作为一种以工件为中心的业务流程，这样就可以将精益实践和测量顺利应用到 DevOps 流程。
在应用精益实践和原则时，必须增强流测量以检测瓶颈和低效率事件，从而找到机会进行改进并采取措施。以工件为中心的一个关键优势是可以很容易地指定和增强流测量。
以下小节介绍了这种以工件为中心的观点以及为什么应用于 DevOps。您将了解到如何应用它以指定流测量。本文最后概括性介绍了两种关键使用模型：项目指导（program steering）和持续改进。
您可以通过两种方式呈现一个流程：
所有流程都会让最终的产品完成它们的生命周期。以工件为中心的观点将描述要做的工作，而以操作为中心的观点则会描述完成工作要做的步骤。例如，在定义一个软件开发流程时，以工件为中心的观点将会描述完成一个代码模型需要做些什么；比如必须减少代码、构建代码并成功通过系统集成测试。程序员需要完成从 “设计” 到 “创建” 代码模型的工作，而不是具体告诉他们要采取哪些步骤来完成从 “设计” 到 “创建” 的转换（打开一个 IDE，创建一个文件，编写代码，进行一次代码审查，运行单元测试，统计 bug 等等）。程序员（事实上包括所有知识工作者（knowledge workers））都讨厌被告知如何完成自己的工作。实际要做的步骤以及每个步骤所需付出的努力都是无法提前预知的。知识工作涉及太多变化因素，因此难以实际预测每个具体步骤。
精益技术通常应用于需要处理相同或非常类似的成品的流程，如制造业。事实上，这些流程的目标是最小化产品输出的差异变化。以操作为中心的观点很适合此类流程。如果您要生产某种灯泡，那么每个灯泡都是相同的，因此每个流程步骤都可以提前指定。如果要处理问题单或业务请求，由于每一个问题单或业务请求都是不同的，因此实际操作步骤也会因此不同。有时，工作人员需要查询日志，装入内核转储（kernel dump），努力重现问题，添加一个新的跟踪并运行新的测试脚本，亦或者什么都不需要做。因此，要对 DevOps 应用精益原理，您必须考虑到成品（工件）和流程的差异性，需要采取以工件为中心的观点。
其中一种重要精益转换技术就是价值流程图，如图 1 所示。在 学会观察：通过价值流程图来提高价值和消除 MUDA（Rother，Shook，Womack，& Jones，1999 年）一书中，您可以了解价值流程图（VSM）在实现转换时的应用及其指标。您可以通过许多方式使用 VSM：
图 1 是一个简单的价值流程图例子。它显示了流程步骤和每个步骤的时间。通常，每个流程步骤都关联了执行流程所需操作的详细描述。比如，用于制造流程的操作描述可能是以下步骤：
图 1 使用了以下符号：
要对以工件为中心的流程应用价值流程图，首先要识别出流程工件。每个工件具有自己的生命周期，即工件从开始到完成需要经历一些不同的状态。
例如，一个简单的业务请求状态模型包括以下阶段：
关键点在于对于以工件为中心的工作，流程步骤涉及到状态转换的过程。
具体地讲，价值流程图中的流程块表示将工件从一个状态推进到下一个状态所做的工作。对于这种情况，流程步骤与操作描述并没有关联，而是与完成状态转换的标准规范有关。
采用这种方法有两个优势：
有了这种映射后，库存 就是指给定状态下工件的数量，而时间 则根据工件转化为给定状态所需时间的统计趋势测定。这些测量将在下面的小节中介绍。
要创建价值流程图来更加忠实地描述 DevOps 团队如何工作，需要一个更详细的状态模型。对于价值流程图，有两种工件状态：
以这个 DevOps 为例。设想一个业务分析师决定是否存在新 Web 服务需求。分析师将特性提交给 IT 组织，后者为它分配一个优先级并置于积压状态并等待开发。在某些时候，开发经理将选择该项工作，这样整个软件流程就会开启。在这个例子中，这被当作完全封装的子流程。最后，开发出带有该特性的新应用程序并等待 IT 部署。现在这项工作处于 IT 积压状态。当 IT 选择了这些工作后，它会再次进入等待状态，这一次将等待来自分析团队的客户反馈。这个示例的最终状态就是该特性被交付给客户并完成评估。
对于一个软件应用程序的新特性，这个例子可以具备以下流程状态模型：
在本例中，价值流程图类似于图 2 所示。
在这个价值流程图需要注意的地方是：
注意，使用价值流程图并不以任何方式暗示这是一个瀑布流程。然而，您可以使用价值流程图表示不同流程之间固有的低效性。例如，在一个典型的瀑布流程中，工件将被堆叠到一组积压工作中，等待进入下面的阶段。例如，收集所有代码等待进行系统测试。价值流程用于理解工作在流程中的进行情况，不管团队使用什么流程。
如图 3 所示，在价值图中可以找到两种测量：
流和流程测量是一前一后使用的。流测量用于找出需要关注的流程。流程块测量则确定如何改进这些流程。例如，如果您在某个流程步骤发现了一个瓶颈，考虑是否有足够的团队处理能力。看看是否能够通过提高流程效率、实现自动化等避免不必要的浪费，从而解决这些瓶颈问题。
流测量
精益组织侧重于最小化库存，明确地管理积压工作，然后将工作量与团队处理能力进行匹配。这些做法的优点在 产品开发流程原理：第二代精益产品开发（Reinertsen，2012）一书中进行了介绍。这些做法已经在制造业、后台系统记录或物流系统中发展成熟。流测量提供了必要的信息来应用这些实践，从而实现精益目标。
有两种类型的流测量：
工作量测量
工作量测量相对比较简单。它们是指在每个等待和流程状态中工作项的数量。图 4 显示了一个图形示例。
时间测量
时间测量更加有趣。每个工件在每个状态或若干状态集合中可能花费不同的时间。这种差异是软件固有的；不是因为缺少流程控制而导致的。在制造业中每个成品都是相同的，差异可以指示出需要进行控制的区域；软件行业的成品与制造业不同，需要预计时间和工作量差异。
考虑到这一点，向软件开发应用流程原理的关键因素之一就是队列中达到的成品存在持续的变化。实现状态转换所需的努力程度也存在差异。
由于要测量来自特定填充的工件在给定状态下所花费的时间长度，因此需要对填充时间进行统计测量。在制造业，由于成品都是类似的，所以一个标准统计项就是平均时间。团队会跟踪工作项处于积压或半成品状态下的平均时间。
在制造业中，工件都是一样的；因此，时间分配通常被认为接近一个差异很小的通用值。更确切地说，时间分配被建模为一个标准（也称为 Gaussian）分配，具有很小的标准偏差。在本例中，分配的平均值非常适合。在制造业工作流中，产品非常相似。然而，在创建软件时，每个应用程序都是不同的。对于软件，时间分配通常并不标准甚至是狭隘的。我们在 IBM 的研究发现软件的时间分配类似于图 5 所示。
尽管这种分布看似让人吃惊，但是可以合理预测接近左侧轴线的峰值。大多数工作项在一个很短的时间内解决，但是一些工作项可能长期处于某个状态。一个好的测量选择就是选择 80 个百分点：T80。也就是说，当前状态中 80% 的工件花费的时间小于或等于 T80。 其他花费比这更长的时间，因此位于分布的尾端。通过使用 T80 点，您可以测量工件花在积压或转换期间的时间趋势。
考虑一个更微妙的问题。因为每个成品是不同的，因此用于它们的工作时间也不相同。工作项被推入到下个团队的积压项是偶尔进行的。成品到达积压项的时间间隔也是变化的。一种比较适合的数学模型就是 Poisson Distribution。这种情形有别于制造生产线，后者在工作站之间的产品流比较稳定。对于软件而言，特定工作站的处理能力是固定的，您可以预测积压的大小来显示差异。差异通过生命周期显现并导致图 5 所示的柱状图。
要捕捉时间趋势的统计数据，一个不错的选择是 T80 点历史，如图 6 所示。
测量循环
软件开发的一个重要特性就是成品在产品流中经常向上游移动。例如，某个代码模块可能没有通过特定级别的测试，因此被推回到开发转换流程的积压工作项中。这一操作并不会影响如何测量工作量或端到端时间。端到端时间包括工件花在各个状态中的时间的总和。
然而，问题是如何处理各个状态的持续时间统计。您是否为工件分配了状态时间，最近一次重新进入某状态的持续时间，或它在整个生命周期内花在该状态下的总的时间？答案是都很重要：每个时间都用于不同的用途。第一个用于当前的流程调整，第二个测量返工，用于整体的流程改进。
流程块测量
精益实践人员将测量流程块之间的工作流，并且测量团队的效率和处理能力。
以下测量适合以工件为中心的工作：
前两个测量可以看出团队在处理状态转换时的效率。后两个测量可以看出团队的处理能力。
在软件和软件开发中，工件的状态通常取决于一些子工件。例如，系统架构师对业务请求进行分析后将生成一些工作计划，这些工作将分配给一个或多个团队。这些工作将进一步细化为用户案例并最终生成代码模块。代码模块被放到编译流程中以进行系统测试和发布。要确定交付的代码与最初的业务请求的匹配程度，您需要了解一些状态，子工件的状态（用户案例、代码模块和测试用例），以及它们与应用程序和发行版的集成。类似地，子工件流程中的某个瓶颈会导致交付业务请求或其中一个计划工作项时出现瓶颈。例如，交付新特性的状态取决于代码模块的状态。您可能会认为只有当所有已确定的模块已被识别并处于开发中，才能认为某个特性处于开发流程中。除非所有模块完成编码并集成到变更集合中，否则不能认为该特性已经完成。
出于这个原因，支持工件流测量的查询需要能够捕捉工件信息架构的链接。流程块标注包括了对父工件和子工件的引用。
在企业中，测量得到合理使用并响应循环，引导企业朝着实现目标的方向前进。这些测量可用于支持精益计算的所有方面：
为了支持这些用途，您需要理解它们之间的微妙差异，从而了解需要对哪些内容进行测量。
精益转换
精益转换包括以渐进的方式应用一组操作实践，比如以下操作：
要成功应用这些原则，企业文化必须发生转变。改变企业文化对于应用精益实践非常重要（Poppendieck 和 Poppendieck，2013）。如前所述，价值流程图及其指标是实现这种转换的常用工具。
测量提供了基本事实，这样所有人都可以看到改进空间，比如流程瓶颈，指出哪些时间被浪费了，以及存在过量处理能力的区域。有了这些信息后，团队可以根据这些信息采取相应的措施。事实上，使用测量可以增强团队的工作能力。
在本例中，您感兴趣的是企业在最近一段时间内针对一组目标转换的执行情况。实际上，问题在于 “工件 X 从状态 A 转换到状态 B 需要花多长时间”？图 7 阐释了这个概念。这里使用了测量获得企业的垂直视图。例如，如果有超过一个团队管理某种工件的同一状态转换，那么考虑使用综合测量，其中包括对团队积压工作和转换执行情况的测量，从而获得对企业总体情况的了解并对团队进行比较。。
使用这类流程测量后，您可以逐步地应用精益方法，找出需求最大的位置。
精益监控
在第二个例子中，想象一下精益转换已经开始执行，并且测量框架已经就绪。由于软件固有的变化特性，需要对流程进行持续监控，从而解决瓶颈问题。通过监视流程的大小和时间统计数据，管理人员和团队可以共同做出最小的优化更改，比如切断提交，或临时变换员工角色，比如安排开发人员进行测试工作。对于这种情况，对于每个状态对儿，您需要按天查看工件的数量和存在时间，如图 8 所示。
另一种使用流测量的方法是理解工作的完成状态。判断项目是否完成的最佳方法是评估工件的状态。标准燃尽图非常重要；从其中可以看出哪些工件已经完成，哪些工件正在处理当中。然而，标准燃尽图缺少工件在整个生命周期内的详细状态。这些测量可用于查看哪些工件占用了最多的时间。这些报表的关键特性是能够找到在给定状态花费时间最多的工件，利用信息架构确定子工件的进度情况。
据说，要实现精益方法，则需要关注工作而不是员工。将重点放在工作上，而不是放到成品及其状态转换上，这使得您不仅能够对高度重复的、处理相同产品的流程应用精益方法，还能将这些方法应用于存在显著差异的流程。
增强状态转换为定义测量指标提供了基础，从而能够实现以下目标：