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