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