减轻敏捷实战中故事点发生漂移的风险 - modernanalyst

20-04-19 banq

在许多敏捷项目中,需求通常不是以正式需求文档的形式编写的。取而代之的是,通常使用一组简洁而有效的方法来描述必须构建的内容,即用户故事。用户故事从客户的角度描述了系统的行为,性能或界面。一个典型的用户故事可能看起来像这样:

作为潜在的客户,我希望能够根据输入的搜索条件查看书籍。

用户故事不仅是有效的需求管理工件,而且对于估计项目的范围/规模以及跟踪团队的进度也至关重要。在确定项目规模时,团队会估算完成每个用户故事所需的工作水平,然后汇总其结果以得出对项目范围的估算(有关如何估算敏捷工作水平的更多详细信息)项目,请参阅Mike Cohn 关于该主题出色著作)。

 

敏捷团队通常会使用一种称为故事点的无单位量度。使用故事点的优点是它们的内在价值是相对的。故事点不会尝试得出通常与时间相关的绝对值(例如,完成特征X需要多少天),而是只关注故事相对于其他故事已经或需要完成的相对工作量或复杂性。将项目的故事点总数与团队的速度(每个迭代周期完成的故事点数)相结合,项目涉众就可以越来越准确地了解项目的规模以及所需的时间。完成当前的团队。

什么是故事点 

最初,当团队形成时,他们将估计一些基准故事的故事点。例如,团队可能将以下三个故事作为其基准:

  • 作为用户,我想按主题浏览书籍集:8分

  • 作为用户,我希望能够保存我的付款信息:2分

  • 作为用户,我希望能够向人们推荐我最喜欢的书:5分

 

从这个基准来看,其他用户故事是根据感知到的相对完成工作量进行估算的。对于大型项目,大多数用户故事被估计为史诗,大型用户故事将在以后分解以实际解决开发问题。

 

随着时间的流逝,新的用户案例将被添加到产品待办事项列表中,其他用户案例将被删除,其中一些将被更改以反映不断变化的需求。所有添加或更改到待办事项中的故事都将需要故事点估计。 

 

故事点漂移

使用故事点时存在的潜在风险之一就是我所说的“故事点漂移”。故事点漂移是指在项目开始时具有给定故事点值的用户故事比项目后期具有相同故事点值的故事需要更多或更少的工作,而完成故事所需的工作量是给定的。

 

例如,假设我在项目稍后估计了以下用户故事:

  • 作为用户,我希望能够将我的银行帐户链接到我的登录名并设置每月提款计划:8分

  • 作为用户,我希望有一个主题编辑器可以自定义我的在线会员商店的外观:5分

尽管上述用户故事可以准确地表示彼此之间的相对大小,但与在项目开始时估计的故事相比,似乎后者的故事点不足以表示其复杂性和所需的工作水平。我怀疑启用自动银行交易的工作量远远大于构建按主题浏览功能所需的工作量。

 

我发现在较大或较长期的敏捷项目中,故事点漂移的风险增加。故事点漂移的发生可能有以下几个原因:

  • 团队的集体记忆是短期的:团队开始估计新故事时,通常会借鉴最近完成的故事中的经验。如果其中一些故事被错误分类(要么比故事点估计中所代表的需要付出或多或少的相对努力),然后团队最终就可以相信这些最近的故事是故事点和使用价值的新规范。这些都是将来的参考,它们使原始基准参考的故事点值出现了偏差。

  • 团队的互补性已经改变:项目团队随时间变化的情况并不少见。我注意到,即使团队规模越来越大,团队的速度似乎也保持恒定。在调查此问题时,我发现通常是因为团队开始以较少的分数来估算故事,因为由于现在有更多的人要从事该项目,他们现在认为故事“更容易”。结果,以前可能被认为是8分的故事现在估计为5分。结果,尽管事实是团队可能会因估计偏差而做得更多,但团队的速度似乎没有变化。

  • 没有提及基线:敏捷项目通常通过最小化不会导致客户价值的间接费用以及适应非理想情况而蓬勃发展。例如,敏捷团队很少等待每个人参加会议-会议是有时间限制的,无论错过了谁,会议都会准时开始和结束。但是,有时敏捷团队可能会忘记将诸如参考故事之类的物理对象带到会议中。有时,团队会根据回忆而不是实际参考来尝试通过会议。如果没有实际的参考故事和点值,则得出的估计值可能会有些偏斜。

 如何减轻故事点飘移

当我看到故事点漂移时,它随着时间的推移以很小的增量发生了–您直到几个月后才意识到估算值有很大的偏差。故事点漂移会导致资源计划,进度和完成时间估算方面的问题。以下是一些我用来帮助减轻故事点漂移的策略:

  • 将原始故事和最近故事的混合作为新估计的基准:进行相对比较时,保留原始估计不会有什么坏处。举一些最近的例子也很有帮助,特别是因为您的初始估计可能仅适用于一些潜在的故事点值。在讨论分配给新故事的估算级别时,或者在计划扑克的过程中陷入僵局时,每个可能的故事点值具有1或2个故事也可能会有所帮助。

  • 了解实施后何时应该重新估计某些故事:每隔一段时间,您会遇到一个故事,它比您最初想的要花费更多(或更少)的精力。如果付出的努力水平与另一个获得相同分数的故事完全不同,则您可能希望重新评估该故事,以免影响团队对一定数量故事价值的理解。通常,只有在一个项目进行了多个Sprint计划后,我才会重新估算一个故事–早期,您可能会发现许多故事所花费的精力比您想象的要少或多,并且您很想调整这些故事的大小。但是,只要故事的相对数量是相同的努力,那么就无需重新估算。因此,如果您认为3点故事需要一天的时间才能完成,而一周中大部分时间都用完,请查看5点和8点故事的表现。如果这些花费的时间也比预期的长,请不要重新估计。

  • 每隔几个Sprint花费一点时间并分析相关故事: ScrumMaster或项目经理可以随时查看一些已完成的故事,以寻找可能的故事点漂移。如果发现漂移,请与团队合作,看看他们的想法。如果团队同意,则从相对的努力上重新估计似乎超出预期的故事。

用户故事和故事点可能是管理项目需求和估算的一种很好的方法。密切关注故事点的漂移将确保团队能够很好地处理项目的进度和估计的完成时间。通过努力,这种项目估算方法对于敏捷团队而言可能是非常准确和有效的工具。

 

         

猜你喜欢