Velocity是一种非常简单，功能强大的方法，用于准确衡量Scrum开发团队持续提供业务价值的速度。要计算敏捷团队的速度，只需将迭代中成功交付的功能，用户故事，需求或积压项目的估算值相加即可。
在完成第一次迭代之前，有一些简单的指南可用于估算Scrum团队的初始速度（请参阅下面的常见问题解答），但在此之后，您应该使用经过验证的历史测量来规划要素。在短时间内，速度通常会稳定，并为提高敏捷项目的近期和长期规划的准确性和可靠性提供了巨大的基础。敏捷交付周期非常小，因此速度很快就会出现，并且可以在项目的早期阶段进行验证，然后依靠它来提高项目的可预测性。
速度真的很简单吗？
是的，确实如此。不要试图不要使速度过于复杂 - 它确实是一个直接的概念，其很大的价值在于它固有的简单性。许多对敏捷方法不熟悉的管理者和团队倾向于过度分析速度的概念，并围绕它进行过多的复杂化。经过几个月的敏捷项目经验，大多数人都会体验到“啊哈”的速度，摆脱与之相关的任何包袱，并欣赏其简洁性和内在价值。
速度图表
除了发布和迭代燃尽图之外，测量敏捷团队的速度已经证明可以提供对项目进度和状态的巨大洞察/可见性。速度图表显示了在所有迭代中提供的工作估计值的总和。通常，速度将在项目的整个生命周期内稳定，除非项目团队的构成变化很大或者迭代的长度发生变化。因此，速度可用于未来的规划目的。虽然对于几次迭代通常是可靠的，但如果您接受优先级，目标和团队可能会随着时间的推移而发生变化，从而导致未来的迭代置信水平发生变化，那么可以使用速度来计划未来的发布。敏捷项目团队的典型速度图表可能与此处的图像类似。
最初，敏捷软件开发新手应该潜入并使用可用的指南和信息选择初始速度。非常快（与下一次迭代一样快），可以测量和调整速度。速度，以及细粒度特征（例如，用户故事，积压，要求等）和高级和/或相对估计（在点数，理想日期甚至数小时内），极大地简化并加速了整个项目规划，估计，状态跟踪和报告过程。
敏捷Scrum常见问题解答
如何计算敏捷开发团队的速度？
速度是每次迭代的传递（即，接受）特征的估计的总和。
用什么单位测量速度？
速度的测量单位与特征估计值相同，无论是故事点数，天数，理想天数还是Scrum团队提供的小时数 - 所有这些都被认为是可接受的。
如何估计第一次迭代的速度？
对于敏捷团队的第一次迭代，一般指导原则是在可用时间的三分之一处计划初始速度。如果您正在估算理想的程序员时间，那么此帐户将用于会议，电子邮件，设计，文档，返工，协作，研究等。例如，有六个程序员和两周的迭代，总共60个程序员日（6个）程序员x10天）可用。在这种情况下，一个良好的开端是在迭代中计划20个理想的工作日。如果使用实际时间，则包括足够的缓冲区以考虑标准项目1）开销和2）估计不准确性。此外，请记住，在第一次迭代期间，速度会很快出现。如果被低估，第一次迭代的速度将随着新特征的增加而上升; 如果高估，速度将随着特征的消除而降低。
会议，电话，电子邮件是否包含在速度中？
这取决于是否估计这些项目并将其包含在迭代计划中。它们通常不包括在内 - 速度的目标是在敏捷团队的交付能力方面跨迭代的相对一致性和可预测性。
是否应该在所有敏捷开发团队或项目中积累速度？
速度是一种非常局部的措施。除了具有不同团队“个性”的不同团队成员之外，项目通常在估计技术，详细过程，技术，客户参与等方面具有独特的特征。因此，这可能使组织范围的分析非常不准确。另一方面，如果你的所有团队估计完全一样，开发完全相同，测试完全相同，并跟踪完全相同，那么无论如何，也许你是例外。
如果速度波动怎么办？
速度通常会在合理的范围内波动，这是完全正常的。如果速度波动超过一次或两次迭代，Scrum团队可能需要重新估计和/或重新协商发布计划。
速度稳定需要多长时间？
对于大多数敏捷开发团队而言，速度通常会在3到6次迭代之间稳定下来。
我如何估计未来的迭代？
未来的迭代使用团队的成熟历史来确定团队可以做多少。因此，速度是用于规划未来迭代的正确措施。
如果项目团队改变规模，我如何估计速度？
Velocity依赖于团队的一致性，以便最有价值。如果您的敏捷团队发生变化，请在规划未来迭代时使用常识。如果您的团队中有20％的人无法进行几次迭代，那么将计划速度降低20％左右。如果这包括几个关键参与者，特别是可能不太可用的客户，那么将估计值降低一点。只需要花费下一次迭代的时间就可以更好地理解团队可以提供的内容以及新的速度。
最大速度意味着最大生产力吗？
绝对不。为了最大化速度，团队实际上可能实现相反的目标。如果要求最大化速度，团队可能会吝啬单元或验收测试，减少客户协作，跳过修复错误，最小化重构或各种敏捷开发实践的许多其他关键优势。虽然可能提供短期改善（如果你可以称之为），但会产生负面的长期影响。目标不是最大化速度，而是最佳速度随时间推移，其考虑了许多因素，包括最终产品的质量。
如果我们的迭代长度发生变化，我们如何测量速度？
你没有，至少不那么容易。Velocity的价值来自于其固有的一致性。固定的迭代长度有助于推动项目的可靠节奏。如果没有这种节奏，您将不断修改，重新估计和协调，并且由于结果不一致，将来预测的能力降至最低。另一方面，如果几乎每个人都会在假期或一两天的公司范围内召开会议，那么通过各种方式只需使用常识并相应地调整迭代日期或速度。像大多数敏捷实践一样，这些是准则，而不是旨在防止常识的规则。
