DevOps转型的创造客户价值所需,绘制价值流图,组建专门的转型团队

一旦确定要应用DevOps 原则和模式的价值流后，就要深刻理解如何向客户交付价值：做什么工作？谁来做？该采取什么措施改善流程？

确定创造客户价值所需的团队

无论价值流的复杂程度如何，一个人是不可能知道为客户创造价值所要做的每一项工作。

选择好DevOps试点应用或服务后，必须确定价值流的所有成员，他们有责任共同为客户创造价值。一般来说，包括以下这些成员：

• 产品负责人：作为业务方的代言人，定义系统需要实现的功能。
• 开发团队：负责开发系统功能。
• QA 团队：给开发团队提供反馈，并确保系统功能符合需求。
• 运维团队：负责维护生产环境，并确保系统能够良好地运行。
• 信息安全团队：负责系统和数据的安全。
• 发布经理：负责管理和协调生产环境部署以及发布流程。
• 技术主管或价值流经理：（根据精益方法论的定义）负责"从始至终地保障价值流的产出满足或超出客户（和组织）期望"。

针对团队工作绘制价值流图

确定了价值流的相关成员之后，下一步是深入理解工作方式，并用价值流图进行记录。在价值流中，最初的工作是确定客户需求或进行业务构思，这由产品负责人完成；然后，开发团队接手，他们通过编程实现相关功能，并将代码提交到版本控制系统中；接下来，在类生产环境中对功能进行集成和测试，最后部署到（理想情况下）能为客户创造价值的生产环境中。

绘制价值流图的目标并不是记录所有的步骤和细节，而是识别出阻碍价值流快速流动的环节，从而缩短前置时间和提高可靠性。在理想情况下，参与研讨会的成员应该有权力改变各自负责的部分。

根据价值流参与团队所提供的全部信息，应该重点分析和优化下面两类工作：

• 需要等待数周甚至数月的工作。
• 引发或处理重大返工的工作。

价值流图的初始版本应该只包含重要的流程模块。即使是针对复杂的价值流，参与小组通常也可以在几个小时内绘制出包含5～15个模块的价值流图。每个模块至少应包括工作项的前置时间（LT）和处理时间（也叫增值时间 Value Added Time VA），以及由下游消费者测量的%C/A。

一旦确定了想要改进的度量指标，就可以进入分析和度量的下一阶段，以便更好地理解问题。然后，绘制理想化的价值流图，并以此作为下一阶段（例如，通常3～12个月）的改进目标。

领导者帮助确定改进目标，并指导团队就假设和措施集思广益，通过实验探索各种假设，然后分析结果，以判断假设是否正确。通过不断地重复和迭代，团队把新获得的经验用于下一次实验和验证。

组建专门的转型团队

DevOps 转型面临的一个固有挑战是与公司当前的业务发生冲突，这不可避免，而且是公司
成功发展的自然结果。任何一个成功运作多年（几年、几十年甚至几百年）的组织都已经建立了
符合自身的实践和运行机制，例如产品开发、订单管理和供应链运营等。

虽然维持现状很有好处，但为了适应市场的变化，往往需要改变工作方式。这需要颠覆和创新，必然会和当前负责日常业务和内部流程的群体产生冲突，而且后者往往会胜出。

应该组建专门的转型团队，并使之独立于负责日常运作的部门。最重要的是，这个团队应该负责实现明确定义的、可度量的、系统级的目标。

首先，要明确整体目标。团队就应该制订改进工作的详细计划与节奏。像产品开发工作一样，转型工作也应该以迭代、增量的方式进行。一般每次迭代在2～4周内完成。对于每次迭代，团队应该制订出一组能够产生价值的小目标，并朝着长期目标靠近。在每次迭代结束时，团队应该检查进度，并为下一次迭代设定新的目标。

其次，保持小跨度的改进计划。这样做有什么好处呢？

• 具备重新计划和更改优先级的能力和灵活性。
• 减少工作从实施到生效的延迟时间，从而加强反馈回路，这将更有可能强化期望的行为——初步成功有利于加大投入。
• 从迭代中更快地获得经验，并将其用于下一次迭代。
• 能够更省力地获得改进。
• 在日常工作中更快地实现有意义的差异化改进。
• 降低项目还没有取得成果就被终止的风险。

再次，为非功能性需求预留20%的开发时间，减少技术债务。为了积极地管理技术债务，要确保至少把20%的开发和运维时间投入到重构、自动化工作、架构优化以及非功能性需求（也称为"质量属性"）上，例如可维护性、可管理性、可扩展性、可靠性、可测试性、可部署性和安全性等。

最后，提高工作的可视化程度。为了能够明确团队是否正朝着既定目标前进，组织中的每个人都有必要了解当前的工作状态。将状态进行可视化的方法有很多，最重要的是有效展示最新状态，而且要不断修订，以确保团队了解最新进展。

用工具强化预期行为

在DevOps价值流中，我们要使用工具来强化文化，并加速实现行为的改变。

我们的目标是强调，开发人员和运维人员不仅有着共同的目标，而且还有同一份任务列表。在理想情况下，任务列表存储在公共的工作系统中，使用统一的术语，并能全局地进行优先级排序。

采用这种方式，开发人员和运维人员可以创建共享的工作队列，而不是使用不同的工具（例如，开发人员使用JIRA，运维人员则使用ServiceNow）。这样做的显著好处是，当生产事故在开发人员的工作系统中可见时，人们能清楚地知道事故会在什么时候影响到其他工作，这在使用看板图时尤为明显。

共享队列的另一个好处是统一了任务列表，每个人都能从全局的角度思考优先级最高的事情，选择对组织最有价值的工作，或能最大限度地偿还技术债务的工作。在发现技术债务时，如果不能立即解决，可以将它添加到任务列表中。对于待解决的问题，可以使用为非功能性需求预留的20%的时间进行修复。

建立机制并允许团队成员互相帮助，甚至帮助其他团队的成员。这将带来惊人的变化——人们获取信息的时间或完成工作的时间从几天缩短到几分钟。此外，因为一切都被有效地记录下来，所以人们之后不再需要向别人求助，而只需要搜索聊天记录即可。

但是，这种希望立即得到回复的心情会导致一些问题。反复地打断和提问会干扰其他人的正常工作。因此，团队可以根据具体情况针对某些类型的需求使用更结构化的异步工具。

总结

我们探讨了如何确定支持价值流的团队，并通过绘制价值流图了解到了向客户交付价值所要做的工作。价值流图不仅可以显示当前工作状态的基本情况（包括前置时间和%C/A 等指标），还可以指导团队确定未来的改进目标。

这样一来，转型团队能够快速迭代，通过实验提高效能。团队分配足够的时间修复已知缺陷和解决架构问题，包括非功能性需求等。通过在价值流中发现问题并持续偿还技术债务，前置时间和质量等各个方面都能取得显著改善。