使用积分估算任务

Question

我最近开始在使用积分完成任务估算的环境中工作。我没有找到任何资源来强调这个过程的好处所以我必须转向SO社区来弄清楚它们是什么。如果你们中的任何一个人在使用积分估算任务的Scrum环境中工作，那么使用小时数的主要好处是什么？

Answer 1

tl; dr 命名的区别在于语义，它可以帮助您以不同/正确的方式思考估算。

当我在一个Scrum团队工作时，Scrum Master向我解释说，积分（双关语意）是它们应该是问题的比例指标。如果根据时间进行估算，那么（非技术人员，特别是PHB）人们会开始将您的估算视为截止日期。如果管理页面估计为32小时，那么那些人在本周末之前就会“只是”该页面...尽管这取决于其他可能需要100小时的幕后工作并且可能是单独任务甚至故事的一部分。此外，你可能是错的（也可能是），因此重要的是要考虑这些是规模指标而不是需要多长时间。

Answer 2

Scrum没有具体说明您如何估算短跑计划的剩余工作量。听起来你正在使用任务来创建你的计划。我参与过的一些团队成功地将任务数量作为剩余工作的总和。有些用了几个小时有些团队只使用剩余数量的Product Backlog Item故事点作为剩余内容的衡量标准。

我没有与使用积分估算任务和故事（PBI）的团队合作，但如果他们已经了解经济上的差异，我认为它可以为他们工作。

Answer 3

敏捷的一个原则是反馈：衡量和适应。使用积分超过一小时的好处是，回答问题“这个任务是否是这个任务的两倍”，而不是“团队完成任务需要多长时间”，尤其是在开始时，这个问题要容易得多。项目。随着项目的进展，您可以观察每单位时间内出货的点数，并且您可以轻松确定是否可以在特定时间范围内完成任务。从本质上讲，这在估计小时数时是相同的，但估算是基于观察到的团队过去，包括所有使估算变得困难的无形因素（人们合作得很好，非编码活动占用时间） - 而你避免“时间讨价还价”。

Answer 4

Scrum中的估算是理解和有效执行的关键方面。对于工程师（特别是）来说，来自更传统的估算方法是非常普遍的，这些估算方法基于数​​小时。而且我们都知道这些在历史上是多么容易出错。

背后的前提是，它们是对一个故事与另一个故事相比的相对权重（基本上是努力）的估计。因此，如果我说一个特定的故事被加权为“2”，而另一个故事被加权为“5”，我真的说故事＃2的大小大约是故事＃1的两倍。事实证明，人类非常适应于相互比较物品 - “这比那个更大”，“这比那个要大得多”，等等。我们不太擅长分配绝对物 - “这正是3立方米“。因此，为什么将任意＃的小时数分配给工作项通常会在实践中产生非常差的结果。

点数发挥作用的是冲刺的速度。这只是衡量一组人在一段时间内通常完成的点数，通常为2-4周。经过短暂的冲刺并假设团队成员在一起，无论团队正在做什么类型的故事，速度趋于稳定。但是，团队成员自己创建点估计值而不是Scrum Master，经理或其他非团队成员是 critical 。否则整个过程就会崩溃，冲刺可能会失败。

点数也反映了故事的复杂性。你将点数提升得更高，比如20,40等等，这个故事对于那个团队来说真的更危险，更复杂。因此，虽然你可以说20码的故事大约是5磅故事大小的4倍，但20 pt的故事实际上可能确实是25或30分;故事的复杂性和范围导致估计可能不太可靠。因此，通常情况下，团队将与产品负责人合作，在可能的情况下以2-5磅的大小调整故事大小;不是太大，也不是太小。

最后，随着团队对Scrum的熟练程度越来越高，有可能开始对将要完成一套故事（通常称为史诗）的未来进行预测。这可以设置产品或功能的目标日期。如果团队以点数估算一组故事，并且该团队的速度已经稳定，那么您可以预测出在完成工作时可能需要的冲刺数量，假设没有对积压进行进一步更改。我和我的团队在从新产品到维护版本的几个项目中这样做，它可以非常准确，比我们在Scrum之前的几个小时里依赖的时候更准确。

从小时转移到积分的好处可以归纳为：

• 以分数估算速度更快。
• 以分数估算更准确。
• 以点数估算更容易。