敏捷研发项目,我们该如何度量?

简介: 作为项目负责人,我们如何及时获悉当前项目的最新进展和问题,了解项目的整体状况?作为项目管理人员,我们如何跟进和推进项目的正常进行?如何借助云效效能洞察平台 Insight,帮助项目管理者及时发现问题和偏差,推进项目进展、保障项目的迭代和高质量交付。

作为项目负责人,我们如何及时获悉当前项目的最新进展和问题,了解项目的整体状况?

作为项目管理人员,我们如何跟进和推进项目的正常进行?

带着这两个问题,我们进入到敏捷项目度量的场景,聊一聊如何借助云效效能洞察平台 Insight,帮助项目管理者及时发现问题和偏差,推进项目进展、保障项目的迭代和高质量交付。

注:以下内容分为视频版和文字版,读者可自选学习。

观看地址:https://v.qq.com/x/page/i3324eoceoo.html

云效效能洞察 Insight 中,我们可以从 3 个维度跟进项目的运作状况:

  • 看项目整体状况:了解项目(或交付团队)的整体运作情况;
  • 看项目交付趋势:了解项目迭代交付的速率、质量和进展;
  • 看资源投入状况:了解团队成员工作分布,保障项目中的重点事项的投入与交付。

看项目整体状况

在云效Insight的敏捷项目度量的报表中,通过「项目进展」和「需求/缺陷现状概览」指标卡,我们可以:

  • 快速洞察项目的整体运作状况,如进展、偏差、风险、问题、需求/缺陷进展等;
  • 快速获知所选时间段内需求、缺陷的吞吐量和逾期状况。

image.png
图片来源:云效效能洞察Insight

我们可以根据这些数据,及时跟进解决风险和问题,如果发现异常,可快速采取行动。例如,当我们看到项目中有缺陷过多、存量风险和已超期事项,需要快速推动项目的负责人去催办,快速将缺陷、风险和已超期事项解决,以免成为项目最终交付的卡点。

看项目交付趋势

在云效Insight的敏捷项目度量的报表中,通过「需求趋势」和「缺陷趋势」指标卡,我们可以:

  • 了解项目的需求、缺陷的新增与完成情况,掌握团队的交付模式,提前识别问题和风险;
  • 了解项目的需求、缺陷的存量的发展趋势。

image.png
图片来源:云效效能洞察Insight

在观测需求、缺陷的趋势时,我们需要重点关注:

1. 看存量趋势

通过项目的需求、缺陷的存量趋势,当存量曲线走高时,可以快速推进重点需求和关键缺陷的及时完成;当存量需求曲线走低时,需要查看需求规划情况,是否会出现需求断档的情况发生。当存量缺陷缺陷逐步或突然走低时,需要查看需求提测的质量,是否真的是质量比较好,还是测试不充分导致的;

2. 看团队的交付模式

如果长时间没发现缺陷,而到某一段时间集中新增大量缺陷,能够反映出是瀑布交付模式,需要及时进行干预,避免集中和批量集成,缩短问题暴露的时间,建立快速反馈机制。

其次,我们可以观测「需求交付速率」和「缺陷修复速率」指标卡,通过这两张指标卡,我们可以:

  • 看到在每一个单位时间内的需求交付、缺陷修复的数量,及所选时间段内平均单位时间需求和缺陷交付量;
  • 看到需求交付速率趋势,根据近期交付量来合理安排团队将来的交付节奏和对外的承诺。

image.png
图片来源:云效效能洞察Insight

其中:

需求交付效率:横坐标为时间,以周为单位,纵坐标是需求的数量(个),柱子高低代表一周交付需求数量的多少,柱子的颜色分布分别对应交付周期的长短分布;

注:按需求个数统计的方式,因需求大小不一致会出现一些统计偏差,因此期望做需求交付统计时能够将需求粒度拆分的相对较小且均匀。

缺陷修复效率:横坐标为时间,以周为单位,纵坐标是缺陷的数量(个),柱子高低代表一周修复缺陷数量的多少,柱子的颜色分布分别对应修复周期的长短分布。

在观察需求交付速率和缺陷修复速率时,我们需要重点关注:

1.需求交付速率的趋势

查看本周内已交付的需求数量,并与历史速率的做对比,可发现差距,并及时推进计划交付但还未交付的需求;

2.需求和缺陷结合了解交付关系

需求的交付速率和缺陷的修复速率结合起来一起看,可以帮助我们判断缺陷修复速率与需求交付速率的关系。一般情况下,缺陷数量多且修复速度越低,需求的交付速率也会比较低。反之,缺陷数量少且修复速度快,需求的交付速率就会比较快。

最后,我们需要观察「需求燃起图」和「缺陷燃起图」指标卡,通过燃起图我们可以:

  • 看到项目(团队)一段时间内的工作成果,了解交付的速率和剩余需求/缺陷量;
  • 通过两条曲线的差距和未来交叉点,可预测项目(需求、缺陷)的完成时间,方便对外做承诺。

image.png
图片来源:云效效能洞察Insight

其中:

需求燃起图:横坐标为时间,纵坐标是需求的数量(个),“完成曲线”该项目(团队)已完成的需求数量变化,“全部曲线”该项目(团队)总共需要完成的需求数量变化;

缺陷燃起图:横坐标为时间,纵坐标是缺陷的数量(个),“完成曲线”该项目(团队)已修复的缺陷数量变化,“全部曲线”该项目(团队)总共需要修复的缺陷数量变化;

曲线交叉点:按照所选时间段内的交付速率,项目中存量需求或缺陷预计完成的时间。

