本文要点
我们合作的敏捷团队有着多种多样的规模和形态,而可预测性几乎是所有主题的重中之重——因为“敏捷”和“可预测”这两个词并不总是相辅相成的……
那么开发团队如何才能保持敏捷并提高交付的可预测性呢?做到这一点,当利益相关方问到关于可预测性的问题“我们是不是在如期推进?”,他们才可以给出一个有意义的回答。
基于产品的敏捷软件开发团队会频繁交付小幅度的增量改进,可能很少花时间来操心预测的话题。
但是,敏捷团队往往需要交付一些重大里程碑,这些里程碑是业务在特定时间点所期望的,相关的预算也是商定好的;因此团队需要有效地预测,否则就可能被指责为“敏捷却迟到!”。
根据我们的经验,敏捷团队的预测往往很不准确,并且通常仅基于团队本身对积压、速度和口头保证的简单观察结果。
我们认为,真正有意义的预测需要更广泛的经验数据集,以反映会导致项目延迟的所有潜在因素。
像这样的“项目”环境中是否适合使用敏捷软件开发方法,还有另一场争论,但这就是另一个话题了
逻辑表明项目迟到可能有六条成因——也就是所谓的“逻辑六成因”。六成因中的三条是由技术团队直接控制的:
其他三条由与技术团队互动的业务发起人控制。这些是:
我们认为,你需要收集跟踪所有这六条杠杆的指标,否则你将永远无法真正准确地预测,并提升交付的可预测性。
只有做到这一点,你才能真正了解一个项目是否可能“迟到”,以及需要做什么才能使其回到正轨上。
"逻辑六成因"——项目延迟的六大根本因素
那么,与项目延迟的六大成因相关的测量指标都有哪些,它们对于交付的可预测性和预测准确性的提升是至关重要的吗?
下表显示了我们在每个领域中最喜欢的一些指标。我们鼓励交付主管在与交付团队负责人合作,重点关注这些指标,以做出更现实的预测。
概括来说,这些指标有:
趋势指标 | 相关性 |
---|---|
可用的工程资源: - 活跃工程师人数(与计划相比) | 显然是关键——显示我们是否有计划的资源来交付工作。 |
生产时间 - 在新功能上花费的时间(%) - 花费在维护上的时间(%) - 与非产品相关的活动损失的时间(%) | 关键指标,用来了解随着时间推移的趋势变化。如果我们在非生产性任务上花费更多的精力,显然这将影响我们的前进步伐。 |
流程效率 - 流量效率(%) - 返工(工作日) - WIP/开发人员 | 这些指标分析了开发过程中的"摩擦"及其随着时间推移的趋势。流量效率下降往往是一个可以解决的问题,因此它是改善预测的关键指标。返工显示了处理未通过质量检查的故障单所花费的累积时间趋势。这是另一种形式的摩擦,可以改善(例如通过协助刚接触代码库的工程师)。 注意:我们认为,各个级别收集到的任何指标都需要直接参与项目的人员根据具体情况来查看。如果传播范围更广,这些指标的评价可能会脱离上下文(具有破坏作用)。 |
实现价值的速度和时间 - 完成的功能门票 - 循环时间(工作日) - 交货时间(工作日) | 速度指标存在自己的问题,但是在做出预测时,关键在于要对已完成门票的趋势(以及每张门票的故事点/价值点)有着深度理解。对周期和交货时间变化的理解也很重要。如果它们在延长,那么做出准确的预测就很困难。 |
冲刺精度 - 总体完成率(%) - 冲刺总体完成率vs冲刺目标完成率(%) | 如果无法实现每两周的冲刺目标,就很难做出较长时间的预测。因此,这些指标对于预测准确性而言至关重要。 |
量化工程师反馈 - 团队士气 - 冲刺效率 - 门票质量和要求定义 - 业务发起人的投入质量 - 与商定的范围变更相关工作 | 一些指标平台可以通过协作中心对工程师进行实时调研。这提供了以下定量数据: - 工程师对士气和流程效率的看法;和 - 业务发起人的需求定义和持续投入的影响 - 团队负责人对业务的利益相关方在原始范围之外添加的故事的反馈。 |
关键交付指标需要从众多来源收集数据,包括:工作流程管理工具、代码仓库和CI/CD工具——以及从工程团队本身(通过协作中心)收集的定量反馈。
数据的复杂性和来源的多样性使人工收集此类数据的工作非常耗时,需要端到端的交付指标平台来大规模收集。
可行的交付指标平台由以下内容组成:一个数据层,用于整理和编译来自多个数据源的指标;一个灵活的UI层,用于创建自定义仪表板,以所需格式显示指标。
如果我们使用一些指标来跟踪和分析影响项目进度的六大逻辑驱动因素,就能获得更清晰的项目实际进度图。也就是说:
改进的预测和相关的改善措施可以在红色、琥珀色和绿色(RAG)根本原因进度报告中一起显示。
根本原因RAG报告要比传统的RAG进度报告有效得多,传统的RAG进度报告通常很少说明(具有所需上线日期)的项目落后于计划的实际原因,以及需要做什么才能回到正轨。
与传统的RAG方法相比,根本原因RAG报告(请参见以下示例)清楚地显示了:
能做得好的话,根本原因RAG报告可以是一种非常有效的方式,以利益相关者可以理解的方式呈现我们的(更准确的)预测,因此可以成为减少延迟并使技术团队与内部客户联系更加紧密的重要步骤 。
但正如所讨论的那样,它依赖于对导致项目延迟的实际指标的理解,以及收集这些指标的方法。
根本原因RAG报告示例
作者介绍
Charlie Ponsonby在发展中国家开始了他的经济学家生涯,随后加入了安德森咨询公司。他直到2007年一直担任Sky的市场总监,然后在2007年离开公司,创立了Simplifydigital。Simplifydigital在《星期日泰晤士报》科技追踪百强榜中三度登榜,并成长为英国最大的宽带比较服务。它于2016年4月被Dixons Carphone plc收购。2017年10月,Ponsonby和Dan Lee共同创立了Plandek。Plandek是端到端交付指标分析和BI平台。它从交付团队使用的工具集中挖掘数据(例如Jira、Git和CI/CD工具),以提供端到端交付指标来优化软件交付预测、风险管理和交付有效性。Plandek的客户遍及全球,其中包括Reed Elsevier、News Corporation、Autotrader.ca和Secret Escapes。
原文链接:
Agile and Late! End-to-End Delivery Metrics to Improve Your Predictability
领取专属 10元无门槛券
私享最新 技术干货