1) Is Velocity worthwhile in a 3-month project? Yes, I think it is. I've worked on teams where most projects were 2-6 months in length. We had one-week iterations, but I know teams that are as short as 3-days. However, there is a movement in the agile community towards a more Kanaban pull-type system where specific iterations aren't as necessary. I'd say start with iterations and then reevaluate
2) So I need velocity when we have good estimates? Probably not, given you are on shorter projects. But when something is 20 hours, and it takes you 10 days because you could only work on it 2 hours a day, then you basically need to calculate velocity using something different anyway.
If you're doing a three month project with month-long sprints, you'll only be able to use your velocity calculation for two sprints. But if you're using two week sprints, you'll have five sprints where you can apply your velocity calculation. With shorter sprints you get more data points.
As a developer, I like to track my velocity on everything. It gives me some idea of how uncalibrated my time estimating skills are. I'm now able to apply my historical velocity to my new estimates, making those estimates somewhat more reasonable.
As a team member, I like to know how well my teammates estimate time. I've worked with people who consistently underestimate their time by a factor of five or more and it's important to know that in advance if you want to avoid unpleasant surprises.
So yes, I've found velocity to be important on any size project.
Smaller iterations will allow you to get a better measure of velocity as they provide more data points. The tracking does not have to be elaborate a simple burn down chart will give a quick graphical look at velocity.
Using velocity for planning basically just depends on a minimal number of iterations to be valuable. But that's true for other feedback mechanisms, too - incorporating new learnings into the running project needs frequent checkpoints, which are provided by the end of iterations. So, for smaller projects, your iterations should be smaller, anyway (independtly of the number of intermittent releases). I once worked on a two week training project, where we used two-day iterations. Worked quite well.
Will using velocity provide value to you? Well, that's kind of hard to tell from here. On the one hand, if your estimation process already works well, it might not. On the other hand, perhaps it would work even better. Or it would work just as well, but take less effort. Also keep in mind that Scrum (as other processes) is a package where the different components support each other - so, although your current estimation process serves you well, it might work less well in a Scrum process, or compromise some other aspects of Scrum. And, not knowing what exactly to expect from a Scrum project, you might not even notice that it's the estimation process that's the problem.
So, taking the above into account, it might make sense to try velocity for some time and see how it works for you. You can always go back and try your old way again. Remember that "inspect and adapt" is an important part of Scrum. Just don't forget to inspect before you adapt.
It might also be a good idea to get someone on board who has some experience with Scrum. It's typically much easier for them to identify anti-patterns and come up with effective adaptions.
发布评论
评论（4）
因此，将您的问题分为两部分：
1）Velocity 在为期 3 个月的项目中是否值得？ 是的，我认为是的。 在我工作过的团队中，大多数项目的长度都是 2 到 6 个月。 我们的迭代周期为一周，但我知道有些团队的迭代周期只有三天。 然而，敏捷社区中存在着一种朝着更加卡纳班拉式系统发展的趋势，其中特定的迭代并不是必需的。 我会说从迭代开始，然后重新评估
2）所以当我们有良好的估计时我需要速度？ 考虑到您的项目较短，可能不会。 但是，当某件事需要 20 小时，而你需要 10 天，因为你每天只能工作 2 小时，那么你基本上需要使用不同的东西来计算速度。
我强烈推荐 XP 和 Scrum 开发 邮件列表。
So, to split your question into two parts:
1) Is Velocity worthwhile in a 3-month project? Yes, I think it is. I've worked on teams where most projects were 2-6 months in length. We had one-week iterations, but I know teams that are as short as 3-days. However, there is a movement in the agile community towards a more Kanaban pull-type system where specific iterations aren't as necessary. I'd say start with iterations and then reevaluate
2) So I need velocity when we have good estimates? Probably not, given you are on shorter projects. But when something is 20 hours, and it takes you 10 days because you could only work on it 2 hours a day, then you basically need to calculate velocity using something different anyway.
I'd highly recomment the XP and Scrum Development mailing lists.
如果您正在执行一个为期三个月的项目，其中包含一个月的冲刺，则您只能对两个冲刺使用速度计算。 但如果您使用两周的冲刺，您将有五个冲刺，您可以在其中应用速度计算。 通过较短的冲刺，您可以获得更多的数据点。
作为一名开发人员，我喜欢跟踪我在所有事情上的速度。 它让我了解到我的时间估算技能有多么不准确。 我现在可以将我的历史速度应用到我的新估计中，使这些估计更加合理。
作为一名团队成员，我想知道我的队友对时间的估计如何。 我曾与一些总是低估自己时间五倍或更多的人一起工作，如果你想避免不愉快的意外，提前了解这一点很重要。
所以，是的，我发现速度对于任何规模的项目都很重要。
If you're doing a three month project with month-long sprints, you'll only be able to use your velocity calculation for two sprints. But if you're using two week sprints, you'll have five sprints where you can apply your velocity calculation. With shorter sprints you get more data points.
As a developer, I like to track my velocity on everything. It gives me some idea of how uncalibrated my time estimating skills are. I'm now able to apply my historical velocity to my new estimates, making those estimates somewhat more reasonable.
As a team member, I like to know how well my teammates estimate time. I've worked with people who consistently underestimate their time by a factor of five or more and it's important to know that in advance if you want to avoid unpleasant surprises.
So yes, I've found velocity to be important on any size project.
较小的迭代将允许您更好地测量速度，因为它们提供了更多的数据点。 跟踪不必很复杂，简单的燃尽图将提供速度的快速图形查看。
Smaller iterations will allow you to get a better measure of velocity as they provide more data points. The tracking does not have to be elaborate a simple burn down chart will give a quick graphical look at velocity.
使用速度进行规划基本上只取决于最少的迭代次数才有价值。 但对于其他反馈机制来说也是如此——将新的学习内容融入到正在运行的项目中需要频繁的检查点，这些检查点是在迭代结束时提供的。 因此，对于较小的项目，无论如何，您的迭代应该较小（与间歇性版本的数量无关）。 我曾经参与过一个为期两周的培训项目，其中我们使用了两天的迭代。 效果很好。
使用速度会给您带来价值吗？ 嗯，从这里很难看出。 一方面，如果您的估算过程已经运作良好，则可能不会。 另一方面，也许它会运作得更好。 或者它也同样有效，但需要更少的努力。 还要记住，Scrum（与其他流程一样）是一个包，其中不同的组件相互支持 - 因此，尽管您当前的评估流程对您很有帮助，但它在 Scrum 流程中可能工作得不太好，或者会损害 Scrum 的某些其他方面。 而且，由于不知道 Scrum 项目到底会发生什么，您甚至可能没有注意到估算过程才是问题所在。
因此，考虑到上述情况，尝试一段时间的速度并看看它如何为您工作可能是有意义的。 您随时可以返回并再次尝试原来的方式。 请记住，“检查和调整”是 Scrum 的重要组成部分。 只是不要忘记在适应之前进行检查。
让具有一定 Scrum 经验的人加入也可能是个好主意。 他们通常更容易识别反模式并提出有效的适应措施。
Using velocity for planning basically just depends on a minimal number of iterations to be valuable. But that's true for other feedback mechanisms, too - incorporating new learnings into the running project needs frequent checkpoints, which are provided by the end of iterations. So, for smaller projects, your iterations should be smaller, anyway (independtly of the number of intermittent releases). I once worked on a two week training project, where we used two-day iterations. Worked quite well.
Will using velocity provide value to you? Well, that's kind of hard to tell from here. On the one hand, if your estimation process already works well, it might not. On the other hand, perhaps it would work even better. Or it would work just as well, but take less effort. Also keep in mind that Scrum (as other processes) is a package where the different components support each other - so, although your current estimation process serves you well, it might work less well in a Scrum process, or compromise some other aspects of Scrum. And, not knowing what exactly to expect from a Scrum project, you might not even notice that it's the estimation process that's the problem.
So, taking the above into account, it might make sense to try velocity for some time and see how it works for you. You can always go back and try your old way again. Remember that "inspect and adapt" is an important part of Scrum. Just don't forget to inspect before you adapt.
It might also be a good idea to get someone on board who has some experience with Scrum. It's typically much easier for them to identify anti-patterns and come up with effective adaptions.