带端口的服务器怎么做网站,织梦网站模板源码下载,重庆品牌设计公司,软件外包上市公司作者 | 张乐
目录
1 数字化时代#xff0c;软件研发本身也要数字化
2 流框架及五大流动指标
1. 流动速率
2. 流动时间
3. 流动负载
4. 流动效率
5. 流动分布
3 研发过程中的常见瓶颈及解决思路
1. 稀缺的专家或资源#xff0c;导致流动受阻
2. 缺乏自动化或工程能…作者 | 张乐
目录
1 数字化时代软件研发本身也要数字化
2 流框架及五大流动指标
1. 流动速率
2. 流动时间
3. 流动负载
4. 流动效率
5. 流动分布
3 研发过程中的常见瓶颈及解决思路
1. 稀缺的专家或资源导致流动受阻
2. 缺乏自动化或工程能力落后导致效率低下
3. 繁琐的流程导致等待和长耗时
4. 过多的依赖导致工作流动停
4 总结
5 作者介绍 1 数字化时代软件研发本身也要数字化
你是否已经感受到我们已经身处数字化时代的关键节点上。
这里首先抛出一个有趣的问题一辆普通的小轿车里面的代码规模与桌面操作系统的代码规模哪个更大
也许你已经猜到了答案。
多年以前一辆小轿车里面大概只有 100 万行的代码用于基础驱动功能如牵引力控制随后不久就增长到了 1000 万行代码以满足越来越多的数字化、电子控制单元的增长以及电动汽车所带来额外控制软件的复杂性随着汽车互联和信息娱乐的发展在几年前一辆宝马汽车中已经达到 1 亿行代码随着自动驾驶技术的普及也许很快将会有 10 亿行代码。相比之下我们的桌面电脑上安装的操作系统有多少代码呢有资料显示微软 Windows 操作系统大概有 6000 万行左右的代码。
所以汽车已经变成了轮子上的计算机。 图 1现代化的汽车已经成为轮子上的计算机
这还只是一个小例子我想说的是我们真的已经身处在数字化时代的关键节点上。
但有点讽刺的是在数字化的时代作为 IT 从业者我们的研发管理方式有时还处于相对落后的状态。
很多企业还在使用上次技术革命所使用的方法延续了旧的行为和过时的思维方式。比如使用近百年之前衡量体力工作者的方法过度关注工作的时长、人力资源饱和度过度要求工作活动的标准化和整齐划一过度关注工作产出的代理指标开发人员写了多少行代码、测试人员测出来多少 Bug而不是最大化业务结果过度关注局部优化某个研发环节的自动化程度、使用了哪些 DevOps 工具而不是全局优化端到端的交付效率和质量......
以至于到了现在软件研发过程在很多情况下还是一个黑盒缺乏端到端的可见性哪里有拥堵、哪里有浪费、哪里有风险管理者可能并不清楚产品、开发、测试、运维各自的真实痛点也容易被埋没在无穷无尽的需求和工作当中更可怕的是时间一久大家也就习以为常了。
但是我们还是有追求的我们要想办法让软件研发本身也实现数字化。而数字化就是从物理世界中开采出数据粗炼出信息精炼出知识聚合出智慧最终提高生产力。
按照这个逻辑研发的数字化我们可以从建设有效的研发效能洞察体系开始。
研发效能洞察体系的话题很大涉及到研发的基础设施的建设、度量指标体系的设计、洞察分析模型的构建、洞察工具产品的实现、基于数据驱动和实验思维的运营等等。限于篇幅本文只展开其中的一小部分即重点聚焦于通过软件交付价值流管理方法中的五大流动指标对研发过程进行有效洞察并分析其中潜在的问题和瓶颈。 图 2研发效能洞察体系 2 流框架及五大流动指标
在 2018 年底有一本名为《Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework》著作出版书中指出业务与 IT 之间的脱节是数字化转型失败的根本原因之一并进一步提炼出了一个称为“流框架”的全新模型用来建立业务驱动的数字化转型与支撑它们的技术转型之间所缺失的那一层连接。
记得当时是何勉老师向我推荐了这本书我看到后真的有一种相见恨晚的感觉我认为书中的内容对于整个行业有很强的指导意义和很高参考价值随即我决定要与朋友们一起将它翻译成中文版本即将出版敬请期待。
本文我们就先聚焦于流框架中的五大流动指标。 图 3五大流动指标
大家可能要问为什么要称为“流动”指标呢
这是因为精益思想是流框架及其相关流动指标设计的底层逻辑正如精益思想的五大原则所强调的我们要应该按照具体产品精确地定义价值、为每款产品定义价值流、使价值不间断地流动、让客户从生产商拉动价值以及追求尽善尽美。
所以基于精益思想流动指标度量的就是价值的流动它们共同指征了一个组织交付价值过程中的效率水平和健康程度。流动指标共有五个分别是流动速率、流动时间、流动负载、流动效率和流动分布。综合利用好这五个指标我们就可以讲述一个关于软件研发价值流完整的故事回答关于研发交付效率如何的本质问题。
1. 流动速率 图 4流动速率 指标定义
在给定时间内完成的流动项如需求、缺陷或其他各种类型的工作的数量流动速率可用于衡量生产力。 如何使用
跟踪流动速率以有效评估并预测团队可以交付多少工作。当流动速率过低时需要及时调查原因可能会存在资源紧缺、架构或基础设施等问题也有可能存在大量等待导致的流动停滞。 指标解读
数值升高
一般表明价值交付正在加速
数值降低且流动时间很长
一般表明交付存在阻塞、依赖或在制品过多导致的工作切换浪费 常见问题
流动速率与敏捷的速率概念有什么区别
流动速率从敏捷的速率概念改编而来后者表明了团队在一个时间段内例如两周的迭代交付了多少个工作单元例如故事点数。但流动速率计算的是在给定时间内完成的流动项的数量假如一个版本完成了 10 个需求和 5 个缺陷则该版本的流动速率为 15。所以这里的关键区别是流动速率更简单它不依赖于对工作量大小、范围或每个流动项优先级的估算。 流动速率为什么按需求个数来算而不是按故事点来算
诚然流动项的大小可能会大相径庭这会让人们倾向于用“故事点”或“T 恤”进行估算。
但是使用故事点的估算会容易引发规模冲动人为的多估算一些反而可能会更不准确也经常因此出现业务 / 产品与研发团队之间对数字的博弈。
所以流动速率更倾向于用流动项的数量而非故事点来进行估算根据大数定律如果有足够的试验或实例事件发生的可能性就是均等的如果有足够多的流动项那么在一个时间段内所有流动项都很大而另一个时间段内的所有流动项都很小的情况应该很少出现。
另外对于工作项的合理拆分如把需求分解为业务需求 - 产品需求 - 技术任务一定程度上也会降低需求颗粒度的差异对指标准确性带来的影响。如果实在不放心我们在度量流动速率指标的同时也可以将需求规模如开发 测试的工作量作为辅助参考指标一起进行观测。
还需要注意的是流动速率的度量更适合于跟踪一个价值流内的生产力和交付趋势而非跨价值流进行比较。
2. 流动时间 图 5流动时间 指标定义
从流动项被接受并进入价值流一直到其完成所花费的时间包括了工作处于活跃状态的时间和等待状态的时间。 如何使用
跟踪流动时间通过概率思维让交付时间变得更可预测并相对准确地回答一个核心问题“工作到底什么时候可以完成?”。根据研究交付周期类指标一般符合韦伯分布Weibull Distribution所以建议使用 85% 分位数而非平均值来对流动时间进行度量和预测。 指标解读
数值很低
我们当然希望流动时间不断缩短。但是看到这个数值很低的时候也别高兴的太早了要多看看工作有没有被准确跟踪。比如我们在实际工作中经常出现“后补”需求的情况比如开发完成到了要上线的时候因为上线单要关联一个需求单这个时候再到看板中补上一个需求然后从第一个阶段直接拖动到最后一个阶段。类似的情况会导致指标的失真而指标的准确性是度量的根基我们需要额外关注。在实践过程中我们经常在观测主指标如流动时间的同时增加一个关于数据健康度的辅助参考指标如异常数据的比例以确保主指标的置信度。
数值很高且流动速率很低
有可能是因为在制品过多导致的工作切换或者工作被阻塞产生了大量的等待时间让流动时间被拖长。我们可以结合下面的流动负载和流动效率一起进行更细化的分析。 常见问题
前置时间、周期时间、流动时间有什么区别 图 6流动时间 vs 前置时间
在精益生产中有两个关键指标用于流程改进分别是“前置时间”和“周期时间”。前置时间侧重于度量整个流程的时间工作从“新建”状态开始到“完成”状态之间的时间差而周期时间则侧重于完成过程中某个步骤所花费的时间如“开发”阶段的周期时间。前置时间可以告诉我们端到端流程运行所花费的时间周期时间可以帮助识别瓶颈周期时间最长的步骤通常就是瓶颈所在。
但为了避免混淆流框架使用了名为“流动时间”的新指标。流动时间始于工作被显式接受例如新需求评审通过并进入排期或隐式接受例如自动升级的事件的时刻这与前置时间从工作被提出就开始计时完全不同。流动时间可以作为对产品研发团队交付效率的观测指标即从确定要做某项工作到完成所需的时间而前置时间更多是从需求方视角进行观测即从需求提出到完成所需的时间。
为什么没有采用 DevOps 社区中常用的变更前置时间
每年的 DevOps 全球调查报告和 DevOps 社区中经常使用名为“变更前置时间”的度量指标英文是 Lead time for changes即代码提交到部署的前置时间。虽然我们也经常采用这个指标进行效能度量和分析但它并没有被流框架所采纳。 图 7变更前置时间变更
前置时间更多的是以开发人员为中心的视角而不是以客户为中心或以价值流为中心的视角进行设计的所以它并不足以封装业务价值虽然是团队工程能力的重要指示器之一但本质上是更偏局部、更偏过程性的指标。而流动时间的视野更广观测的是工作项在软件交付管道中端到端的流动是更偏全局、更偏结果性的指标。
流动时间是按自然日来算还是工作日来算
上文已经讲到流动时间是一个以客户为中心设计的指标因此它是以“自然”时间而非“工作日”来进行计算和度量的。
3. 流动负载 图 8流动负载 指标定义
价值流中在制品的数量已开始、未完成即正在进行中的工作包含了状态为活跃或等待的流动项的数量。 如何使用
流动负载是一个先导性指标可以用来发现在制品过多对速度类指标和团队满意度的影响。我们可以通过不断调整和实验找到产品价值流最优的流动负载此时流动速率较高并且流动时间较短。流动负载可以让产研团队与业务需求方更好地进行协作在需求与产能之间寻求平衡。 指标解读
数值较低
可能只有少量的工作正在完成可能出现了闲置的情况。
数值较高
过多的流动负载在制品很可能会导致交付延迟、成本增加、质量下降、员工抱怨长期超过团队产能安排工作将导致职业倦怠。还可以进一步分解为以下两种情况。
数值较高并且流动时间很短
可能有很多的工作被忽略或搁置了即存在很多“僵尸需求”一直停留在交付管道中却又因为优先级一直没有时间处理。这时需要清理在制品评估真正需要完成的工作。如果真的重要就让工作继续及时推进如果不重要就干脆把工作移出交付管道。
数值较高并且流动时间很长
在制品过多导致的工作切换可能是罪魁祸首过高的流动负载直接影响了交付效率。这时可以采用精益实践限制在制品并采用拉动模型如采用精益看板的方法。可能还要为资源不足的角色 / 岗位增加容量或提升自动化的水平。 图 9基于利特尔法则的流动时间预测
特别需要注意的是根据利特尔法则流动时间 流动负载 / 流动速率当流动负载的当前值已经高于流动速率 * 流动时间的预测值则预示未来会有工作无法如期完成。这时就已经发现了未来交付计划及周期的风险需要对流动时间的预测进行修正进而实现更准确的承诺 / 决策这正是先导性指标的价值所在。 常见问题
流动负载应该从何处开始计算尚未开始的工作要计算么
如果将价值流想象为一条管道其中所有尚未开始或已经完成的流动项都在管道的两端而流动负载就是管道内正在进行的工作单元数包括所有部分完成的流动项。当流动负载过大由于队列时间过长价值流的过度利用会极大地影响交付速度。
流动负载有没有绝对数字来说明好坏
业界很难有一个绝对的数字来说明流动负载应该是多少不同业务类型、处于不同发展阶段的团队对流动负载的承受能力都有很大差别。所以建议采用实验思维关注流动负载的高低导致了流动速率和流动时间怎样的变化从而找到一个适当的平衡点。追求过高的资源饱和度对产品开发而言并没有任何好处。百分之百资源利用率对于制造业和软件交付都存在同样问题都会对流动速率和流动时间产生很大的负面影响。
流动负载如何进行有效下钻找到具体问题
可以通过停滞项工作报告展示在交付管道中有哪些未完成的工作以及它们在当前阶段已经停滞了多久的时间。 图 10停滞项工作报告
通过查看系统中指定天数如 10 天没有进展的工作可以发现系统中的问题和瓶颈一方面找到并消灭较低价值的 “僵尸需求”减少被搁置的工作另一方面识别出被阻塞的工作通过当前阶段及上下游的协同优化促进它们尽快恢复流动。关于研发过程中的常见瓶颈我会在下一小节中进行讨论。
4. 流动效率 图 11流动效率 指标定义
流动项处于活跃工作状态的时间占总消耗时间的比例。 如何使用
度量流动效率可以帮助团队从瓶颈中可视化等待时间以便找出导致流动停滞的问题。流动效率越低工作停滞在等待状态的时间就越长。此指标可以与其他流动指标结合使用重点聚焦于减少等待时间。 指标解读
数值较高
流动效率越高一般表明交间它涵盖了开发上下游的等待时间。如果开发团队在等待用户界面设计而设计人员被分配到了其他工作则流动效率会下降因为相关需求处于等待状态原因是这两个团队都没有处理它们。因此可以通过追踪流动效率降低的原因来识别价值流的瓶颈。付过程越顺畅、越没有阻塞。但也要警惕指标过高的情况例如超过 40%这可能意味着状态映射错误或不准确比如把实际上是等待的阶段映射成活跃状态了这样就会导致这个指标虚高。
数值较低
一般表明存在瓶颈、低效的流程、过多的依赖关系、资源匮乏等这些问题会导致流动负载的增加更长的队列以及更长的流动时间。 常见问题
流动效率基于流动时间还是周期时间来计算
流动效率是基于流动时间而不是周期流动效率是基于流动时间而不是周期时间它涵盖了开发上下游的等待时间。如果开发团队在等待用户界面设计而设计人员被分配到了其他工作则流动效率会下降因为相关需求处于等待状态原因是这两个团队都没有处理它们。因此可以通过追踪流动效率降低的原因来识别价值流的瓶颈。
流动效率的正常值应该多少合适
我在行业中经常看到一些统计数据很多企业的实际流动效率要比想象中低很多有些采用传统研发模式、规模较大、流程较复杂的团队流动效率甚至不到 10%。在能进行准确统计的情况下指标没有虚高对很多企业而言如果流动效率达到 30-40%就已经算是不错的水平了。
5. 流动分布 图 12流动分布 指标定义
通过显示在给定时间内完成的流动项特性、缺陷、风险和债务的比例来衡量在不同价值创造类别中的实际投入。 如何使用
利用流动分布来为价值流中不同类型的工作带来可见性这样就可以从优先级的角度看到当前投入的重点在哪里。如果统计出来的流动分布相当于资源的分配与业务优先级不一致则需要进行调整。流动分布通过使资源的分配可见推动产研团队与业务需求方进行各类工作优先级的权衡而这里的权衡是一种零和游戏。另外流动分布随着时间的推移根据产品所处的阶段需要进行持续调整和演化。 指标解读
缺陷占比很高
一般表明缺陷和未计划的工作降低了需求交付的能力对于技术债务的投资可能需要加强。
缺少技术债务和风险的占比
相关工作被忽视或延后虽然短期看起来交付的需求多了但未来可能会出现债务危机。 常见问题
每条价值流的流动分布应该如何设置
流动分布会随着时间的推移不断发生演化。新产品的价值流通常被调整为最大化需求交付的比例。一旦该产品上市并且有稳定用户就有必要构建额外的能力来处理可能出现的支持工单和故障并且还要安排一些工作来减少在随后发布周期中不断积累的技术债务。
以上分别展开介绍了五大流动指标的定义和解读方法相信大家已经对如何使用它们有一些感觉了。但还有一点需要注意的是这些指标还是停留在软件交付层面上的我们还应该将研发工作映射到业务结果。将研发效能度量指标与业务结果关联在一起可以使用真实的数据来确定相关性并不断地学习和调整。
常见的业务结果指标包括价值如收入、年度合同价值、业务活跃用户数等、成本如人力成本、运营和基础设施成本等、满意度如净推荐值、员工净推荐值等考虑到篇幅有限关于如何将五大流动指标映射到业务指标的方法及案例本文暂不展开后面有机会再介绍。 3 研发过程中的常见瓶颈及解决思路
通过对五大流动指标我们可以对软件交付过程进行有效的度量和分析并透视出其中潜在的问题和瓶颈。下面我们就简单讨论一下研发过程中的常见瓶颈及其解决思路。
1. 稀缺的专家或资源导致流动受阻 图 13瓶颈导致流动受阻 现象
某个活跃状态阶段如 “开发”存在瓶颈在此之前的等待状态阶段如 “待开发”出现大量堆积工作在制品数高、周期长。 解决思路
在存在瓶颈的活跃状态阶段增加有技能的资源但临时加人可能会导致额外的负担反而降低生产力对团队成员进行专业技能培训或是跨专业的横向培训通过自动化、自服务、流程优化或规范简化解决。
2. 缺乏自动化或工程能力落后导致效率低下 图 13缺乏自动化导致的效率低下 现象
人工流程或者主要由人工完成的交互成为流动的瓶颈比如代码需要在预发环境测试但测试资源紧缺且资源申请不是自服务的有大量需求堆积在等待测试阶段。 解决思路
实现自动化流程引入自服务机制提升工程能力通过自动化手段提升吞吐量不依赖于资源或专家就绪从而提升效率不依赖于某个中心化的团队按优先级完成工作如发布审批、环境申请等。
3. 繁琐的流程导致等待和长耗时 图 14繁琐的流程导致等待 现象
变更审批委员会如两周举办一次审批会议无论前面交付多快都要等待、安全审批、资金审批等工作处于等待状态如“等待审批”处于这些状态的制品数很多在选定时间范围到达高水位线而后周期性下降。 解决思路
以高水位线最大制品数量为线索找到瓶颈点问题所在即使当前数值已经回落。自动化变更审批流程识别出高风险变更的标准哪些是必须要走审批哪些是低风险变更可以自动化验证、直接部署。
4. 过多的依赖导致工作流动停 图 15过多的依赖导致流动停滞 现象等待某事或者某人完成后才能继续工作。
架构依赖软件或硬件一个部分的变更造成另一个部分的功能被破坏例如 DB 变更导致对方的功能调用无法工作
专业知识或专家依赖需要特定专业知识的专家如业务专家、安全专家的输入才能继续完成既定工作
活动依赖或事件依赖需要等待其他的活动完成否则流程无法进行。如甘特图里的几个前置任务之间的依赖关系 解决思路
图 16三种依赖及其解决思路
对依赖建模如使用依赖矩阵与依赖方沟通探索解决方案长期方案要花时间去除依赖而不仅仅是管理它们。架构层面找到系统的断裂面进行架构解耦组织层面建立跨职能团队进行组织解耦。活动层面提升自服务和自主性进行活动解耦。
最后要说的是对于研发过程中的瓶颈我们要通过系统思考以流动指标为牵引观测整个价值流以整体的方式思考约束。找到瓶颈并明确解决思路后在实施改进时要注意一次只解决一个问题而不能贪多、追求大而全这样才能独立观察每项措施带来的效果和影响。 图 17基于数据驱动和实验思维一次只解决一个问题 4 总结
本文核心观点如下 数字化时代软件研发本身也要数字化。 研发的数字化可以从建设有效的研发效能洞察体系开始。 基于精益思想流动指标度量的就是价值的流动指征了一个组织交付价值过程中的效率水平和健康程度。 流动指标共有五个流动速率、流动时间、流动负载、流动效率和流动分布。 综合利用好这五个指标我们就可以讲述一个关于软件研发价值流完整的故事回答关于研发交付效率如何的本质问题。 研发过程中的常见瓶颈包括稀缺的专家或资源、缺乏自动化或工程能力落后、繁琐的流程、过多的依赖等这些瓶颈都会导致流动受阻、让工作陷入停滞导致等待和长耗时。 对于研发过程中的瓶颈我们要通过系统思考以流动指标为牵引观测整个价值流以整体的方式思考约束。 实施改进时一次只解决一个问题这样可以独立观察每项措施带来的效果和影响。 5 作者介绍
张乐
腾讯技术工程事业群 DevOps 与研发效能资深技术专家前百度工程效率专家、前京东 DevOps 平台产品总监与首席架构师曾任埃森哲、惠普等全球五百强企业咨询顾问、资深技术专家。长期工作在拥有数万人研发规模的一线互联网公司专注于研发效能提升、敏捷与 DevOps 实践落地、DevOps 工具平台设计、研发效能度量体系建设等方向是 DevOpsDays 国际会议中国区核心组织者国内多个 DevOps、工程生产力、研发效能领域技术大会的联席主席、DevOps/ 研发效能专题出品人是《研发效能宣言》发起人及主要内容起草者EXIN DevOps 全系列国际认证授权讲师、凤凰项目沙盘授权教练。著作《软件研发效能提升实践》、译著《独角兽项目数字化转型时代的开发传奇》
