使用价值流图评估过程效率
创建价值流图 (VSM) 后，它可以帮助你分析当前的发布周期过程。 VSM 的用途是直观地显示团队在此过程中何处可以创造价值，何处存在浪费。 目标是实现一个以最少的浪费为客户提供最大价值的过程。 VSM 可帮你准确找出哪些方面不能贡献任何价值或者实际上降低了产品价值。
一起来看看 Tailspin 是如何衡量的。
Mara，是团队的新手，打算创建 VSM 来帮助自己了解现有过程。 在 VSM 的帮助下，她会知道团队在 DevOps 成熟度模型中的位置。 事实证明，更成熟的团队与不够成熟团队相比，通常发布更快、更自信且 bug 更少。
Mara 知道她尚未了解全部内容，因此她打算在会议室白板上创建快速 VSM。 虽然会有一些遗漏和未解决的问题，但没有关系。 这只是一个开始。 当她完成自己力所能及的部分时，就会将其与团队分享。 VSM 给所有人提供一个通用的切入点，供他们了解改进 Tailspin 网站开发和发布过程的第一步。
一起来看一个示例。
了解现有过程
Mara 把团队召集到会议室，为大家展示她的 VSM。
Mara：VSM 可以帮助我们衡量一个过程中哪些地方对客户有价值，哪些地方只会耗费时间而不会创造任何价值。 从位于左上角的软件功能规范开始映射。 让我们只关注一项功能，看看它在当前发布周期中的进展情况。
一些人不以为然，但 Mara 径自继续着。
开发过程
当前，创建一个新功能首先要在源代码管理中创建一个标签 
。 我们中有一个人可以创建标签，那就是 Andy。 我们通过电子邮件请求标签。 我们使用集中式的版本控制系统，因此 Andy 等到所有现有代码签入并稳定后才创建该标签。 创建标签后，我们收到一封电子邮件，说我们可以开始工作了。 此过程需要三天之久，而且对客户没有任何价值。 对客户没有价值的东西应该花费尽可能少的时间。
一旦我们有权访问所需的全部文件，一个人编码一项功能大约需要四天时间 
。 我们必须连接企业网络才能访问源代码管理。 这个时间对客户来说是有价值的。 他们想要这个功能。
测试过程
确定了稳定版之后，我们更新电子表格来告诉 Amita 已有一个版本准备好进行测试以及在哪里可以找到该版本 
。 她得到通知需要两天。
Amita 对该版本进行手动测试 
。 此过程随着代码库的发展而变得越来越长。 现在，假设需要三天。 随后她向 Andy 发送附有 bug 报告的电子邮件。 测试不能增加价值，但有必要这么做。
然后 Andy 必须花时间来会审 bug 以及分配工作 。 Andy 可能还需要三天时间来了解这件事，并将其发给合适的开发人员。
操作过程
Amita 批准一个版本后，她会将其交给 Tim。 Tim 需要将此版本部署到预生产服务器进行更多测试。 通常情况下，预生产服务器与运行网站所需的最新补丁和更新不同步。 Tim 大约需要两天时间来部署到预生产环境并运行一些测试。 再次强调，尽管部署到预生产环境并不会增加价值，但有必要这么做
。
一个版本准备好投入生产后，需要领导批准发布，才能部署。 批准要开会确定。 领导开会和审阅发布需要四天时间。
最后，Tim 部署该功能，并将其交付给 VSM 右上角的客户。 如果生产服务器配置因发生偏移而与预生产环境不同步，Tim 首先需要进行更新，这需要一天时间
。
计算客户价值指标
现在我们可以看看关键性能指标，看看我们是如何衡量的。
“总提前期”是一项功能交付给客户所需花费的时间。 在这里，总提前期为 22 天。 “处理时间”是在对客户有价值的功能上所花费的时间。 在这里，处理时间总共为五天，四天用于编码，还有一天用于部署功能。
而“活动比率”是处理时间除以总提前期：
$${Activity\ ratio\ =\ }{\dfrac{Process\ time}{Total\ lead\ time}}$$
这个计算结果就是我们的“效率”。 将效率乘以 100 得到一个百分比。 得出的结果大于 0%且通常小于 100%。 百分比越大表示效率越高。
代入数字，就得到：
$${Activity\ ratio\ =\ }{\dfrac{5\ days}{22\ days}}{\ =\ .23}$$
该结果乘以 100%，得到“23%”。
如你所见，我们有很大的改进空间。 而且花费 22 天来开发一项功能太久了。
Tim：所以，这对我们有什么帮助？
我们该怎么办？
Mara：它有助于我们看到现在所处的位置，以便我们可以准确指出浪费的地方。 我们希望最大程度减少花费对客户没有价值的时间。 我相信我们可以通过采用 DevOps 方法来提高效率。 首先，可以自动执行这其中许多步骤，这样一定能减少时间消耗。
我并不说我们要放弃现有过程，但我认为我们可以在不破坏现有过程的情况下，一点一点地朝着实现更高效的过程的方向努力。
一起来看仅有的几个可以改进的地方。
Andy：我们倒不如从头开始。 在代码上获取标签要花很长时间，然后才能启动新功能。 我必须在各个开发人员之间来回跑，并要求他们签入所开发的代码，以便我们可以进行生成和测试。 如果你能想出加快速度的办法，我就听你的。
此外，我注意到，你没有给生成本身预留时间。 目前这会花费半天时间。 我很期待看到这个时间缩短。
Amita：而且开发人员不会每次都更新电子表格，让我知道有新版本需要测试。 如果能确保这个部分得到执行，就能节省时间。
Mara：太好了！ 我认为 DevOps 可以帮我们解决所有这些问题。
Andy：我们没有时间立即更改这个过程。 你听到 Irwin 的话了。 我们现在处于危机模式！
Mara：是，我了解。 现在，我们还是做一直在做的事情。 但我们所有人都可以思考一下自己在此过程中所参与的环节，以及如何改进。 我们可以首先以并行方式对现有过程进行小幅更改。 然后我们可以了解 DevOps 是否可以在无需破坏现有过程的情况下帮助我们。 我会保留此映射和性能指标。 如果我们最终采用 Azure DevOps 做法，那么我们就可以缩短这些时间。 或许我们可以在某个时候更新 VSM。