在观察需求和缺陷燃起图时,我们需要重点关注:

  • 完成曲线的斜率:完成曲线的斜率代表团队的需求交付速率和缺陷修复速率,当曲线的斜率陡升或陡降的时,需要及时关注和跟进,了解是否出现了集中交付需求或修复缺陷的情况;
  • 两曲线间的距离:两曲线的距离代表待完成需求和缺陷的数量,也是该项目剩余的工作量,当距离基本变化不大时说明需求完成或缺陷修复与其新增量保持平衡,在持续交付的模式下,距离应该尽可能的短且两条线平缓增长。
  • 两曲线的交叉点:两曲线的交叉点代表该项目(团队)如果按照当前的交付速率,项目中所有需求或缺陷预计完成的时间,当我们知道这个时间时,我们可以更方便对外做承诺。

看资源投入状况

在云效Insight的敏捷项目度量的报表中,通过「成员工作量排名」和「存量缺陷按成员排名」指标卡,我们可以:

  • 看需求、缺陷和任务按人员的分布情况;
  • 看项目组成员所负责的缺陷情况,以及不同类型的缺陷的分布情况;

image.png
图片来源:云效效能洞察Insight

在观察项目人员分布时,我们需要重点关注:

  • 工作量排名前三位:成员工作量排名在前面的几位,我们需要了解成员是否工作负荷过高、并行需求是否过多等,如果有此类情况,需要及时调整成员的工作安排;
  • 工作量排名后三位:成员工作量排名在后面的几位,我们需要了解成员是否工作量安排过少,或不负责当前项目中的工作,如果有此类情况,需要调整成员的工作安排;
  • 缺陷的排名前三位:缺陷数量排名的前几位人员,需要推动其及时修复缺陷,同时需要对缺陷的引入原因进行分析,避免类似的问题再次引入。

整体回顾

我们可以从整体状况、交付趋势和人力投入 3 个方面来观测项目的状况,重点观测 5 幅图:

  • 项目进展:反应项目的整体进展,可查看项目的进展和风险等;
  • 需求交付速率:反应项目历史的需求交付吞吐量,可对未来的交付产能进行预测;
  • 缺陷趋势图:反应团队历史的过程质量情况,可分析团队的交付模式和质量状况;
  • 需求燃起图:反应项目交付速率,可对项目计划完成时间点进行预测;
  • 成员工作量排名:反映项目工作量的分布情况。

同时我们还可以有更多的数据分析,比如:需求趋势、缺陷修复速率、缺陷燃起图、缺陷按成员排名、迭代进展概览等,这篇文章中我们没做分享,但是也可以在云效Insight中看到。

最后,在跟进敏捷项目时,我们还可以跟进迭代进展的详细度量数据。关于迭代的度量内容,我们将在下篇文章中进行分享,敬请期待。


如果你想要体验云效Insight 的敏捷项目度量场景报表,点击下方链接,前往云效Insight 即可「免费试用」

https://www.aliyun.com/product/yunxiao/insight?channel=yy_yc

lQLPDhshq7rXr9DNBDjNB4Cw6h-soueBRw4CB9bnfwCoAA_1920_1080.png

相关文章
|
6月前
|
运维 监控 Devops
持续提升敏捷度,你需要实施Sitecore DevOps
作为打破产品和开发团队之间的隔阂障碍的工具,DevOps透过自动化“软件交付”和“架构变更”的流程,推进构建、测试、发布软件能够更加地快捷、频繁和可靠。
110 8
|
6月前
|
运维 监控 Cloud Native
设计与构建 FinOps 流程、团队、体系与目标
企业 FinOps 实施不是一蹴而就的项目,如果您正在推进企业云原生 FinOps 落地,除了选择合适的技术手段,企业内部的流程和体系建设也尤为重要。
163601 22
|
6月前
|
监控
构建高效能团队的敏捷方法论
【5月更文挑战第10天】敏捷方法论助力构建高效能团队,强调个体协作、迭代开发、客户参与和灵活应变。通过选择合适的敏捷框架,建立协作文化,制定明确流程,持续改进,团队能迅速响应市场变化,保证产品竞争力和创新力,促进企业成功和持续发展。
|
6月前
|
敏捷开发 Devops jenkins
DevOps、瀑布模型与敏捷开发:关系解析与对软件交付工程师的影响
DevOps、瀑布模型与敏捷开发:关系解析与对软件交付工程师的影响
149 1
|
数据可视化 关系型数据库 MySQL
度量平台落地实践
度量平台落地实践
266 0
度量平台落地实践
|
新零售 运维 监控
研发效能的度量| 学习笔记
快速学习研发效能的度量
研发效能的度量| 学习笔记
关于研发规范化的一些实践和思考
除了老板之外,我想大多数人是讨厌规则的,因为它束缚了我们的自由。然而,无论是个人,还是组织,规则却是发展中必不可少的环节,虽然我们很难看出规则的直接价值。 研发类任务,更是一类严谨的工作,它不仅需要严谨的逻辑思维能力,更需要一个完善的研发规范流程。对于程序员的我们,其实我们心里是比较讨厌规则的,在我们心里,只要把需求完成,上线就ok了,其他都是浮云,其实,这样的心里,我以前也是有过。
《研发效能提升36计-敏捷协作篇:设定北极星指标,数据驱动效能改进》电子版地址
研发效能提升36计-敏捷协作篇:设定北极星指标,数据驱动效能改进
165 0
《研发效能提升36计-敏捷协作篇:设定北极星指标,数据驱动效能改进》电子版地址
|
Devops
DevOps研发模式下「产品质量度量」方案实践
DevOps研发模式下「产品质量度量」方案实践
639 0
DevOps研发模式下「产品质量度量」方案实践
下一篇
无影云桌面