我目前正在学习 Scrum，并想向该主题的经验丰富的专业人士学习。
速度是否与需要 3 个月的项目相关（通常有 2-3 次中间交付给客户）？
我认为现在还不足以使统计数据相关。是否值得记录整个项目中每个开发人员的速度以获得足够的统计深度？
另一个问题是速度对于小型项目真的那么重要吗？
我们在我们的领域有很多经验，我们的估计是不准确的。我们遇到的唯一问题与有时会影响您的风险因素有关，但我们知道我们的风险并知道如何处理它，我不确定 scrum 是否有助于解决客户板上的硬件问题。
我确实在其他部分看到了很多逻辑，比如小迭代、连续集成，让产品/项目管理非常接近开发过程，我认为我们已经在不知情的情况下通过 scrum 做很多事情。
所以最重要的是，我看不出 Scrum 作为整个概念是否适合我的需求，但我确实看到我可以使用很多概念（我真的很喜欢 backlog）来使我们的开发过程更好。
实际上，这更像是讨论而不是问题，但 SO 不是为此而设计的，所以如果不合适，我很抱歉。
因此，将您的问题分为两部分：
1) Velocity 在 3 个月的项目中是否值得？是的，我认为是的。我曾在大多数项目持续 2-6 个月的团队中工作。我们有一周的迭代，但我知道只有 3 天的团队。然而，在敏捷社区中，有一种运动朝着更加 Kanaban 拉式系统的方向发展，在这种系统中，特定的迭代不是必需的。我会说从迭代开始，然后重新评估
2）所以当我们有好的估计时我需要速度？可能不会，因为您的项目较短。但是当某件事是 20 小时，而你需要 10 天，因为你每天只能工作 2 小时，那么你基本上需要使用不同的东西来计算速度。
如果你正在做一个为期一个月的冲刺的三个月项目，你将只能将你的速度计算用于两个冲刺。但是，如果您使用两周的冲刺，您将有五个冲刺，您可以在其中应用您的速度计算。通过更短的冲刺，您可以获得更多数据点。
作为一名开发人员，我喜欢在所有事情上跟踪我的速度。它让我知道我的时间估算技能是多么未经校准。我现在可以将我的历史速度应用于我的新估计，使这些估计更加合理。
作为一名团队成员，我想知道我的队友对时间的估计程度。我曾与那些一直低估自己的时间五倍或更多的人一起工作，如果你想避免不愉快的意外，提前知道这一点很重要。
所以是的，我发现速度对于任何规模的项目都很重要。
较小的迭代将使您能够更好地衡量速度，因为它们提供了更多的数据点。跟踪不必很详细，一个简单的燃尽图可以快速以图形方式查看速度。
使用速度进行规划基本上只取决于最少量的迭代是否有价值。但对于其他反馈机制也是如此——将新的学习内容融入到正在运行的项目中需要频繁的检查点，这些检查点在迭代结束时提供。因此，对于较小的项目，您的迭代应该更小，无论如何（独立于间歇发布的数量）。我曾经做过一个为期两周的培训项目，我们使用了两天的迭代。工作得很好。
使用速度会为您提供价值吗？嗯，从这里很难说。一方面，如果您的估计过程已经运作良好，它可能不会。另一方面，也许它会更好。或者它也可以工作，但需要更少的努力。还要记住，Scrum（与其他流程一样）是一个包，其中不同的组件相互支持——因此，尽管您当前的估算流程为您提供了很好的服务，但它在 Scrum 流程中可能效果不佳，或者损害了 Scrum 的其他一些方面. 而且，由于不知道 Scrum 项目的具体期望是什么，您甚至可能没有注意到问题在于估算过程。
因此，考虑到上述情况，尝试一段时间的速度并看看它如何为您工作可能是有意义的。您可以随时返回并再次尝试您的旧方法。请记住，“检查和适应”是 Scrum 的重要组成部分。只是不要忘记在适应之前进行检查。
让一个对 Scrum 有一定经验的人加入可能也是一个好主意。他们通常更容易识别反模式并提出有效的适应。