敏捷开发进度管理之燃尽图

很多时候,我们感觉什么都没干一天就过去了,但对领导者来说,事情最好已经提前做完了,而且是越快越好。聪明的管理者知道,“时间”是需要花大功夫去把控的限制因素,只有掌握了更多关于时间和工作的数据,我们才能更好地执行计划,在预算范围内按时完成项目。

燃尽图就是用来反映此类项目数据的工具,常用于敏捷软件开发中,如Scrum。它可以呈现剩余工作量和可用剩余时间,并通过可视化的图示表述繁复文字无法表述的意思。

一、燃尽图是什么?

燃尽图可以呈现团队处理用户故事进度,是一种对工作完成情况可视化展示的工具,燃尽图可显示每次迭代工作总量中仍需完成的工作余量。

燃尽图的横轴显示工作天数,纵轴显示剩余工作,反映了项目启动以来的进度情况,它让每个团队成员都能够看到当前的进度,团队需定期更新燃尽图以保持其准确性。

目前存在两种形式的燃尽图,Sprint燃尽图用于显示迭代中的剩余工作量,而产品燃尽图则用于说明整个项目的剩余工作量。

二、如何解读燃尽图

燃尽图有下面几个要点,它有一个X轴,代表项目或迭代的时间;有一个Y轴,代表需要在项目中完成的工作,用户故事剩余的工作量也由该轴表示。

项目起点位于图表左侧最高点,发生在项目或迭代的第0天。项目完结点位于最右侧,标志着项目或迭代的最后一天。

计划曲线

燃尽图中的计划曲线是一条连接起点和终点的直线。因为代表了需要完成的所有预估任务的总和,计划曲线的终点应穿过X轴,表示已经不存在任何剩余的工作。但鉴于它以估算值为基础,因此并不总是准确的。

实际曲线

燃尽图中还存在一条实际曲线,显示项目或迭代中实际剩余的工作量。在起点,计划剩余工作量和实际剩余工作量是相同的,但随着项目或迭代的进行,实际剩余工作曲线将在计划工作线的上下方波动。实际的剩余工作线每天都会添加一个新的点,直至项目或迭代完成,以确保尽可能准确。

如果实际工作线高于计划曲线,则意味着剩下的工作量比预期多,换句话说,意味着项目进度落后于计划。但如果实际曲线低于计划曲线,则意味着剩余工作量少于预计,项目进度快于既定计划。

三、燃尽图有什么好处?

燃尽图最显著的好处是,能提供关于项目进度和更新状态的最新报告,并对这些重要数据进行直观展示,可以确保每个人都统一进度。

此外,将燃尽图展示到所有人面前,能够让团队所有成员都积极参与项目,并激励成员提前处理可能出现的问题。因此图表越大越显眼就越好。燃尽图应该成为办公室的视觉焦点,进而引发对项目和进度的相关讨论。

简洁明了的燃尽图十分有用,因为它是查看项目历史速度(Velocity)的最佳工具。速度(Velocity)是一个敏捷术语,表示迭代期间完成的用户故事相关的预估工作量总和。

四、燃尽图有何局限?

燃尽表无法呈现所有信息

例如,它仅显示已经完成的用户故事工作量,无法预知任何变化,例如在工作范围内估算待办列表(backlog)的所有points。因此,我们很难判断燃尽图中的变化是由于已经完成的backlog,还是由于故事点的增加或减少引起的。在燃尽图中增加一个专门显示backlog总量的图表可以解决这个问题。

但是,燃尽图(向下或向上线条显示)都无法显示哪些产品backlog已经完成。燃尽图能显示项目的进度,但无法显示团队是否在做正确的事,也无法判断团队是否在交付正确产品backlog。

燃尽图需依赖精准的预估

燃尽图的另外一个问题是理想剩余工作线。实际工作线是高于还是低于理想工作线需要取决于对任务原始时间估计的准确性。因此,如果团队过高估计时间要求,则项目实际进度可能会看似正常或略超前。但如果低估了时间要求,则看起来会落后于计划。

