05 | 价值流分析：关于DevOps转型，我们应该从何处入手？
讲述：石雪峰
时长16:31大小15.13M
关键要素
方式
价值
总结
思考题
精选留言(12)
桃子-夏勇杰2019-10-22需求提出时间的定义是什么？用户提出需求的时间，还是业务部门提出需求的时间，还是产品经理提交PRD的时间，还是提出就绪用户故事的时间？需求如何拆，规模多大？这些问题对前置时间的计算都有很大影响，想听一些这方面的实战经验。展开作者回复: 你好，你把下一讲的问题提前剧透了，以我们公司现有的实践来说，需求提出时间，具体指业务方提出需求的实践，以业务方在系统中录入原始需求为准。需求录入之后，会经过需求承接，产品设计，PRD评审，到准备就绪，这些就是需求管理层面的事情，再往后就进入了开发阶段。
至于需求拆分的粒度，根据不同业务形态也不尽相同，我们现行的指导原则是，在一个迭代周期内可以上线交付，平均统计下来3-5天居多。另外，除了需求粒度之外，还有一个比较重要的指标，就是配置化需求比例，也就是不需要额外开发代码，仅需要调整配置就可以完成交付的功能。 1 2
阿硕2019-10-23石老师，您好，请问价值流图中的指标如何度量出来的呢？作者回复: 你好，价值流图反应的是团队客观的软件交付流程，度量价值流实际上就是度量软件交付过程。一般来说，都是以需求作为抓手，统计在各个交付阶段的时长，在针对这个阶段的流转时长度量可改进的方向。所以，关键是把需求纳入统一系统管理，需求状态切换尽量通过自动化手段完成，让需求管理系统和各个环节系统进行打通，那么从需求管理平台就能一目了然的看清楚团队现状。
1
Brian2019-10-28一边学习，一边思考我们公司现在的项目，如果用VSM的各项指标去衡量的话浪费极为严重。开展VSM活动对于我们而言，难点在于首先要让大家认同，不认同就意味着不会积极配合，也就没有办法通过会议或者走访的形式去挖掘最底层的问题。展开
工画师2019-10-28我是比较认同VSM中的价值流的。DevOps其实是与敏捷伴生的，但不是说没有使用敏捷的公司就无法开展DevOps，只不过落地实施会走样，当成效率工具罢了。个人认为要想发展DevOps甚至VSM，需要先搞清敏捷与价值流动，从文化和思维模式上进行转变，否则单说DevOps有些跟风了，无法发挥出内在的价值，也就不会有质的飞跃。展开
sugar2019-10-25目前问题还是比较多，看似上了很多平台、系统、工具提升效率，其实有时反而降低了效率，我觉得主要是文化及意识的问题，没有优先级，没个需求提出都说着急上，需要一个牵头人做整体的推动和沟通交流作者回复: 嗯嗯，缺少顶层设计和实施框架，的确容易野蛮生长，这也是现在很多公司部门都在搞DevOps的通病，开发和运维之家的壁垒还没解决，DevOps各家工具之间的壁垒先整出来了。
manatee2019-10-24想请问老师，关于价值流中的三个指标，前置时间我理解就是从需求到上线的时间，这个还好统计，无非就是确定一个个阶段再分段统计时间，那增值时间和完成度又如何在系统上实现呢。我的意思是这两个指标如何具体的去度量。就拿增值时间来说，这个如何定义，有没有什么标准，又如何在系统上自动化的统计呢，感觉完全没有思路，请老师指点展开作者回复: 你好，其实我在文章中也有提到过，稍微展开一下。
关于增值时间和不增值时间，可以划分为两个层面。首先是从全局的维度统计等待时间，如果你已经用了电子看板工具，那么一个任务从开始到结束的周期内，有多长时间处于等待状态，比如待开发，待测试，待发布，那这些都是典型的不增值时间。
其次，从微观角度，深入到各个环节内容，比如开发环节，统计那些除了真正写代码之外的活动时长，比如构建打包，比如提测任务，比如没人评审的提交，比如审批活动，这些理论上都是不增值的时间，可以尽量优化掉。
至于说开发本身的效率高低，这个不方便度量，但我相信，只要外部这些不增值的时间被优化掉，其实就能解决大头的问题。
关于完成度和准确率，完成度最简单的就是统计迭代周期内的任务，有多少按时完成了，有多少延期了，比如按时提测率，虽然刚开始的时候对于任务的工作估计会有很大偏差，但随着团队磨合以及对于业务的理解，这个估计会被不断的矫正，更加贴近于真实情况。
准确率方面，可以重点考察被下游打回的流程，比如研发提测后，测试发现自测不达标打回研发，可以统计提测打回率，再比如上线发布后，发现有问题出现回滚，那就是上线失败率，也可以进行统计。
关键点是，指标贵精不贵多，预期一次性度量10个指标，不如把一个关注点的指标做透，直到改进流程影响行为。
leslie2019-10-22VSM中“价值”：应当是最难的，现在的公司现有系统经常就在这个模块里的“识别问题”和“促进沟通”以及“价值展现”中一堆的问题；故而做了一系列关于现状的沟通，然后明白自己要想实现一些的梦想应当去哪里😀展开作者回复: 期待你的梦想成真😄
johnny2019-10-22像我们这种没有devops体系的公司来说，可能关注更多的是如何落地。
老师以后会多讲一些devops所涉及环节具体实践吗？
比方说，devops会涉及到一个持续集成/持续交付的环节（会用到jenkins、容器等技术），怎么实现？
我的意思是老师会不会以Adminset、jenkins或者其它运维平台或工具为主线，讲解devops落地过程的实践操作呢？展开作者回复: 你好，感谢你的留言，我在整理内容的时候，也在纠结工具本身的介绍要占据多大的篇幅，其实如果展开来说，每个工具都可以成为一个独立的专栏，所以权衡下来会采用实践为主，工具和案例为辅的方式，也就是先说明白为什么要做这个实践，实践的正确姿势是怎样的，再结合实践和工具列举一些小的案例帮助理解。至于工具本身，一方面网上有很多资料，另外一方面DevOps本身也不强依赖于某个具体的工具，所以我推荐还是以问题驱动学习的方式。你好，感谢你的留言，我在整理内容的时候，也在纠结工具本身的介绍要占据多大的篇幅，其实如果展开来说，每个工具都可以成为一个独立的专栏，所以权衡下来会采用实践为主，工具和案例为辅的方式，也就是先说明白为什么要做这个实践，实践的正确姿势是怎样的，再结合实践和工具列举一些小的案例帮助理解。至于工具本身，一方面网上有很多资料，另外一方面DevOps本身也不强依赖于某个具体的工具，所以我推荐还是以问题驱动学习的方式。
顺便说下，你既然提到了Adminset，也给你一些小的福利，关于这个工具的问题，我会收集起来邀请作者来跟大家一起互动哈。- delly2019-10-22以我所在的大型it服务公司的角度来看，我个人觉得价值流是挺难梳理的。因为照我的认知，基于itil的服务交付体系，大家的执行动力是以sla为驱动，工作模式基本都是等单子，看优先级，然后做单子。手里很多单的时候会按照优先级逐级去做，手里单子很少呢，有可能勤快点来个单子就做，也可能来了单子就等着，到快到deadline了才处理。每个人可能都处于在一个或多个时间区间内来回挪腾的状态，所以我的意思是这种情况下去弄清楚当前到底哪些是有效时间那些是无效时间是很困难的，都没个准，因为目前的工作模式本身就不是为了效率而服务的。而且就像文章提到的，即使使用了效率管理工具，都需要手动计时，太麻烦了根本就没有人愿意搞，数据也根本没有参考性。
相对这个，可能文章里提到的每个部门只了解自己的内容这个问题还更好解决一些，重点是要有能力把大量的资深员工或领导聚在一起开会讨论。
目前思路也比较混乱，但我觉得可能传统it服务公司想走上devops的道路，优化流程可能比工具重要很多……展开作者回复: 你好，感谢你的回复，我觉得说的特别好。
没错，问题的关键就在于组织的运作不是面向效率建设的，换句话说只要符合现有的流程前提之下，效率的高低其实并没那么重要。但是另外一方面，我们又看到ITILv4的指导原则，也体现出一种DevOps的特征，比如关注价值，关注现状，自动化，流程与反馈等等，所以你说的这种现状不会长期存在，迟早也会进行调整。除非IT服务变成了铁饭碗，也没有行业竞争的压力，那么当竞争的重心从服务全面性，到服务质量，再到运作效率的转变时，消除浪费也就在所难免了。
我还是始终强调一点，如果公司想在不改变流程的前提下推行DevOps，那么大概率是会失败的。所以思想和流程的共同转变，再辅以工具技术的支撑，才有可能改变现状。 1 
牧野静风2019-10-22看老师的专栏，对于企业技术管理，转型很有参考意义，除了软件交付上的流程更加通畅，高效，人员的水平提高也很有帮助，不仅仅在技术方面，很多软实力也是需要的。作者回复: 你好，我今天跟团队还在学习谷歌的代码评审文档，不知道你看了没？其中感受特别深的一点就是国外这些所谓的优秀公司，在总结规范和实践的时候，对人的关注非常高。比如举个例子，在谷歌的代码评审实践中，特别提到了要如何给出评审建议，怎么样的话术比较容易让人接受，如果两方争执不下，要怎么处理的好，甚至要关注评审双方的情绪，等等。
但是我们在做类似的事情的时候，很多时候都是指标先行，通过定义指标，来考核团队的落实情况，至于指标是否合理，人员的情绪是否有照顾到，说实话，并不太关心。这也是值得反思的一点吧。
蜗牛2019-10-22可能对于较大的，已有交付流程较为规整的企业来讲，价值流的整理会相对简单些……但是对于某些初创企业来说，本身的交付流程就相对混乱，这个时候就需要梳理人本身有一个已有的价值流模型来做作为参考，结合公司的流程现状来梳理，规划调整。不知道我的理解石老师会怎么看？ 对于初创企业的价值流整理有什么好的建议？展开作者回复: 你好，我非常认同你的观点，价值流梳理听起来很炫，但归根结底梳理的还是软件交付流程，这个流程并不是说梳理价值流才出现的，而是只要公司在开发交付软件，这个流程就一直存在，只不过没有人全局的来看，或者把他提到一个比较高的维度而已。
对于初创企业来说，压力大，人手紧张，再加上业务范围不确定，本身就是需要灵活变化的能力，这样看来，容错率更低的初创公司，对于DevOps的协作，自动化，全局优化更为适用。
作为价值流梳理的副产品，公司内部的持续交付流水线就是很多初创公司都在加强建设的方向，无论是基于云服务商提供的平台，还是内部自己搭建的平台，把这个事情说清楚了，价值流也就出来啦。 1
Robert小七2019-10-22目前金融行业中大部分的研发人员来自isv，而企业自有人员的研发能力不足，可能对价值交付流程不熟，对于不同的项目可能来自不同的isv，价值交付流程图也有很大区别，那么老师是如何对这类企业进行走访调查的？作者回复: 你好，根据我这一两年的经历，我可以很确定的说，金融企业对于软件的自我意识和把控诉求与日俱增，一方面自身软件交付团队和平台的建立有目共睹，另外一方面对于外包的质量，流程，交付节奏，甚至DevOps能力都再越来越严。
所以，即便每个项目合作方都不相同，软件开发流程也不相同，但是殊途同归，毕竟你总要有一种有效的衡量手段。而价值流中的几个核心指标，对于这一点来说很是很有帮助的。
