软件工程原理与实践 11 软件研发效能度量.ppt

**度量的过程实际上是要把数据转化为信息，然后将信息转化为知识，这样就可以让用户自主消费数据，进行分析和洞察。***标准化的研发流程、云化的工具链是基础****驾驶舱**在企业研发效能度量体系建设的初始阶段，大家的关注点可能都聚焦在度量什么样的指标、如何采集和计算、如何展示报表等问题上，这只是在做一些单点能力的建设，但并没有形成体系。随着持续深入的推进，需要更加系统性地思考，建立研发效能度量体系。*****基于这样的度量体系，我们应该设定怎样的目标呢?阿里巴巴内部做团队效能改进时，提出了称之为“2-1-1”的愿景，得到了不少部门的认可。什么是211呢?“2”指的是交付周期2周——85%以上的需求可以在2周内交付；第一个“1”指的是开发周期1周——85%以上的需求可以在1周内开发完成；第二个“1”指的是发布前置时间1小时——提交代码后可以在1小时内完成发布。*蚂蚁集团累计沉淀了2200多个指标。这些指标，经过研发洞察平台的处理，自动识别异常，转化为自动分析结论，并匹配相应的解决方案实践建议，分层、分角色、分场景输出，让全组织使用数据持续优化和改进。**在这四个指标中，前两个（部署频率、变更前置时间）用于衡量吞吐量，后两个（服务恢复时间、变更失败率）用于衡量稳定性。**业界流传着一个关于代码质量度量的小段子：唯一一个可以衡量代码质量的指标，是代码评审时，评审者每分钟骂脏话的次数。?我们知道，国内外互联网行业的很多效能标杆公司都非常重视代码评审（CodeReview），比如Facebook、Google等就要求每一个提交都必须通过评审。代码评审可以尽早发现Bug和设计中存在的问题，提高个人工程能力，增强团队知识共享，有助于统一编码风格。但大多数国内公司还是对代码评审理解得不够深入，对评审方法的认识也不够全面，只能简单地去追随一些所谓的最佳实践。结果就是，有些团队的代码评审推行不下去，半途而废；有的则流于形式，花了时间却看不到效果。?那么对于代码评审的度量，如何开展呢？下图就给出了一个在某互联网公司代码评审的不同的成熟度阶段所采用的度量指标：?在启动阶段，重点度量代码评审活跃度千里之行，始于足下。我们面对的第一个问题是度量代码评审是否开展起来了，这个时候可以选择的指标包括代码评审活跃率、强制代码评审开启率、代码评审发起数、代码评审参与人数等。?在上一步基础上，度量代码评审有效性这个时候代码评审已经有了较大规模的应用，我们重点要度量的是评审是否有效，是否发现了代码的问题。这个时候可以选择的指标包括代码评审覆盖率、千行有效评审评论数、评审平均交互次数等。?在前两步基础上，度量代码评审的效率代码评审的活跃度和有效性都没有问题的时候，我们对团队提出了更高的要求，即评审效率要相对比较高。这个时候可以选择的指标包括评审响应时长和评审时长等。当然，这个指标的目标值设置也不能过于激进，我们希望在评审能够及时响应与尽量不破坏评审者的心流工作状态之间找到平衡。**有个著名的定律称为古德哈特定律，其内容是：当某个度量变成了目标，它便不再是一个好的度量。效能度量的出发点是好的，但当它演变成了与绩效考核挂钩的KPI，大家都有追求自己切身利益的动机，那么各种有创造性的、为了提升指标而进行的不优雅的短视行为就会纷纷上演，度量走偏就在所难免了。关于古德哈特定律，最形象的例子来源于一个经典的理论：「眼镜蛇效应」。在英国殖民印度时期，德里这个地方的眼镜蛇泛滥，由于这种蛇毒性很强，所以对人们的生活造成了很大影响。为了解决这个问题，英国政府想了一个方法：民众每上交一条打死的眼镜蛇，就能领取赏金。一开始，人们为了获得奖金，争先恐后地捕杀毒蛇，导致毒蛇数量大幅减少，政策颇有成效。可是好景不长，一些人嗅到了政策漏洞中隐藏的商机：政府只看死蛇，并不清楚蛇是怎么来的。于是，他们开始自行养殖眼镜蛇，并定期宰杀上交，来获取赏金。政府发现这一切后，果断停止了奖励的发放。眼见无利可图，这些人就把大量已经失去价值的眼镜蛇，放生到了野外。最后，眼镜蛇的数量非但没有因为政策而降低，反而大大增加了。比如以“手术成功率”来考核医生，医生就会刻意回避疑难杂症和重症病人，医生的“手术成功率”是提高了，但重症病人却得不到救治。*千行代码缺陷率是被大家广泛熟知并且不少企业正在使用的一个代码质量相关的度量指标，但是这个指标真的能客观反应代码的质量吗？这个指标真的是一个合格的指标吗？这里我不直接给出结论，而是带着大家一起来分析一下，让你自己得出结论。工程师A的技术能力比较差，实现需求X用了20000行代码，同时引入了158