价值流

基于Jira 的量化管理——eazyBI实践分析

认识价值流

精益生产体系中，有一个基本概念叫价值流，价值流是组织基于客户的需求执行的一系列有序的交付活动。制造业用于加快产品加工流程的原则和模式，同样可以应用到技术行业。
在 DevOps ，通常把技术价值流定义为：把业务构想，转化为向客户交付有价值的、由技术驱动的服务所需要的流程。

流程的输入是既定的业务目标、概念、创意和假设，从研发部门接受工作，并把输入添加到待完成工作列表中开始。研发部门接受工作后，将用敏捷或迭代的开发流程，把输入转化为用户故事或其他形式的需求说明。通过编写代码实现这些需求，把代码签入到版本控制库中，每次变更都要集成到软件系统中，并进行集成测试。应用或服务，只有在生产环境中按预期正常地为客户提供服务，团队的工作才算是产生价值了。

在技术价值流中，团队不但要做到快速交付，还要保证部署工作不会出现失误的情况，比如客户服务中断、性能下降、安全性下降等问题。
部署指的是把项目进行打包、配置和发布的过程。在 App 端，打包 App、把 App 发给测试人员，把 App 发布到市场、发布热更新补丁，都属于部署工作。
和后台比起来，App 端的部署要简单很多，因为后台有各种乱七八糟的配置，任何一个没配好都有可能导致服务起不来。

前置时间

在精益社区中，前置时间与处理时间是度量价值流性能的两个常用指标，处理时间有时也叫接触时间或任务时间。
前置时间在工单创建后开始计时，到工作完成时结束，处理时间从实际处理这个工作时才开始计时，不包含这个工作在任务队列中排队等待的时间。因为客户能体验到前置时间，所以我们把重点放在缩短前置时间，而不是处理时间上。

处理时间与前置时间的比率，是非常重要的效率指标，为了实现快速流动且缩短前置时间，就必须缩短工作在队列中的等待时间。

有的开发团队在实践 DevOps 前发现，经常在项目开发完成前，把变更合并到一起后，发现整个系统根本无法正常工作，甚至连代码都无法编译。而遇到的这些问题，需要几天甚至几个星期来定位和修复，这么长的前置时间，对客户而言是非常糟糕的体验。

在 DevOps 的理想情况下，开发人员能快速、持续地获得反馈，快速且独立地开发、集成和验证变更，而且能把代码部署到生产环境中。
而采用的手段有：

• 小批量向版本控制系统中，持续不断地提交小批量的代码变更，并使用自动化测试对代码进行测试，再把它部署到生产环境中。代码变更在生产环境中运行后，如果存在问题，就能快速发现并修复问题。
• 模块化除了小批量，还要通过模块化、高内聚、低耦合的方式优化软件的架构设计。这样即使部署失败，也不会影响到整个团队的开发工作。

除了前置时间和处理时间，价值流中第三个关键指标，就是完成时间和总花费时间的比率 %C/A（Completion / Accurate），该指标反映了价值流中每个步骤的输出质量。
想要获取 %C/A ，可以询问下游客户（比如开发人员的下游客户就是测试人员），他们有百分之多少的时间收到了“真正有用的工作”。
真正有用的工作，也就是不必修复错误信息、补充信息或澄清信息的工作。

部署前置时间

部署的前置时间，是价值流的一个子集，也是这篇文章讨论的重点。
技术价值流，从工程师向版本控制系统提交变更开始，以变更在生产环境中运行，为客户提供了价值，并生成有效的反馈和监控信息为止。

1. 第一阶段在技术价值流的第一阶段，工作主要包括设计和开发系统，这个阶段和精益产品开发有很多相似之处。比如都具有高度的易变性、不确定性，都需要创意，某些工作还可能无法重来，导致无法确定工作的总体处理事件。
2. 第二阶段技术价值流的第二阶段，工作主要包括测试和运维，这一阶段类似于精益制造。和第一阶段相比，第二阶段的工作，要有可预见性和自动化，减少易变的因素，并满足业务目标。减少易变因素，可通过短且可预测的前置时间、进行能降低缺陷率的改善。

DevOps 不提倡在第一阶段完成大量工作后，再把工作转入第二阶段。而是提倡采用测试、运维、设计与开发同步的模式，产生更快的价值流和价值更高的产品。
只有当工作任务是小批量，并且把质量内建于价值流的各个部分时，这种同步的工作模式才能实现。

价值流程图

