大家好，我是阿萨。有时候不太喜欢把英语翻译成中文，感觉翻译过来后就没法完全表达那个意思了。比如Sprint Velocity。这个词就是今天的主角。
今天先解释sprint速度背后的基本概念，然后提供5种提高敏捷软件开发团队速度的方法。
什么是冲刺速度?
敏捷开发中的速度衡量的是团队在冲刺中可以完成的工作量。它可以用故事点、小时或理想天数来衡量。理想情况下，团队的工作速度越高，他们交付的软件功能就越多，为客户创造的价值也就越多。
Sprint速度可以在Sprint项目管理中用于评估和估计团队生产力。在下面的图表中，sprint 5的效率非常高——团队制作了将近40个故事点。他们的平均速度大约是10个故事点。
平均冲刺速度，通常在最后三个迭代中进行，可以帮助研发领导了解团队可以完成多少工作，并为未来的冲刺计划工作量。
理解敏捷/Scrum速度:关键概念
下面是敏捷方法的基本概念，可以帮助解释速度。
能力
能力不同于速度，因为它衡量的是团队有多少可用的时间，而不是他们完成了多少。一般来说，全职员工每天有6个小时的工作时间(包括休息、开会、收发邮件等时间)。因此，一个拥有10名开发人员的scrum团队，每周工作5天，持续两周，其容量为600小时。
故事点
敏捷团队使用故事点来量化从sprint backlog中构建用户故事或特性所需要的工作量。单位可以因团队而异。例如，一个团队可以决定一个小的故事或bug修复= 1分，一个中等的故事= 2-4分，一个大的故事= 5-8分。从一个sprint到另一个sprint，团队试图估计每个故事“值”多少分，并承诺完成一定数量的故事点，作为sprint的一部分。
完成的定义标准
在敏捷或Scrum项目中，“完成定义”是团队用来确定故事是否已经完成的验收标准。每个团队都有自己的“完成”定义。完成的定义通常要求功能正在工作，并且能够为客户提供价值。它可以包括其他标准，如测试、代码注释、文档、同行评审等。
燃尽图
燃速图(有时称为Scrum速度图)是冲刺速度的可视化。它显示了在sprint的每一天完成计划用户描述的剩余时间。燃尽图的斜率使得预测sprint的结果成为可能——将图扩展到X轴，以查看故事何时完成——提前、准时或晚于计划。
提高冲刺速度——几点注意事项
研发领导的目标之一是随着时间的推移提高敏捷或Scrum团队的速度;用同样的资源取得更多的成就。虽然这是一个重要的目标，但也不能盲目追求:
速度不等于业务价值——团队可能在数年时间里大致交付相同数量的工作特性。他们的速度是一样的，但由于他们的专业水平、团队精神和经验的提高，他们可以在相同的故事点内提供更多的价值和更高的质量。
速度可能以质量为代价——团队被迫交付更多、更快的产品，可能别无选择，只能走捷径，减少单元测试、代码审查、UI和可用性测试等实践。
速度是一个流动的概念——在敏捷中，速度由主观的故事点估计决定，并依赖于完成的定义。仅以速度衡量的团队将有强烈的动机估算更多的点数，或降低国防部的标准。
最重要的是，速度不是最重要的。这是一个重要的指标，但需要谨慎使用，以避免损害敏捷团队的一些最佳品质。
提高速度的技巧1：提高质量
提高质量可能听起来是反直觉的。更高的质量意味着在代码审查、测试自动化和错误修复方面有更大的投资，这使得产生新功能的时间减少。因此，你可能认为提高质量可能会降低速度。
然而，大多数敏捷实践者都认为，对质量的投资总是能在提高生产力方面得到回报。现在种植质量，以后播种优雅、可维护的软件，不浪费时间去追寻过去的错误。在生产中出现问题的团队不能以高速度前进。
提高速度的技巧2：停止在不必要的测试上浪费时间
开发人员花在测试自动化和维护上的时间越来越多。这是一个关键的活动，但也会减慢团队的速度。节省时间和提高速度的一个重要方法是消除不必要的测试。
这里有三个可能是浪费时间的测试的例子。
测试重叠--对于开发人员来说，为一个已经被其他测试部分或全部覆盖的功能编写测试是很常见的。这通常发生在端到端，UI或集成测试中；这些测试很复杂，往往涵盖几个软件组件。开发人员对系统中存在哪些测试以及它们所涵盖的内容没有太多的了解，这不可避免地导致了重叠。任何测试重叠都是对时间和精力的浪费。
测试未使用的功能--在当前生产版本中很少或从未使用的功能，不值得进行额外的测试。即使你发现了错误，它们也几乎不会影响软件的活跃用户。
测试没有变化的代码--代码已经稳定了几个季度，甚至几个星期或几个月，而且没有出现过故障，现在也不可能出现故障。为没有积极工作的代码添加测试可能是一种浪费，因为终端用户已经为你测试了这些代码。
敏捷或Scrum测试方法的一个重要补充是如何通过优先考虑为客户提供最多价值的东西使测试本身变得敏捷。
提高速度技巧3：优化Sprint计划会议
敏捷方法论主张不要提前太多计划，也不要太多细节。然而，一些提前规划可以产生重要的效率。
在你的冲刺计划会议上，一定要提前计划好几个冲刺，对接下来的1-2个冲刺进行详细的任务分解，对接下来的4-5个冲刺的用户故事只做 "存根"，让团队了解 "大局"。这种额外的可见性有助于看到依赖性，识别挑战，并提前考虑方法和技术解决方案。
提高速度的技巧4：冲刺追溯和过程回顾
敏捷方法最著名的方面之一是反复的迭代，这有助于团队调整他们的流程、工具和团队工作。但有时被忽视的因素是冲刺回顾，当团队在每次迭代后坐下来讨论什么是成功的，什么是不成功的，以及如何改进。
敏捷团队收集有价值的见解，了解是什么拖累了冲刺--团队内部的合作、中断、技能缺失、与其他团队的接口、工具或技术问题。与产品负责人一起浮现这些问题，并找到切实可行的方法来解决它们，可以极大地提高速度。
重要的是，不要把回顾会议变成一个 "发泄会议"，会议中讨论的问题必须被认真对待，领导者必须花必要的时间来解决这些问题。
提高速度的技巧5：增加外部资源或培训
敏捷的跨职能团队的概念使我们认为开发团队是自给自足的单位。他们应该建立工具，创建自动化，编写代码和测试--所有这些都在冲刺的范围内。
在现实中，许多团队发现很难凑齐他们所需的基础设施，同时还能产生新的功能。有些团队缺乏某些技能--例如，DevOps、测试自动化框架，或与新组件集成时引入的不同技术。
当这些问题发生时，管理者应该注意并尝试提供支持，以帮助团队通过保持生产力。
聘请外部或内部咨询，帮助建立所需的基础设施
培训以帮助团队成员掌握新技术
为团队补充拥有急需技能的新成员
购买更好的工具，以帮助解决问题或使团队更快发展。
总结
有很多方法可以提高冲刺速度，我们介绍了五种与几乎所有敏捷组织相关的方法。其共同点是，为了提高速度，我们必须现在就做出努力，"播下种子"，以便在未来的冲刺阶段提高生产力。
软件质量可能是影响未来团队生产力和效率的最大因素。一个健全的、经过测试的、可运行的代码库是开发新功能的良好基础。相反，一个有严重测试漏洞的代码库，充满了技术债务，会使未来的开发非常困难。
