使用值流映射评估进程效率

创建 VSM 时，它有助于分析当前的发布周期过程。 VSM 的目的是直观地显示团队在过程中创造价值的位置以及浪费的地方。 目标是到达一个将最大值提供给客户且浪费最少的过程。 VSM 可以帮助你确定那些不贡献任何值或实际减少产品值的区域。

让我们看看 Tailspin 的表现如何。

Mara 是团队的新人，她将创建一个 VSM 来帮助她了解现有过程。 借助 VSM，她将了解团队在 DevOps 成熟度模型中的位置。 事实证明，更成熟的团队通常发布得更快、充满信心，并且出现的问题比不太成熟的团队更少。

Mara 知道她尚未了解全部内容，因此她打算在会议室白板上创建快速 VSM。 会有一些差距和未回答的问题。 没关系， 这是一个开始。 当她完成自己力所能及的部分时，就会将其与团队分享。 VSM 给所有人提供一个通用的切入点，供他们了解改进 Tailspin 网站开发和发布过程的第一步。

让我们看看她的地图。

了解当前过程

Mara 把团队召集到会议室，为大家展示她的 VSM。

玛拉： 价值流图帮助我们衡量一个流程在哪些方面对客户有价值，以及它如何浪费时间而不创造任何价值。 我们的地图从软件的功能规范开始。 让我们只关注一项功能，看看它在当前发布周期中的进展情况。

有些人翻了个白眼，但是马拉继续坚持。

开发流程

创建新功能当前从在源代码管理 中创建标签开始。 我们有一个人可以创建标签，Andy。 我们通过电子邮件请求标签。 我们使用集中式版本控制系统，因此 Andy 会等到所有现有代码都签入并稳定，然后才能创建标签。 创建标签后，我们会收到一封电子邮件，指出我们可以开始工作。 此过程最多需要三天时间，对客户没有价值。 对客户没有任何价值的事情应该花费尽可能少的时间。

在获取所需的所有文件之后，编码一个功能大约需要一个人四天的时间 。 我们必须在公司网络上才能进行源代码管理。 这段时间对客户来说是有价值的。 他们希望此功能。

测试过程

确定有一个稳定版本后，我们会更新电子表格，通知 Amita 有一个版本可以进行测试，并告知她在哪里可以找到它 。 收到通知需要两天时间。

Amita 对该版本进行手动测试 。 随着代码库的增长，此过程会变长。 暂时就说三天吧。 然后，她给安迪发了 bug 报告的电子邮件。 测试不会增加价值，但是必需的。

然后 Andy 必须花时间来会审 bug 以及分配工作 。 Andy 可能需要三天才能理解这些问题，并将它们交给合适的开发人员。

操作过程

Amita 批准一个版本后，她会将其交给 Tim。 Tim 需要将此版本部署到预生产服务器，以便进行更多测试。 通常，预生产服务器与运行网站所需的最新修补程序和更新不同步。 Tim 需要大约两天时间才能部署到预生产并运行一些测试。 同样，虽然部署到预生产不会增加价值，但有必要 。

在一个版本准备好投入生产后，需要先由领导批准发布，才能进行部署。 审批发生在会议中。 需要四天时间才能让领导层开会和审查发布。

最终，Tim 部署了该功能，该功能在 VSM 的右上角呈现在客户面前。 如果生产服务器配置已偏移，因此它与预生产不同步，Tim 首先需要更新它，这需要一天 。

计算客户值指标

现在，我们可以查看关键性能指标，看看我们的表现如何。

总交付时间 是功能交付给客户所需的时间。 在这里，总时间为 22 天。 “处理时间”是在对客户有价值的功能上所花费的时间。 在这里，流程时间包括四天编码和一天来部署该功能，总共提供五天。

活动比率是过程时间除以总交付周期时间：

$${活动比率\ =\ }{\dfrac{处理时间}{总交付时间}}$$

这是我们的效率。 将效率乘以 100 以获得百分比。 结果大于 0%，通常小于 100%。 较高的百分比表示效率更高。

代入我们的数字即可得到：

$${Activity\ ratio\ =\ }{\dfrac{5\ days}{22\ days}}{\ =\ .23}$$

将结果乘以 100，得到 23%。

正如你所看到的，我们有很多改进空间。 开发功能需要 22 天的时间太长。

提姆： 那么，这如何帮助我们？

我们接下来该怎么办？

玛拉： 它有助于了解我们现在所处的位置，以便我们可以确定浪费的区域。 我们希望尽量减少我们对客户没有价值的时间。 我相信，我们可以通过采用 DevOps 方法来提高效率。 一方面，我们可以自动执行这些步骤中的许多步骤，这肯定会缩短时间。

我不建议我们放弃我们目前的流程。 我认为我们可以逐步朝着更高效的流程努力，而不会破坏我们现有的流程。

让我们看看几个可以改进的领域。

安 迪： 我们很可能从一开始就开始。 在代码上获取标签要花很长时间，然后才能启动新功能。 我必须走过去找开发人员，并要求他们提交他们的代码，以便我们可以进行构建和测试。 如果你能想出加速的办法，我会进行重点关注。

此外，我注意到，你没有给生成本身预留时间。 这需要半天的时间。 很期待能看到这个时间缩短。

Amita： 开发人员并不总是会更新电子表格来告诉我，有一个新版本需要测试。 如果有某种方法确保完成该部分，这将节省时间。

玛拉： 伟大！ 我认为 DevOps 可以帮助我们解决所有这些问题。

安 迪： 我们现在没有时间更改该过程。 你听到 Irwin 的话了。 我们现在正面临紧急情况！

玛拉： 我理解。 现在，让我们做我们总是做的事。 但我们可以思考自己在这个过程中的角色，以及我们可以如何改进。 我们可以开始与当前进程并行进行少量更改。 然后，我们可以看看 DevOps 是否能在不中断我们已有的一切的情况下帮助我们。 我将保留此地图和性能指标。 如果我们最终采用 Azure DevOps 做法，则可以重新审视这些数字。 也许我们可以在某些时候更新 VSM。