写点什么

论敏捷与延迟:项目延迟六大原因,该如何避免?

  • 2019-12-19
  • 本文字数:3611 字

    阅读完需:约 12 分钟

论敏捷与延迟:项目延迟六大原因,该如何避免?

本文要点

  • 敏捷团队通常会参与交付业务的重大里程碑,这种里程碑是业务在特定时间点所期望的,相关的预算也是商定好的。所以团队需要做好预测,否则就可能会被指责"敏捷却迟到"。

  • 根据逻辑,项目延迟有六大可能的原因——也就是“逻辑六成因”。其中的三条因素是在技​​术团队控制下的:低估工作量;缺乏可用的人才;并且缺乏团队生产力。另外三条是发起人控制的:需求不明确;范围变更;并且缺乏所需的持续投入。

  • 有一些指标针对的就是这六条潜在的延迟原因——测量这些指标以提高预测的准确性是至关重要的。

  • 这些指标需要从多个数据源中总结出来,因此需要端到端的交付指标/分析平台,否则这些指标就很难评价。

  • 然后可以使用这些指标创建红色/琥珀色/绿色(RAG)根本原因进度报告——与发起人共享更准确的预测和明确的改善措施,并分配责任来实施已确定的改善措施。


我们合作的敏捷团队有着多种多样的规模和形态,而可预测性几乎是所有主题的重中之重——因为“敏捷”和“可预测”这两个词并不总是相辅相成的……


那么开发团队如何才能保持敏捷并提高交付的可预测性呢?做到这一点,当利益相关方问到关于可预测性的问题“我们是不是在如期推进?”,他们才可以给出一个有意义的回答。

典型的敏捷团队预测方法

基于产品的敏捷软件开发团队会频繁交付小幅度的增量改进,可能很少花时间来操心预测的话题。


但是,敏捷团队往往需要交付一些重大里程碑,这些里程碑是业务在特定时间点所期望的,相关的预算也是商定好的;因此团队需要有效地预测,否则就可能被指责为“敏捷却迟到!”。


根据我们的经验,敏捷团队的预测往往很不准确,并且通常仅基于团队本身对积压、速度和口头保证的简单观察结果。


我们认为,真正有意义的预测需要更广泛的经验数据集,以反映会导致项目延迟的所有潜在因素。


像这样的“项目”环境中是否适合使用敏捷软件开发方法,还有另一场争论,但这就是另一个话题了

“逻辑六成因”——项目延迟的六大原因

逻辑表明项目迟到可能有六条成因——也就是所谓的“逻辑六成因”。六成因中的三条是由技术团队直接控制的:


  1. 任务的大小和复杂性被低估了

  2. 计划中符合需求的工程师小组并不可用

  3. 交付团队的交付效率不及预期。


其他三条由与技术团队互动的业务发起人控制。这些是:


  1. 需求定义不清晰——内部客户对他们实际想要的东西不够清楚

  2. 范围变更——业务目标内容变化(变更/新需求或优先级改变)

  3. 持续的投入——在需要的地方/时间缺乏利益相关者的投入而延迟了开发过程。


我们认为,你需要收集跟踪所有这六条杠杆的指标,否则你将永远无法真正准确地预测,并提升交付的可预测性。


只有做到这一点,你才能真正了解一个项目是否可能“迟到”,以及需要做什么才能使其回到正轨上。



"逻辑六成因"——项目延迟的六大根本因素

通过分析重要的交付指标来挑战团队的预测结果

那么,与项目延迟的六大成因相关的测量指标都有哪些,它们对于交付的可预测性和预测准确性的提升是至关重要的吗?


下表显示了我们在每个领域中最喜欢的一些指标。我们鼓励交付主管在与交付团队负责人合作,重点关注这些指标,以做出更现实的预测。


