如果客户要求我使用Scrum给出整个项目的完成时间估计，我能做到吗？
例如，使用（可怕的）瀑布方法，我会有一个技术规范来给出一个相当不错的估计。
6个回答
5
对于给定的预算，您知道可以完成多少次迭代。然后，产品负责人应该优先处理工作以获得产品待办事项的最大价值。这就是敏捷开发的工作方式，固定时间和团队规模，可变范围（敏捷开发是关于范围管理的）。一旦团队速度已知，您就可以预测可以完成多少工作（点数）（# of sprints x velocity = 可实现的工作量大小）。
通常，客户不理解并希望在特定时间内获得“他们认为需要的一切”（即固定范围）。在这种情况下，您最终需要进行某种前期分析，将所有内容分解为足够小的项目以估算它们。完成此工作后，您可以通过猜测速度（# of sprints = 总大小 / 速度）来预测需要多少个sprint。对于具有瀑布背景的人来说，这是一种非常常见的情况，并且往往会导致不准确的结束日期（固定范围和团队规模，时间可变），因为您无法真正猜测速度，而项目的开始是做估计的最糟糕的时刻。
在两种情况下，您都需要速度。问题是速度实际上是1）在团队开始工作之前未知的，2）随时间变化而变化。
要解决1），您可以像第二种情况中讨论的那样估计速度，但这并不是非常“敏捷”。理想情况下，您应该让团队开始工作来测量实际速度（在早期迭代期间可能会不准确）。一个中间情况是先给出一个非常粗略的估计，然后在进行了几次迭代并收集了更多关于项目的知识并减少了不确定性后再回到客户那里提供更精确的估计。
为了解决2），我跟踪随时间测量的速度，并使用最近3个sprint的最高速度、最低速度和平均速度作为工作假设。这使我能够进行乐观、悲观和现实的预测（分别）。
通常，客户不理解并希望在特定时间内获得“他们认为需要的一切”（即固定范围）。在这种情况下，您最终需要进行某种前期分析，将所有内容分解为足够小的项目以估算它们。完成此工作后，您可以通过猜测速度（# of sprints = 总大小 / 速度）来预测需要多少个sprint。对于具有瀑布背景的人来说，这是一种非常常见的情况，并且往往会导致不准确的结束日期（固定范围和团队规模，时间可变），因为您无法真正猜测速度，而项目的开始是做估计的最糟糕的时刻。
在两种情况下，您都需要速度。问题是速度实际上是1）在团队开始工作之前未知的，2）随时间变化而变化。
要解决1），您可以像第二种情况中讨论的那样估计速度，但这并不是非常“敏捷”。理想情况下，您应该让团队开始工作来测量实际速度（在早期迭代期间可能会不准确）。一个中间情况是先给出一个非常粗略的估计，然后在进行了几次迭代并收集了更多关于项目的知识并减少了不确定性后再回到客户那里提供更精确的估计。
为了解决2），我跟踪随时间测量的速度，并使用最近3个sprint的最高速度、最低速度和平均速度作为工作假设。这使我能够进行乐观、悲观和现实的预测（分别）。
- Pascal Thivent
1
是的，你可以（并且确实）估算Scrum项目。[注意，“Scrum”是一个英语单词，不是缩写或首字母缩略词。它不应该全部大写。]
以下是估算Scrum项目的方法。
写下待办事项清单。
将待办事项清单分解成Sprint。
按价值从高到低对Sprint进行排序。
向客户提供这个已经排序的Sprint列表。
他们可以随时停止工作，因为每个Sprint都是有用的，而第一个Sprint是系统中最有用和最重要的部分。
这就是估算结果。这是他们自己管理的。
- S.Lott
17
@ammoQ：“整个项目”通常是无法定义的。如果您可以定义它，瀑布模型实际上会起作用。由于您无法定义它，因此采用敏捷方法。买家将在冲刺待办事项清单中挣扎，不知道在哪里划线。实际上，他们挣扎得如此之多，以至于最终要求您为他们定义“整个”（这是荒谬的，但他们经常无法决定需要多少）。 - S.Lott
1我不会费心将积压的任务分配到冲刺中，我只会对它们进行优先级排序。实际上，我想知道你是如何完成第二步骤的（没有估算和速度）。 - Pascal Thivent
1@Pascal Thivent：提前分解一个sprint本质上就是估算。这并不需要深入的技术规范。此外，交付速度始终无法提前知道，因此初始估算总是错误的。对此无可奈何。 - S.Lott
绝对不是。我只是在说，提前将所有项目放入冲刺中是浪费和无用的。你应该及时处理。在Scrum中，这发生在Sprint计划会议的前半部分。顺便说一下，团队应该挑选项目，而不是其他人。 - Pascal Thivent
@Pascal Thivent：同意。然而，在当前的问题中，有人正在寻求概述，并且他们正在“现在”询问，而不是“及时”。在这个问题的限制下，人们必须想象一个可能的未来，其中包括一些潜在的冲刺和潜在的交付速度。我不确定是否有任何替代方案，而不涉及预知或魔法。 - S.Lott
显示剩余12条评论
1
在Scrum中，你确实会确定成本和时间。然后你让功能变化。这样，你可以告诉客户，在XX/XX/XXXX完成，成本为$YYY.YY。然后由他们来确定优先级，以确保在这些限制下完成最重要的功能。
- DancesWithBamboo
0
是和不是。我认为Scrum是一个很好的方法，可以让业主参与到Sprint计划中。
因此，在估算的情况下，很难说“我们将在30天内完成项目”。相反，业主会对第一和第二周完成的工作有期望，并且在30天内有一个“完成情况的感知”。
在我看来，这比给出30天的估计然后幸运地或者完全偏离标记更有价值。
此外，您将更好地估计即将完成的工作。Scrum的另一个好处是，您可以根据需要调整部署，以便在30天后获得更可用的产品，而不是使用瀑布流可能完全无法使用的东西。
- Mark Kadlec
0
这取决于你想要预测什么。
你可以保证n周的冲刺需要正好n周的时间，而m个冲刺需要n*m周的时间。因此，进度估算很容易。成本/工作量估算也很容易，只要确定了团队规模和项目持续时间。但是你无法可靠地承诺最终提供哪些功能以及不提供哪些功能。
对于一个项目，有四个主要的控制变量：范围、成本/工作量、进度、质量。你可以选择哪些变量是项目的驱动因素（即固定的），哪些不是。你不能将它们全部作为驱动因素，至少需要保留一个变量来允许平衡项目。
在传统的瀑布模型中，你有固定的范围（规格）和通常固定的进度（目标日期）。你可以通过增加成本/工作量（例如增加人员、加班工作）或在质量方面采取捷径来平衡项目。这些平衡因素并不呈线性关系，如果你推得太远，就会在其他领域遇到问题。
使用敏捷开发包括Scrum，您有固定的时间表（迭代或冲刺）和固定的质量水平（完成定义）。成本/工作量与团队中的人数成正比。范围是主要的平衡因素。它具有相当线性的良好特性：范围的增加或减少不会导致其他驱动程序出现非常非线性的变化。成功的关键在于功能优先级排序，以从您可以交付的范围中获得最大价值。
- laalto
1
99%的情况下，我们编写规范等文件并交给客户阅读和签署，然后他们会问一个问题：我的应用程序何时完成？（2009年12月31日）。如果不知道涉及到的全部内容，很难预测完成日期。除非我们在第一次冲刺之前先编写整个冲刺待办事项清单。这反过来又会更多或更少地结束功能/技术规范。 - Antony Delaney
0
正如Steve McConnell在软件估算中所说，每当您需要提供一个估计时：
- 计数
- 如果您无法计数，则进行计算
- 如果您无法计算，则进行判断
“专家判断”或估算是最后的资源。尝试计算实际事物和/或参考历史数据以计算有意义的数字。
无论您使用的方法是Scrum还是其他任何方法，都适用此原则。
- CesarGon
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接