最近几年 “软件研发效能” 成了业界的热词 ,频繁出现在各个行业大会,被各大厂、传统行业数字化部门、追求高效能的团队不断的提及并迭代,比如阿里的效能改进211愿景,腾讯的智研平台,百度工程能力白皮书。那么为什么软件研发效能会成为热词,有哪些合适的软件研发效能指标呢? 本文想尝试回答这两个问题。(本文是此系列的上篇,后续两篇将尝试构建一个根据团队上下文的软件研发效能推荐指标图表,和一些实际度量指标的案例。)
为什么软件研发效能会成为热词?
咱们先看看现有的问题, 与传统制造业相比,软件研发行业还很年轻,并没有达到传统行业的大规模流水线的生产方式,这解释了为什么没有一种统一的,被广泛认可的方法来衡量开发人员或研发小组的效能。研发效能的度量很大程度上取决于公司的类型,规模,文化,与之合作的项目类型以及其它诸多因素。甚至某些小而精,依靠聪明才智和资深经验的创业团队,不用度量研发效能,团队依然非常高效。很显然,10年前使用代码行数(Lines of code)来度量研发效能的方式已经不适用现代敏捷过程对软件研发的理解了。以前关注代码产出,而不是业务成果,以前关注个人绩效,而不是团队效能。例如: 随着公司和开发人员向着价值驱动和基于团队开发方向的转变,代码行数不再具有任何意义。100行代码是否比20行好?行数是否告诉你取得了良好的进展,还是只是一个没有上下文的抽象指标?软件企业都在寻求其它有效的指标来度量研发效能。同时,如今的软件行业已经不再是“以大吃小”的时代了,而是转变成了“以快吃慢”的时代。对于很多大型软件企业、传统行业的数字化部门。原本“大”是优势,现在却陷入了“大船难掉头”的尴尬。如何破局?研发效能具体来讲就是从需求转化成软件或者服务的能力。改善研发效能从某种方面也在试图解决“大船难掉头”的尴尬。研发效能试图在解决度量和让研发变快的问题,那为什么会成为热词? 为什么最近几年各大厂、传统行业数字化部门、追求高效能的团队,都纷纷开始在研发效能领域发力,我认为这背后的原因有以下四点:
有哪些合适的软件研发效能度量指标呢?
上面基本回答了研发效能为什么会成为热词,那什么才是软件研发效能中合适的指标呢? 要度量哪些指标和数据呢?根据不同的场景和目标人群需要给出相应的度量指标。正如《关键对话》中建议的,需要根据信息接收者的兴趣点来构建沟通策略和沟通内容。从研发效能DevOps角度 《Accelerate》 这本书给出了4个指标和评价标准。研发效能是一个比较大的话题,如何根据不同的关注点,给出不同的指标呢?Roy Osherove 的 “Lies, Damned Lies, and Metrics”也给出了很好的归类。根据我们在项目中的实际使用和经验总结,这里把当前常用的度量指标归类如下:
当您在为团队寻找研发效能指标时,其实并没有一个恒定不变的模板,需要分析多个因素,选择最适合您的指标,并与团队一起不断的使用它们,不断的根据价值交付为导向来修改和迭代。您自己团队的度量指标很可能与其他公司或团队的指标完全不同,这是完全正常的事情。因为正如前面提到的,研发效能的度量很大程度上取决于公司的类型,规模,文化,与之合作的项目类型以及其它因素。
下篇,将尝试使用项目类型,合作方式,等因素做为维度,放入已知的这些指标,构建一个推荐图表。帮您在了解这些情况之后,选择合适的指标。同时也会列举一些实际度量指标的案例(中篇),并讨论前置业务不明朗时 (fuzzy front end),如何统计前置时长(lead time)的起始时间。
本文分享自 ThoughtWorks洞见 微信公众号,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文参与 腾讯云自媒体同步曝光计划 ,欢迎热爱写作的你一起参与!