如果客户问我整个项目的预计完成时间可以使用Scrum吗？
使用例如（可怕的）瀑布式方法，我将使用技术规范来进行一半估算。
答案 0 :(得分：5)
对于给定的预算，您知道可以完成多少次迭代。然后，产品负责人应优先考虑工作，以获得产品积压的最大价值。这就是敏捷如何工作，固定时间和团队规模与可变范围（敏捷是关于范围管理）。一旦团队速度已知，您就可以预测可以完成多少工作（以点为单位）（冲刺的数量x速度=可以实现的工作的大小）。
通常，客户不会得到它并希望“在给定时间他们认为他们需要的一切”（即固定范围）。在这种情况下，您最终会进行某种前期分析，将所有物品制成足够小的物品来估算它们。完成这项工作后，您可以通过猜测速度（短跑的数量=总大小/速度）来预测您需要多少冲刺。这对于具有瀑布背景的人来说是一种非常常见的情况，并且通常会导致不准确的结束日期（固定范围和团队规模随时间变化），因为您无法真正猜测速度和项目的开始是最糟糕的时刻。估计。
在这两种情况下，你都需要速度。问题是在团队开始工作之前，速度实际上是1）未知，2）将随时间变化。
要解决1），你可以估计猜测速度，如第二种情况所述，但这不是很“敏捷”。理想情况下，您应该让团队开始测量实际速度（在早期迭代期间可能不准确）。一个中间场景是给出第一个非常粗略的估计，并且在您收集了更多关于项目的知识并减少不确定性之后，在更精确的一次迭代之后回到客户。
要解决2），我跟踪测量的速度随时间的变化并使用最高和最低速度以及最后3个平均速度冲刺作为工作假设。这使我能够分别做出乐观，悲观和现实的预测。
答案 1 :(得分：1)
是的，您可以（并且确实）估算Scrum项目。 [注意“Scrum”是英文单词，不是首字母缩略词或abbereviation。它不应该是全都的。]
您以这种方式估算Scrum项目。
记下积压。
将积压分成短跑。
优先考虑从最有价值到最有价值的冲刺。
向客户提供此优先级冲刺列表。
他们可以随时停止工作，因为每个sprint都很有用，第一个sprint是系统中最有用和最重要的部分。
这是估计值。这是他们的管理。
答案 2 :(得分：1)
当然，在scrum中你可以修复成本和时间。然后你让功能变化。因此，您可以告诉客户它将在XX / XX / XXXX上完成，费用为YYY.YY。然后由他们决定他们想要的功能的优先级，以确保在这些限制下完成最重要的功能。
答案 3 :(得分：0)
是和否。我相信Scrum是让主人参与冲刺计划的好方法。
因此，在估算的情况下，很难说“我们将在30天内完成项目”。相反，所有者会期望在第一周和第二周内完成哪些工作，以及在30天内了解将要完成的工作。
在我看来，这比估计30天然后幸运或远离标记更有价值。
此外，您将更好地估计在不久的将来会做些什么。关于Scrum的另一个好处是你可以定制你的部署，以便在30天之后改变或删除项目以获得更有用的产品，而不是使用瀑布完全无法使用的东西。
答案 4 :(得分：0)
这取决于你想要预测的内容。
你可以保证n周冲刺需要n周，而短跑需要n * m周。因此，进度估算很容易。考虑到一定的团队规模和项目持续时间，成本/工作量估算也很容易。您无法可靠地承诺的是最终会提供哪些功能，哪些功能无法实现。
项目有四个主要控制变量：范围，成本/工作量，进度，质量。您可以选择哪些变量是项目的驱动程序（即固定的），哪些不是。您不能同时将它们全部作为驱动程序，至少需要保留一个变量以便平衡项目。
对于传统瀑布，您有固定的范围（规格），通常是固定的时间表（目标日期）。您可以通过增加成本/工作量来平衡项目（例如，增加更多人员，加班加点）或采用质量快捷方式。这些平衡因素的行为并不是线性的，如果你将它们推得太远，你会在其他方面遇到问题。
对于包含Scrum的敏捷，你有固定的时间表（迭代或冲刺）和固定的质量水平（完成的定义）。成本/精力与团队中的人数成正比。范围是主要的平衡因素。它具有非常线性的良好特性：范围的增加或减少不会导致其他驱动程序发生非常大的非线性变化。成功的关键是功能优先级，以便将最大值从您可以提供的范围中移除。
答案 5 :(得分：0)
史蒂夫麦康奈尔在Software Estimation中说，无论何时你需要提供估算：
“专家判断”或清算是最后一种资源。尝试计算真实的事物和/或引用历史数据来计算一个有意义的数字。
这适用于您使用的方法，无论是Scrum还是其他任何方法。