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

在许多敏捷项目中，需求通常不是以正式需求文档的形式编写的。取而代之的是，通常使用一组简洁而有效的方法来描述必须构建的内容，即用户故事。用户故事从客户的角度描述了系统的行为，性能或界面。一个典型的用户故事可能看起来像这样：
作为潜在的客户，我希望能够根据输入的搜索条件查看书籍。

用户故事不仅是有效的需求管理工件，而且对于估计项目的范围/规模以及跟踪团队的进度也至关重要。在确定项目规模时，团队会估算完成每个用户故事所需的工作水平，然后汇总其结果以得出对项目范围的估算（有关如何估算敏捷工作水平的更多详细信息）项目，请参阅Mike Cohn 关于该主题的出色著作）。
 
敏捷团队通常会使用一种称为故事点的无单位量度。使用故事点的优点是它们的内在价值是相对的。故事点不会尝试得出通常与时间相关的绝对值（例如，完成特征X需要多少天），而是只关注故事相对于其他故事已经或需要完成的相对工作量或复杂性。将项目的故事点总数与团队的速度（每个迭代周期完成的故事点数）相结合，项目涉众就可以越来越准确地了解项目的规模以及所需的时间。完成当前的团队。

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

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

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

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

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

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

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

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

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

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

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

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