减少工作时间是敏捷的,因为工作软件是进度的主要衡量标准

燃尽图可以使用任何单位单位,例如小时或点数,但最初是Scrum’的燃尽图跟踪了迭代中剩余的工作时间。许多人仍将基于小时的燃尽图用作迭代过程中进度的主要指标。这是一个有用的工具,但类似于在(美式)橄榄球比赛中跟踪码数。它衡量活动,但不衡量成就。毕竟,30码的达阵百分比是多少?
工作软件是进度的主要衡量标准
敏捷宣言中的一项原则是“工作软件是进度的主要衡量标准“。但是,减少工作时间可以衡量和增强计划的进度,而无需任何软件,直到迭代结束。那’与在Waterfall版本发布之前不必拥有可用的软件几乎一样!这是许多人不再消耗时间或使用其他工具(例如消耗故事点)来补充时间的原因之一。
抢救点

按点数消耗图表是敏捷中最好的工具之一。它将敏捷的许多最佳方面融合在一起,并且让您立即了解自己的实际工作方式。基于积分的燃尽图的工作方式很简单。

对于您即将开始的迭代,请针对该迭代所针对的所有故事中的故事点总数。假设它由两个5点故事,两个3点故事,一个2点故事和两个1点故事组成。总共有20个故事点。制作一个带有X轴的图表,该图表代表从左至右从第一天到最后一天的迭代中的所有天。假设是10天。 Y轴表示已完成的故事点数,在这种情况下,将为0到20个故事点。

在每天结束时,您会汇总与满足“完成”定义的所有故事相关的故事点,并将总计记录在图表上。例如,如果您在第一天完成了1分的故事,在第二天没有完成,而第二天完成了2分的故事,则图表的第一天将具有1点的条形,而第一天则具有1点的条形第二天,第三天则是3分。

基于积分的燃尽图可让您每天以图形方式查看您在实现目标方面所取得的进展。它仅记录成就,而不记录活动,并允许您查看自己是否步入正轨或落后。对我来说,这正是“工作软件是进度的主要衡量标准。

韩元’t图表在迭代结束之前是空的吗?
刚开始时,您可能会认为图表会在大多数迭代中落后于您,并且仅在QA能够开始测试并标记故事完成时才进行追赶,但只要图表显示出稳定的前进之外,到迭代结束,这里是您应该问的一些问题:

  • 我们的用户故事太大了吗?这是否会阻止质量检查人员更早参与?
  • 人们一次写太多故事吗?
  • 我们是否无法生成稳定的版本以进行质量检查?
  • 开发人员是否会产生很多问题,然后继续讲下一个故事,而不是帮助质量检查解决问题?
  • 开发人员是否应该放弃他们正在做的事情并提供手写自动测试的机会?
使用基于积分的燃尽图,从团队到经理再到整个组织,每个人都可以立即了解项目和团队的健康状况。这简化了经理的工作,因为如果表明有任何问题,任何人都可以站起来并说“嘿,团队,我们正在搞砸,我们将如何处理团队?”
燃尽图强化了以下想法:
  • 使用故事点进行估算,可以实现整个团队的思考,例如该整个团队的指标。
  • 使故事尽可能小以使故事尽可能快地完成,从而将重点放在成就而不是活动上
  • 尽可能在同一地点和跨职能的团队工作,以使故事发生最快的周转时间
  • 使团队能够团队合作并自行管理更多事务
与燃烧时间不同, 逐点燃烧是全自动的!
您可能还没有准备好放弃燃烧时间,但是在那里’s no reason you can’不要同时使用。以及大多数敏捷项目管理工具,例如 团结版本一,将自动为您生成基于积分的燃尽图。
那里’还有一个原因,您可能要考虑从消耗大量的时间转移到消耗大量的点,假设您的用户故事总体上足够小,并且您大部分都是在迭代过程中一直完成故事。根据我的经验,团队成员不会’真的很喜欢每天都要输入剩余时间来完成任务,而常常忘记这样做,这使他们将精力集中在活动而不是成就上。同样,唯一需要手动操作的步骤是标记完成的故事,这有助于使整个过程更加流畅。

鸣叫