agile - 使用点估计任务

Question

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

Answer 1

tl; dr命名的区别是语义上的，它是为了帮助您以不同的方式/正确地考虑估计。

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

Answer 2

Scrum 中的估计是理解和有效执行的关键方面。工程师（尤其是）来自更传统的以小时为单位的估算实践是很常见的。我们都知道这些在历史上是多么容易出错。

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

分数发挥作用的地方在于冲刺的速度。这只是衡量一组人在给定的时间段内通常完成多少分，通常是 2-4 周。经过少量冲刺并假设团队成员在一起，无论团队正在处理什么类型的故事，速度都会趋于稳定。然而，团队成员自己而不是 Scrum Master、经理或其他非团队成员创建点估计是至关重要的。否则整个过程会崩溃，sprint 很可能会失败。

点数也反映了故事的复杂性。你在分数范围上移动得越远，比如 20、40 等，这个故事对那个团队来说风险和复杂性就越大。因此，尽管您可以说大小为 20 的故事大约是 5 磅故事大小的 4 倍，但事实上，一个 20 磅的故事可能实际上是 25 或 30 磅。故事的复杂性和范围导致估计可能不太可靠。因此，团队通常会与产品负责人合作，尽可能将故事大小调整为 2-5 磅；不要太大，不要太小。

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

从小时转移到积分的好处可以总结如下：

• 以点为单位估计更快。
• 以点为单位估计更准确。
• 以点为单位估计更容易。

Answer 3

Scrum 没有具体说明您如何估计 sprints 计划的剩余工作。听起来您正在使用任务来创建计划。我参与的一些团队成功地将任务数量用作剩余工作的总和。一些使用时间。一些团队只是使用剩余的产品待办事项项目故事点数作为剩余内容的衡量标准。

我没有与使用分数来估计任务和故事 (PBI) 的团队合作，但如果他们开始了解经济体的差异，我想它可以为他们工作。

Answer 4

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