价值流程图才是最理想的DevOps第一步

DevOps的终极目标在于产品快速迭代的同时又能保证良好的质量水平，为了了解当前哪些人员、流程、技术需要修复或改进，我们要画出整个软件交付周期的价值流程图——从接收应用或者功能的开发新要求，到将产品交付至客户或者员工。而这正是DevOps最理想的第一步，这项工作包括：

• 全部流程区都将参与其中
• 保障信息流程与开发流程（对于应用开发工作）
• 流程时长，即新应用或功能在单一流程之内的开发周期
• 生产交货时间，即应用或功能需要耗费多长时间来过渡到下一个流程并最终达至交付
• 现有应用或者功能的就绪时间
• 新型应用或者功能的现有交付时间

价值流程图有很多版本，每个人的理解也有偏差，有时候在面对客户时甚至不清楚他们是否已经拥有一套有意义的价值流程图方案。

以下示意图通过简单示例解释了新功能发布所需的价值流程图方案：

在这套流程机制中，我们可以看到：

• 信息流程——即新功能的要求如何与业务相契合并与CIO进行对接。在这种情况下，每隔一周就要进行一次需求讨论会。需要注意的是，应用智能（包括监控与分析两大要素）对反馈回路非常重要。
• 软件开发流程——此流程在IT部门内部，同样属于新功能开发的重要组成部分。需要注意的是，应用智能同样对软件开发周期内的信息反馈与交付回路至关重要。
• 交付时间表——即将应用或功能由理论要求转化为可交付内容的时间周期。在这里我们可以看到两项计算过程：1）产品交付时间=该功能在不同流程间过渡所耗费的总时长；2）流程时间=该功能在每个流程当中所耗费的独立时长。
• 在此之后，我们能够一步步计算出总体功能就绪时间和总体功能交付时间。在这个示例当中，一项全新功能需要大约三个半月才能被呈现在用户面前——这样的周期对于当前追求唯快不破的用户来说太过漫长了。

  关于价值流程图的提示

  为自己的DevOps做一张价值流程图仅仅只是第一步，好的价值流程图机制应该具备极强的针对性，能够很轻易绘制在白板之上，最重要的是能帮助工作人员解读当前流程。而前面列举的示例则能更近一步向企业决策者展示并争取到他们的认可。如何做好专属的DevOps价值流程图，以下五点你可能会用到：

1、价值流程图最重要的意义并不在于立即生效，它会逐步进行同时帮助同一团队内的成员理解整个流程，通过抱怨、诉求、接纳以及变更等途径直至达成共识。这对于整个DevOps团队来说极为重要，因为日常工作当中我们会发现，往往就是不沟通不诉求才会导致效率下降。

2、不要在决策制定者未了解的情况下着手构建价值流程图，这样的话将无法确保流程的准确性。只有决策制定者才能真正了解到整个DevOps的实际情况，能保证最后的流程能够顺利进行，这可能会很麻烦但却非常值得。

3、对于DevOps价值流程图的讨论一般需要较长的时间，根据大家实际采取的流程情况来定，要确保不同职责的人能够在这一环节中畅所欲言，避免把同一项内容拆分开，因为Dev和Ops在实际工作中还是有很大区别的。

4、DevOps价值流程图的规划需要一个主持人，他将扮演极为重要的角色。要统一来自不同部门的意见，调节大家的情绪波动，让不同参与者在讨论过程中始终保持正确的交流状态。

5、最后是价值流程图的发布，需要组织一次研讨会或电话会议，以更正式的方式进行价值流程图方案的发布，因为这是DevOps的第一步，同时也是最重要的一步，它是实现各类有价值目标的必要基础，是以后所有工作的起点和指导。

如何使用价值流程图？

说到这里，我们仅仅勾勒出了价值流程图方案的轮廓，也许你的心中也有了属于你自己的DevOps价值流程图。需要强调的是，这里的每个流程都只是参考，我们需要结合自身实际情况，包括人员因素、内部流程与技术类别等，分辨出他们具体处于哪个阶段，该流程的持续时间甚至最终交付时间如何确定，这些都是我们需要自己去考虑的。

如果最后能够确保DevOps价值流程图真实准确，那DevOps的第一步将走得无比坚实，这不仅能解决DevOps实施过程中的矛盾，同时还回答了之前关于DevOps的核心目标——指导我们如何在加快发布速度的同时保证成果的质量水平，从此迈出DevOps的第一步！