如何分步骤、阶段性地真正提升软件交付效能？
极客时间编辑部
讲述：丁婵大小：2.11M时长：04:37
近日，在 TGO 鲲鹏会的杭州分会活动中，KodeRover 创始人李倩分享了分步骤、阶段性提升软件交付效能的经验和方法。在上一篇文章中，我们已经了解到了软件交付的关键点和挑战，本文继续分享提升软件交付效能的具体方法。
目前，很多团队在持续集成工程实践方面做的很好了，但有相当一部分团队测试或部署过程是人工的、非连续的。而这正是影响交付效能的重要因素，实现全流程的自动化是软件持续交付、效率提升的关键。
业务团队可以通过业务拆分、采用微服务架构进行并行开发，但不能连续测试、持续部署到环境中。建立持续交付能力帮助 QA 不间断地进行业务校验，提供环境或者业务验证机制，或帮助开发自主验证。优秀的工程实践是把共性的部分，即每个人都要花大量时间的部分自动化掉。
李倩在长期做一个“工程师自己认为时间花在何处”的调查。统计结果显示，仍然有 55% 的工程师认为自己在做杂事，很少有时间安心写业务相关的代码。这很奇怪，作为工程师大部分时间却不在写代码。如果我们能将没有时间写代码的问题解决掉，效率就能提升。
李倩从事质量或效率工程很多年，一直在寻找一个答案：有没有一种基于指标的度量模型可以准确衡量一家公司的软件交付效能 。通过多年的探索，她发现代码量、PR 量、覆盖率、需求数量、缺陷数量等指标都不合适，无法提升效能甚至会带来副作用。那么什么样的指标更有价值？李倩发现基于不同的改进目标，面向人、流程、技术建立多视角的度量，根据成熟度选择适合自己企业特性和现阶段发展的指标，不仅可以提升效能还可以增进工程文化。
首先要面向流程改进，尤其需要注意打回率和各种测试的平均耗时。QA 的高打回率指标可以推动研发自测，减少返工情况。各种测试的平均耗时则显示你花费了多少时间在验证，比如花了很长时间在 UT 上，假如一个同学提一个 PR，运行了 20 分钟，要是每个人都耗 20 分钟，那其他人等这个代码集成，时间损耗就很大了，这是特别容易忽略的效率。
李倩很推崇从工程技术角度度量，首先这些指标最能代表核心效能，比如 CI/CD 是交付核心的效率，覆盖率是交付核心的质量指标。另外，对于工程师而言，客观逻辑至上。相比”写了多少代码，解决了多少个缺陷，完成了多少个需求“等指标，客观技术指标非但不会损伤开发者的尊严，反而给大家更强的目标感，完全可以用于关键绩效的依据。
同时，每个企业都应该有核心的北极星（North Star）指标，这是可以建立绩效的点，是老板关注的点，也是员工可以努力的方向。
当然，还要考虑事故处理能力。事故就是针对企业内在流程机制的考验，故障恢复时间可以作为核心内部作为绩效指标。
其他的指标在此就不详细阐述了。如何选择度量指标，要取决于企业阶段性的研发运营目标是什么。比如最近对外缺陷很高，可以拿缺陷性指标去度量。另外，想要建立这样的度量体系，还需要注重自动化体系的搭建，需要有自动化能力，并且可以持续收集数据。
但请注意，不要陷入一个误区：在自动化能力不强的情况下，就去统计指标，指望通过 1-2 个月去收集到全团队指标来度量团队效能和评比，真正的度量和优化需要长久的运营。
随着时间的推移，问题驱动转向数据驱动，团队通过数据可以清楚短板在哪里，就可以定向解决这个短板，最终让研发团队从软件生产过程的数据中成长获益。
以上就是今天的内容，希望对你有所帮助。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论