• Five_reasons
  • Cal2_20220108
  • Hardware-agile-practice
  • 2020-scrum-guide-banner
  • Clp_20220108
  • A-CSM 国际Scrum联盟认证 ScrumMaster
  • 敏捷思维 领导力 企业培训 国际Scrum联盟认证
  • 汽车行业敏捷开发课程
  • CSM A-CSM Scrum敏捷实践
  • 敏捷领导力认证培训  CAL认证培训 CST CSP
  • 30天软件开发 敏捷规模化实践 Scrum精髓 敏捷文化
  • CSM CSP CAL CSPO CSD CST CEC CTC
  • Scrum敏捷培训 Scrum敏捷企业内训
  • Scrum敏捷软件开发管理 企业内训 Scrum转型
敏捷度量实践

软件研发工程效能度量是一个非常宏大的话题,我们从如下几个维度展开探讨:

  · 为什么需要度量?

  · 如何定义有意义的度量目标?

  · 如何实现有效度量?


为什么需要度量?

做一件事知道其主要目的,才能有更多的热情和积极的心态把事情做好。

管理学大师彼得德鲁克曾经说过“如果你无法度量它,就无法管理它”(“If you can't measure it, you can't manage it”)。对于软件研发工作,这句话同样一语中的,度量是一切技术改进和决策的前提。

从精益价值流来看,如果可以对软件研发工程效能进行有效度量,我们可以定位系统瓶颈,减少浪费,提高生产效率。

从Scrum框架的理论支柱来看,Scrum框架是基于经验主义三大支柱透明、检视、调整,度量可以对检视提供帮助,并对调整提供有针对性的指向。

如果缺乏有效的度量,技术工作就如盲人摸象,偏离目标是大概率事件。


如何定义有意义的度量目标?

既然度量有如此多的好处,那如何定义有意义的度量目标呢?我们度量的领域是软件研发工程效能,那什么是软件研发工程效能,沿用马斯克第一性原理,软件研发工程效能可以定义为“顺畅、高质量地持续交付有效价值的闭环”。

  · 顺畅:价值的流动过程必须顺畅,没有阻碍。

  · 高质量:交付以高质量标准交付到客户手中,如果质量有问题,流动的越快,负面影响也越大。

  · 持续:不能时断时续, 小步快跑才是王道。

  · 有效价值:客户的真正痛点有没有解决,换句话客户愿不愿为软件买单。

  · 闭环:持续的闭环反馈,才能引发有效改进,提高客户粘性,提升客户满意度。

定义软件研发工程效能的指标可以从其定义出发,找到着手点。对基础能力,产品交付和业务价值进行分层和定义构建一套度量体系。

  · 基础能力层:完善基础设施,通过对人和工具的指标度量,促进研发能力的增强,保障高效执行。

  · 产品交付层:以流动效率为核心,关注过程指标,致力于效率、产品和成本的平衡。

  · 业务价值层:以业务目标为核心,交付准确、优质的产品,达到预期的业务结果 (业务量增长、用户数增加,等等)。

其中把握度量目标定义的原则是:

  · 指标的定义是清晰的、明确的,使大家对度量什么有一致的理解,方便后续改进措施的跟进。

  · 指标的定义通过自动化工具或者REST API容易获得,这意味着度量系统较容易实现,从成本考虑,避免一开始就构建一个大而全的度量体系。

  · 指标的定义是有明确价值的,定义适合组织土壤和文化的有意义的指标,而不是生搬硬套其他公司的指标定义,因为只有这些指标才可以带来真正的改善并为组织带来价值。


如何实现有效度量?

根据度量体系的分层,找到发力点,基于分层构建度量系统。

度量系统的构建基于开发过程中的客观数据,整个过程与开发周期同频并构建一个反馈循环,有助于更加精准地调整团队行动。

在这个反馈循环中有以下几个步骤:

  (1) 收集 – 收集关于团队表现的所有数据

  (2) 度量 – 分析数据

          ·  查找数据点之间的变化趋势和关联

          ·  构想有关团队、工作流或者过程等问题

          ·  在分析的基础上,研究如何调整

  (3) 应用 – 根据分析进行调整

  (4) 重复 – 动态观察,以便持续地分析和调整团队

1. 基础能力层

软件工程中复杂的因素是人,敏捷宣言中第一条“个体和互动高于流程和工具”。个人和互动通过每一个需求的完成让想法得以落地,它通过源代码管理平台相互交流和碰撞得以体现,每个Pull Request,每次Code Review都是个人能力和团队互动的呈现。

利用源代码管理(SCM)系统,可以获取以下信息:

  · 谁在修改代码?

  · 代码发生了多大变化?

再结合度量系统的目标,可以使用SCM数据回答:

  · 谁在做什么?

  · 谁在帮助谁?

  · 工作中投入了多少精力?


2. 产品交付层

利用任务管理系统如JIRA,可以很好地分析数据。

  · 执行任务的负责人

  · 制定任务的负责人

  · 任务开始时间

  · 任务完成时间

  · 最初估算的任务量

敏捷团队好的工作方式应该全员参与。如果想要创建一个快乐而又高效的团队,对所开发的产品拥有一些所有权,就应该要求团队尽其所能地标记任务,这可以作为一个好的指标,衡量团队的绩效。


3. 业务价值层

通过应用程序监控,从软件运行和客户满意度情况等方面,衡量是否达成业务目标,如应用程序性能监控(APM)数据和业务智能(BI)数据,有助于衡量团队的工作绩效。

  · APM数据从技术角度反映应用程序的表现

  · BI数据表示应用程序为客户提供的服务

总结

降本增效是这个内卷时代浪潮的声音,构建度量系统顺势而为,以客观数据为抓手,找到最有意义的改进点,利用反馈循环不断调整并提高团队绩效,达到提高研发效能的终极目标。

小诗一首:

研发效能提升易,

客观数据为抓手,

反馈循环为逻辑,

持续改进为手段,

降本增效为目标,

内卷时代终破局。

——作者:Lilian Chen

作者简介:一直在学习,从未有放弃,渴望有精进的CSP。