小型项目的速度

Question

我目前正在学习scrum，并想向这方面经验丰富的专业人士学习。

速度是否与需要3个月(通常需要2-3次中间交付给客户)的项目相关？

我认为现在没有足够的时间来做出相关的统计数据。在整个项目中记录每个开发人员的速度以获得足够的统计深度是否值得？

另一个问题是速度对小项目真的如此重要吗？

我们在这个领域有很多经验，我们的估计非常准确。我们遇到的唯一问题是与风险因素相关的，有时会打击你，但我们知道我们的风险并知道如何处理它，我不确定scrum是否会帮助解决客户板上的硬件问题。

我确实在其他部分看到了很多逻辑，比如小迭代，连续集成，让产品/项目管理非常接近开发过程，我认为我们已经在不知不觉中通过scrum做了很多事情。

因此，我不认为scrum作为整个概念是否适合我的需求，但我确实看到我可以使用许多概念(我真的很喜欢backlog)来使我们的开发过程更好。

实际上，它与其说是问题，不如说是讨论，但它不是为此而设计的，所以如果它不合适，我很抱歉。

Answer 1

所以，把你的问题分成两部分：

1)在一个3个月的项目中，Velocity值得吗？是的，我想是的。我在团队中工作过，大多数项目都需要2-6个月的时间。我们有一周的迭代，但我知道团队只有3天的时间。然而，在敏捷社区中，有一种更多的Kanaban拉式系统的运动，在这种系统中，特定的迭代不是必要的。我会说从迭代开始，然后重新评估

2)所以当我们有好的估计时，我需要速度？可能不会，因为你在做更短的项目。但是当一个东西是20个小时的时候，你需要10天的时间，因为你每天只能工作2个小时，那么你基本上需要使用不同的东西来计算速度。

我会高度评论XP和Scrum Development邮件列表。

Answer 2

如果你正在做一个三个月的项目，其中有一个月的冲刺，那么你只能使用你的速度计算来进行两次冲刺。但是如果你使用两周的冲刺，你将有五次冲刺，你可以在其中应用你的速度计算。随着冲刺时间的缩短，你会得到更多的数据点。

作为一名开发人员，我喜欢跟踪我在所有事情上的速度。这让我对我的时间估算技能有了一些了解。我现在可以将我的历史速度应用于我的新估计，使这些估计更加合理。

作为团队成员，我想知道我的队友对时间的估计有多好。我曾经遇到过一些人，他们总是将自己的时间低估了五倍或更多，如果你想避免不愉快的惊喜，提前知道这一点很重要。

所以，是的，我发现速度在任何规模的项目中都很重要。

Answer 3

较小的迭代将允许您获得更好的速度度量，因为它们提供了更多的数据点。跟踪不需要精心设计，一个简单的燃尽图将给出一个速度的快速图形查看。