概括来说,这些指标有:


  1. 人员可用性——显然很关键。如果我们没有所期望的工程师,我们将迟到。

  2. 团队生产力涉及:

  3. 生产时间——另一大关键指标,考虑了工程师必须专注于编写新功能的时间比例

  4. 流程效率——开发流程中的摩擦会破坏最佳的交付计划。因此,真正了解这种摩擦的趋势及其成因是关键

  5. 实现价值的速度和时间——了解我们的吞吐量和实现价值的时间如何随着项目的进行而变化,是我们预测中的另一个决定性变量

  6. 估计精度——如果我们采用基于 Scrum 的方法,则冲刺的完成水平是衡量我们预测能力的很好指标。如果我们无法达到每两周的冲刺目标,那么我们就不太可能有效地估算工作量并进一步预测未来

  7. 可以使用从协作中心(如 Slack)收集的量化工程师反馈来跟踪需求定义、利益相关者的输入和范围变更。我们在内部经常使用这种方法来改进我们的预测,因为它利用了实际工作人员的定量观察能力。它通常会为原本只在理论上的交付预测增添信心,并使人看清楚“逻辑六成因”中的三条(需求定义、利益相关者的投入和真实范围变更)。

跟踪导致项目延迟的逻辑六杠杆的关键指标

趋势指标相关性
可用的工程资源: - 活跃工程师人数(与计划相比)显然是关键——显示我们是否有计划的资源来交付工作。
生产时间 - 在新功能上花费的时间(%) - 花费在维护上的时间(%) - 与非产品相关的活动损失的时间(%)关键指标,用来了解随着时间推移的趋势变化。如果我们在非生产性任务上花费更多的精力,显然这将影响我们的前进步伐。
流程效率 - 流量效率(%) - 返工(工作日) - WIP/开发人员这些指标分析了开发过程中的"摩擦"及其随着时间推移的趋势。流量效率下降往往是一个可以解决的问题,因此它是改善预测的关键指标。返工显示了处理未通过质量检查的故障单所花费的累积时间趋势。这是另一种形式的摩擦,可以改善(例如通过协助刚接触代码库的工程师)。 注意:我们认为,各个级别收集到的任何指标都需要直接参与项目的人员根据具体情况来查看。如果传播范围更广,这些指标的评价可能会脱离上下文(具有破坏作用)。
实现价值的速度和时间 - 完成的功能门票 - 循环时间(工作日) - 交货时间(工作日)速度指标存在自己的问题,但是在做出预测时,关键在于要对已完成门票的趋势(以及每张门票的故事点/价值点)有着深度理解。对周期和交货时间变化的理解也很重要。如果它们在延长,那么做出准确的预测就很困难。
冲刺精度 - 总体完成率(%) - 冲刺总体完成率vs冲刺目标完成率(%)如果无法实现每两周的冲刺目标,就很难做出较长时间的预测。因此,这些指标对于预测准确性而言至关重要。
量化工程师反馈 - 团队士气 - 冲刺效率 - 门票质量和要求定义 - 业务发起人的投入质量 - 与商定的范围变更相关工作一些指标平台可以通过协作中心对工程师进行实时调研。这提供了以下定量数据: - 工程师对士气和流程效率的看法;和 - 业务发起人的需求定义和持续投入的影响 - 团队负责人对业务的利益相关方在原始范围之外添加的故事的反馈。

收集重要的交付指标

关键交付指标需要从众多来源收集数据,包括:工作流程管理工具、代码仓库和 CI/CD 工具——以及从工程团队本身(通过协作中心)收集的定量反馈。


数据的复杂性和来源的多样性使人工收集此类数据的工作非常耗时,需要端到端的交付指标平台来大规模收集。


可行的交付指标平台由以下内容组成:一个数据层,用于整理和编译来自多个数据源的指标;一个灵活的 UI 层,用于创建自定义仪表板,以所需格式显示指标。

使用根本原因 RAG 报告来改进你的交付预测和改善计划

如果我们使用一些指标来跟踪和分析影响项目进度的六大逻辑驱动因素,就能获得更清晰的项目实际进度图。也就是说:


  • 更现实的交付预测

  • 如果预测结果落后于时间表,我们可以致力于明确的改善计划。