将效率因素纳入燃尽图可以解决这个问题。因此,在项目的第一次迭代之后,重新计算效率因素能够获得更高的准确性。

五、燃尽图的历史回顾

燃烧图表是从Scrum社区开发出来的,并且在2000年左右首次用于管理软件项目和其他相关工作。Ken Schwaber首次对燃尽图进行了描述,因此也被认为是燃尽图的发明者。当时正在Fidelity Investments工作的Ken Schwaber创建了燃尽图,来为Scrum团队提供一个可以帮助他们绘制项目进度图的简单工具。

到2002年,燃尽图在Scrum社区中越来越受欢迎。从那以后,燃尽图开始运用于scrum之外的其他领域,成为了管理者控制项目进度的有用工具。

Worktile提供专业的敏捷项目管理模板工具,包括需求管理、迭代规划、缺陷追踪、报表统计、团队协作等功能,能实时查看和监控项目进度,提高团队成员工作效率。10人以下团队可免费使用,免费注册Worktile

文章来源:Worktile敏捷博客

欢迎访问交流更多关于技术及协作的问题。

文章转载请注明出处。

原文地址:https://www.cnblogs.com/worktile/p/10916425.html

时间: 2024-09-30 14:28:59

敏捷开发进度管理之燃尽图的相关文章

软件开发进度管理探析

随着计算机信息技术的飞速发展,软件项目在开发过程中的进度管理越来越受到重视.如果进度管理做得好,软件开发项目将通过延长工作时间和提高质量来满足预算要求来减少.相反,工作时间会延长,这会降低质量或超出预算.可以说,进度管理是软件开发项目工程的核心和重要组成部分.它贯穿于软件项目开发的全过程.项目开发的成功直接取决于进度管理的质量.从软件开发的实际情况来看,影响软件开发进度管理的因素很多.第三,结合进度管理的概念和进度管理在软件开发过程中的重要性,从多个角度分析了影响进度管理的因素.最后,提出了改进

[转]敏捷开发需求管理(产品backlog)

传统的瀑布工作模式使用详细的需求说明书来表达需求,需求人员负责做需求调研,根据调研情况编制详细的需求说明书,进行需求评审,评审之后签字确认交给研发团队设计开发.在这样的环境下,需求文档是信息传递的主体,也是一份契约. 然而详细的需求说明书有以下5大弊端: 单向的信息传递,容易出现理解偏差. 文档很正式,我们会误以为它一定是对的,不去质疑它,让我们停止作出判断. 有了详细的文档,我们不会反复讨论它,相互确认. 书面文档不利于团队共享责任,它扮演了证据的角色.Scrum强调团队共享责任,不论是需求人

敏捷开发 scrum管理

项目准备阶段 1.产品经理将整体项目拆分成不同的单独模块,每个模块尽量细化到能够自成一体.例如app的登录注册模块,不能仅仅就是登录注册这两个界面,而是要将所有与这有关的需求整合到一块.要达到的效果就是用户直接能用这个功能. 2.开发团队根据需求列表,做工作量的预估和安排. 开发准备阶段(每一次迭代都是都是一种冲刺) 1.项目技术主管搭建项目框架(框架高水准要求),并将这次迭代从全局方面来进行细化. 2.项目成员根据主管的安排,细化每个人的工作量以及完成时间,具体方式如下: 下图所展示的是计划纸

软件开发进度管理

一.什么是软件项目管理 软件项目管理是按需求确定范围.按目标制定项目计划.按计划执行管理的过 程.对软件开发各阶段加强项目管理的根本目的在于增强对软件开发的控 制能力,提升软件开发的质量.软件项目的建设按软件工程的生命周期法可分为项目立项.启动.需求分析.系统设计.系统开发.系统测试.系统上线.项目验收 和上线后评估等9个阶段进行. 加强软件项目管理,就是以软件工程的各个环节为管理主线,将动态项目管理贯穿其中,通过对软件开发的项目范围.项目进度.项目质量.项目沟通.人力资源.项目成本六大核心要素

