软件度量指标合集

度量合集

有哪些合适的软件研发效能度量指标呢h3>

上面基本回答了研发效能为什么会成为热词，那什么才是软件研发效能中合适的指标呢度量哪些指标和数据呢不同的场景和目标人群需要给出相应的度量指标。正如《关键对话》中建议的，需要根据信息接收者的兴趣点来构建沟通策略和沟通内容。从研发效能DevOps角度 《Accelerate》 这本书给出了4个指标和评价标准。研发效能是一个比较大的话题，如何根据不同的关注点，给出不同的指标呢oy Osherove 的 “Lies, Damned Lies, and Metrics”也给出了很好的归类。根据我们在项目中的实际使用和经验总结，这里把当前常用的度量指标归类如下：

• 规划进度：评估进度，获取背景信息和上下文，知道任务何时完成，预测问题（未来），对问题复盘与回顾（过去）。
  • 燃尽图 (每个迭代/每个发布) （Burn down chart sprint/release)
  • 速率图 (Velocity chart)
  • 标准差 (Standard deviation)
  • 吞吐量（Throughput)
  • 累积流程图 (Cumulative flow diagram)
  • 控制图 (Control chart)
  • 看板 在制品限制图 (Kanban WIP board)

• 快速反馈：持续集成，持续部署。
  • 构建与部署速度 (Build & Deploy speed)
  • 测试速度 (Test speed)
  • 代码签审时长 (PR approval Time)
  • 单元测试通过速率 (Unit tests passed)
  • 集成测试通过速率 (Integration tests passed)

• 团队转型：使用特定指标来衡量不同工作方式的方法，可以影响行为，帮助改变人们的行为方式。也可以向管理层说明某些事情不合理，需要改变，或者说明需要更多的时间和预算。
  • 结对编程的时长 (Pairing Time)
  • 手工测试的时长 (Time spent manual testing)
  • 代码签审时长 (PR approval Time)
  • 修复失败构建的耗时 (Fix red build time)
  • 修复Bug的耗时 (Cost of fixing bug in Dev/Prod)
  • 测试覆盖率 (Coverage test count)
  • 功效分配比率 (Effort allocation, New work / Unplanned work or rework / Other work)

• 辅助决策：可进行实验并不断寻找新的度量指标，帮助做决策。
  • 前置时长 (Lead time)
  • 发布出去的Bug数 (Escaped bugs 线上逃逸Bug数)
  • 功效分配比率 (Effort allocation, New work / Unplanned work or rework / Other work)
  • 交付的价值 (Valued delivered)

• 工程能力： 4 key metrics 度量并找出团队工程实践的弱点。
  • 变更前置时长 (Lead Time for Changes)
  • 部署频率 (Deployment Frequency)
  • 变更失败率 (Change Fail Rate)
  • 服务恢复耗时 (Time to restore service)

在正常负载的情况下，响应用户的输入的平均响应时间必须控制在500～1250毫秒之间，超过1500毫秒会影响用户操作；在500毫秒以下，人的反应速度无法触及。

 有效的质量保证手段——同行评审（Peer Review），以此可以提前发现许多软件各阶段隐含的问题。比如：
　　*在需求阶段的评审：发现需求是否已被很好的定义，其中是否存在技术上的风险等；
　　*在设计阶段的评审：检查架构数据库等设计的是否合理；
       *在编码阶段的评审：检查Source code,发现代码中不符合编码规范部分；
　　*在测试阶段的评审：检查测试计划安排的是否合理，测试用例设计的覆盖率等；
　　*在验收阶段的评审：检查项目文档是否都已存在于配置管理库中；总结项目开发过程中的一些经验教训并作记录，存入公司的资源库等。 过程中需注意的细节
　　

做评审计划,人员不要太多，保证会议的效率经常性地举行.