改进的预测和相关的改善措施可以在红色、琥珀色和绿色(RAG)根本原因进度报告中一起显示。


根本原因 RAG 报告要比传统的 RAG 进度报告有效得多,传统的 RAG 进度报告通常很少说明(具有所需上线日期)的项目落后于计划的实际原因,以及需要做什么才能回到正轨。


与传统的 RAG 方法相比,根本原因 RAG 报告(请参见以下示例)清楚地显示了:


  1. 我们最新的交付预测

  2. 支持我们预测的交付指标

  3. 我们的改善措施(基于驱动项目进度的逻辑六杠杆)——例如,需要减少用于维护的时间来增加生产时间;需要解决开发流程中的障碍(例如质量检查等待时间)来提高流程效率; 或需要改进利益相关者的投入(如量化工程师的反馈所示)

  4. 为了交付已确定的改善措施,在开发团队和利益相关者之间分配责任的情况


能做得好的话,根本原因 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


2019-12-19 09:007822

评论

发布
暂无评论
发现更多内容

第一周-胡赵凯-作业

hisun胡

产品经理训练营

给自己当前岗位所定义的理想岗位模型

邹小胖

自我思考

前端也要懂机器学习(下)

执鸢者

机器学习 大前端

有道乐读 x AWS | 云上的少儿图书馆!这个寒假让孩子爱上“乐读”

亚马逊云科技 (Amazon Web Services)

云计算 AWS

十三、数据应用二

Geek_28b526

架构师训练营第2期 第13周命题作业

月下独酌

架构师训练营第2期

AWS Graviton2 | 匠“芯”定制,性能为王

亚马逊云科技 (Amazon Web Services)

云计算 AWS

ClickHouse在大数据领域企业级应用实践和探索总结

王知无

大数据 Clickhouse

架构师课程--第十三周作业

孤星

币币撮合交易系统软件开发|币币撮合交易APP开发

系统开发

构师训练营 - 第十三周课后练习

joshuamai

最长公共前缀字符串, RxSwift的概念详细解析, 极客大学认识产品经理 John 易筋 ARTS 打卡 Week 35

John(易筋)

ARTS 打卡计划 最长公共前缀字符串 RxSwift的概念详细解析 极客大学认识产品经理 极客大学产品经理训练营

架构师训练营 week13 学习笔记

花果山

Springboot 中的切面AOP处理

武哥聊编程

Java aop springboot SpringBoot 2 28天写作

十三周总结

水浴清风

软件架构-缓存技术

看山

缓存 架构

第一周-胡赵凯-总结

hisun胡

产品经理训练营

HTML(一)——html相关介绍

程序员的时光

程序员 28天写作

架构师训练营第2期 第13周总结

月下独酌

架构师训练营第2期

如何 debug hive 源码,知其然知其所以然

王凯

hive 源码分析

数字货币交易APP系统开发|数字货币交易软件开发

系统开发

架构师训练营 week13 课后作业

花果山

敏捷开发需要内外兼修

Bruce Talk

敏捷开发 Agile

面试官:Netty的线程模型可不只是主从多Reactor这么简单

中间件兴趣圈

reactor Netty nio 中间件 线程模型

【计算机内功修炼】七:高并发高性能服务器是如何实现的

码农的荒岛求生

高并发 事件驱动 高性能 Event Driven 高并发优化

HDFS中的常用压缩算法及区别

王知无

大数据 hdfs

Hbase性能优化百科全书

王知无

大数据 HBase

数字货币合约交易系统软件开发|数字货币合约交易APP开发

系统开发

在 AWS 的视角下,正确打开零信任安全模型

亚马逊云科技 (Amazon Web Services)

云计算 AWS

Flink1.12集成Hive打造自己的批流一体数仓

王知无

大数据 flink

项目管理系列 (5)-沟通规划

Ian哥

项目管理 沟通与管理 28天写作

论敏捷与延迟:项目延迟六大原因,该如何避免?_研发效能_Charlie Ponsonby_InfoQ精选文章