敏捷开发方法(一) Scrum

Scrum团队:由产品负责人.开发团队和Scrum Master组成. 是跨职能的自组织团队 自组织团队自己选择如何最好地完成工作,而不是由团队外的人指导 跨职能团队拥有完成工作所需要的全部技能,不需要依赖团队以外的人 这种团队模式的目的是最大限度地优化灵活度.创造力和生产效率 三大角色: Scrum管理-五事件 Scrum 管理: 所有事件是有时间盒限定的 每个事件都有时间限制的 一旦Sprint开始,它的周期也就固定下来了,不能缩短或者延长 Scrum 管理五事件包括: Sprint 计划会

敏捷开发流程,您缺一个这样的协作平台

近年来,在高科技行业,为了响应快速的技术迭代和产品升级,敏捷开发流程正成为越来越多企业的选择.企业希望通过敏捷开发模式,基于自身的线性发展,来获取非线性的创新与竞争优势. 敏捷开发宣言是这样重新定义研发过程: ? 个体和交互胜过过程和工具 ? 可以工作的软件胜过面面俱到的文档 ? 客户合作胜过合同谈判 ? 响应变化胜过遵循计划 敏捷开发模式的践行,并非易事.首先是团队观念的转变和组织变革,然后这些还并不足够,在敏捷流程中特别强调沟通的高效,快速而有序.要做到这样,您还需要一个协作平台. 敏捷开发

杨学明老师推出全新课程--《敏捷开发&IPD和敏捷开发结合的实践》

课时:13小时(2天) 敏捷开发&IPD和敏捷开发结合的实践 讲  师:杨学明 [课程背景] 集成产品开发(IPD).集成能力成熟度模型(CMMI).敏捷开发(Agile Development)是当前国内外企业产品研发管理的最常用的3种模式.随着创新环境的快速发展,许多企业都会面临这样的问题:如何快速响应市场的变化?如何推出更有竞争力的产品?如何在竞争中脱颖而出?……是大部分研发型企业普遍面临的核心问题.另外,软件项目在产品开发中位置越来越重要,逐渐占领主导地位,这时传统的IPD流程和CMMI

[敏捷开发实践](1) 认识敏捷开发

[敏捷开发实践](1) 认识敏捷开发 1,提要 软件开发是一个系统工程,包括最初的可行性分析.再到设计.开发.测试.维护等整个生命周期.在这个过程中某些阶段的失误或说是变化,都可能增加整个软件项目的风险. 如何在保证效率的基础上还能安计划.保证质量的完成软件项目?于是产生了软件开发的一些方法,这个方法不是指具体有编码阶段的各种设计模式和技巧,而是在整个软件开发策略层面的方法. 传统瀑布模式和新型的敏捷开发就是其中最常用的方法,后面着重讨论敏捷开发的优缺点和敏捷开发的基础知识. 2,常用的开发模式

《大产品,小团队——携程敏捷技术与管理转型实战》读后感

作为曾经携程的一员,看到一起奋斗过的小伙伴们宣传此书立刻就买了,非常开心拿到了作者团队的亲笔签名版.读完颇为感慨与惭愧,有种虽然身在此山中,竟不识庐山真面目的感受.当时身处携程俩大核心业务之一,却只知一味地吐槽糟糕的流程和无止尽的加班,即没有推动改进的勇气与执行力,也不知背地里整个公司为优化流程,提倡创新所作出的努力,以及已经取得的成果. 诚如书名<大产品,小团队——携程敏捷技术与管理转型实战>,此书着重于在敏捷开发与管理转型期碰到的问题与解决方案,所以建议小伙伴们在学过了ACP,或者敏捷项目