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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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