跳到主要内容

需求交付时长

概念

定义

需求交付时长是需求从创建到交付的总时长。可按照需求在实践域或项目管理系统中流转的状态划分,统计各个状态阶段的时间占比,帮助定位拖长需求交付时长的阶段。如果需求的颗粒度不统一,可以统计需求的功能点、故事点、代码当量等进行校准。其中功能点是常用于估算软件规模的单位,有国家标准作为依据,适用于小颗粒需求或小规模专业性强的团队,或航天、军工、政务等行业。为了校准需求的实际颗粒度,可以采用每个需求交付后对应的代码当量作为一个统计指标,来观察各个需求颗粒度的分布。如果它们的代码当量符合正态分布,则需求交付时长的结果可作为观察交付速率的有效参考,否则应重点排查代码当量过大或过小的需求,首先统一需求颗粒度,再采用需求交付时长指标。

例如,下图展示了几个月份中,需求交付时长的均值和低80%分位值。

image

价值

需求交付时长反映研发团队的快速响应能力。理论上,向客户交付价值的速度越快越好,但必须综合考虑交付价值是否满足顾客期望、需求吞吐率和交付质量等其他方面。快速交付不一定等同于优秀的研发实践。

应用

角色认知

角色认知域
项目经理、开发者交付效率

MARI 方法

度量(Measure)

计算方法

对于某个需求,需求交付时长 = 需求发布时间 - 需求创建时间。可以按照需求在各个状态中停留的时长,将需求交付时长细分为多个组成部分。可以只统计指定范围内的需求,计算它们的交付周期。

  • 统计项目维度需求交付时长。
  • 统计周期内平均或 80% 的需求的交付周期。

  • 统计需求在不同实践域(需求分析、设计、开发、测试、发布)或不同状态的停留时长。

分析(Analyze)

  • 对比不同项目的需求交付速度,找到交付最快和最慢的项目。

  • 分析各个周期内平均需求交付时长的变化趋势,进行纵向对比,定位最大值、最小值、连续上升周期、连续下降周期等关键点。

  • 分析各个周期内80%的需求的交付周期的变化趋势,进行纵向对比,定位最大值、最小值、连续上升周期、连续下降周期等关键点。

    信息

    为什么选用80%分位数而不是使用平均数? 统计的意义在于以真实有效的数据进行预测,支持更优决策,而均值和中分位数无法具备支持预测的作用。 通常情况下,均值和80%分位数的统计结果会出现两倍的差距,80%分位数和99%分位数也往往是约两倍关系。 因此,80%分位数是一个很好的预测平衡点。

  • 分析对比需求在不同实践域或不同状态的停留时长,识别耗时最长的环节,找到影响整体交付速度的关键瓶颈。

  • 需求交付时长与需求吞吐量关联分析,辨别需求交付趋势是否健康。

    • 健康趋势:需求交付时长缩短并且需求吞吐量增加。
    • 不健康趋势:需求交付时长延长并且需求吞吐量降低。

回顾(Review)

基于分析结果,聚焦少数关键点,采用石川图(鱼骨图)或根因分析法(RCA),进行根本原因的分析、调研和回顾。例如:连续几个统计周期,需求交付时长变长,需要进一步调研需求在不同阶段的停留时长,找到耗时最长的阶段进行根因分析:

  • 需求阶段耗时过长:需求不明确、变更频繁、需求颗粒度过大、需求优先级没有定义清楚、需求分析师或产品经理的资源或经验不足?
  • 设计阶段耗时过长:需求文档不清晰、研发负责人或架构师的资源或经验不足?
  • 开发阶段耗时过长:设计文档不清晰、任务分配不均匀、流负载(并行任务)过高、技术债过多、bug过多、开发人员资源或经验不足?
  • 测试阶段耗时过长:需求文档不清晰、代码质量差、自动化测试少、测试人员资源或经验不足?
  • 发布阶段耗时过长:构建或部署时间过长、运维人员资源或经验不足?

改进(Improve)

基于回顾结果,聚焦关键根因,从规范、流程、工具、行为等方面给出针对性改进措施,明确提升目标、改进措施、验证周期及责任人。

以下为可参考的改进思路:

  • 与客户或业务方沟通明确需求、合理拆解需求和定义优先级、邀请业务方、研发负责人、测试负责人进行需求评审。
  • 邀请产品经理、研发人员、测试负责人进行设计评审。
  • 减小需求或任务颗粒度、均匀分配任务、降低流负载、增加单元测试、及时解决技术债和代码问题以减少bug和返工的数量。
  • 测试左移、开发自测、代码评审、增加自动化测试、提升持续集成能力。
  • 自动化部署、缩短构建时间、提升持续交付能力。
  • 对各个岗位人员进行合理的资源分配和必要的培训。

改进成果也应当是可量化的,便于持续度量,追踪改进效果。