SCRUM估计精度

Question

我猜想，在很多情况下，估计结果在某个时候是错误的。因为一旦您深入了解待办事项的细节，您可能总是会发现一些您在计划过程中没有考虑过的内容。这种情况可以在任务级sprint估计期间或在实际sprint期间发生。

在任务级评估期间，您可能会发现一个故事/待办事项的任务太多，因此需要对初始估计进行调整。，你现在做什么？，你会回到产品负责人那里，告诉他他可能想重新排序它的待办项目，现在这需要更长的时间(甚至更少)？基本上，这可能意味着整个团队需要回到故事级别的评估和重组故事？

在sprint过程中，您可能会发现实现需要比最初想象的更多的努力。，你现在做什么？，你是否默默地继续冲刺，知道你不能按计划完成它？从现在开始，你将在所有评估中添加一个“安全缓冲区”？

一般来说，SCRUM地址估计作为一个整体是如何精确的？

如果我理解正确的话，SCRUM开发团队就会“向”产品负责人承诺，它将按计划交付。但是，只有当他们准确估计时才能做到这一点。因此，评估对于SCRUM的成功似乎是非常关键的，但也非常困难。

Answer 1

简单的事实是，估计精度在术语上是一个矛盾。就像独角兽一样，它根本不存在。根据定义，估计值是而不是准确。

考虑到这一点，Scrum和其他敏捷方法试图绕过这个限制，而不是击败风车。在Scrum中，是对产品待办事项(用户故事、需求等)复杂性的先验估计。是为了给产品所有者一个粗略的概念，让他知道在即将到来的冲刺中他可以完成多少故事。在将PBI分解为任务之后，根据相信完成任务所需的时间来估计每个任务。一旦满足了团队的能力，他们就能(稍微)更好地估计他们在冲刺结束前能交付什么。

这些估计都是，仍然不准确。

敏捷产品所有者处理这种不准确的方法是降低延迟交付产品的成本。PO对他的故事进行了定义和排序，使他能够尽早交付产品中最重要的部分，并尽早创建一个(仍然不完整)可用和有价值的产品。这样，不管没有按时完成什么(结束冲刺或发布日期)，仍然是可以交付的最好产品，而且通常可以在时间之前创建一个足够好的，而其他的最不重要的特性则是在不久之后以小批量交付的。

，是Scrum如何处理估计的准确性。

Answer 2

一般来说，SCRUM地址估计作为一个整体是如何精确的？

通过调整飞行状态。您将故事点指定为大小和复杂性的度量。你尽你的最大努力，在相似的基础上，在相似的规模和复杂性的任务之间分配点数。

在最初的几次冲刺中，你不可避免地弄错了。随着时间的推移，你调整未来的估计，根据揭示的“速度”的整体项目。

其概念是，您创建一个反馈循环来校准那个sprint的故事点的值，并且您接受不确定性。Mike的书“敏捷评估和规划”中有一个很好的讨论。

因为一旦您深入了解待办事项的细节，您可能总是会发现一些您在计划过程中没有考虑过的内容。

评估中遗漏的任务是开发项目中第二常见的估计误差源(第一种是.1.这也是“总体规划谬误”的根源之一。敏捷过程倾向于反对过早地分解任务。

然而，管理这种风险的通常方法是建立评估清单。McConnell的软件评估:神秘的黑色艺术是一个很好的资源-表4.2，4.3和4.4 (第44-45页)是你自己的清单的一个极好的起点。

1 van Genuchten，米希尔。“为什么软件开发这么晚?软件开发延迟原因的实证研究”。IEEE软件工程交易，1991年6月。

Answer 3

评估过程是SCRUM中最难的事情。有时候，和一个团队一起坐在会议室里要花1天的时间，讨论完成每一个特定故事所需要付出的努力。甚至不要希望在第一次短跑中得到一个准确的估计。你应该接受这一事实，继续前进。取决于故事中的细节以及团队合作的时间长短，这个过程从sprint到sprint都会变得更好，并且评估将更加准确。到目前为止，您可以只计算速度或以0.5作为您的团队的当前速度。在第一次冲刺结束后，您将得到一个更精确的速度，然后可以用来为下一个sprint构建一个范围。

我的团队在项目一开始就给出一个准确的估计有很大的问题。在一个我们可以依赖的项目中没有任何东西，没有架构，这个系统又大又复杂，所以每个人都害怕给出任何估计，因为没有人知道到底应该建什么。我们通过向我们的公司引入系统分析员(SA)来解决这个问题，他正在分析所有传入的请求，直到从业务的角度来看一切都清楚之后才会将它们传递给开发部门。SA的主要目的是了解新特性，了解如何实现它，并在高级别上提出解决方案，同时考虑到对已经实现的功能的依赖，并记住我们计划在即将到来的sprint中实现的功能。在完成初步分析之后，SA创建故事并将其添加到待办事项中。然后这些故事就交给设计师了。他们设计屏幕并将它们连接到故事中。在此之后，产品所有者将获得批准并设定业务价值。

以上所有这些步骤都大大减少了整个团队用于评估会议的时间。现在，当会议开始时，我们几乎拥有了我们所需要的一切。每个故事都有详细的解释，开发人员看到它如何影响现有的功能和设计，所以现在很容易只关注技术问题。因此，正如在过程中得出的结论一样，我们构建了SA，设计人员正在为下一个sprint开发功能，而开发人员和QA则专注于活动特性。这使我们能够在active sprint的末尾分析所有的故事，并为下一个故事进行设计。