“冲刺”是scrum框架的基础，通俗地讲就是每个迭代周期，我们在实践过程中需要抓住冲刺的几个特性：时长限定，持续周期短，一致的持续期，锁定冲刺目标，完成的定义。

时长限定：

冲刺中有个时间盒（timebox）的概念，用来帮助安排工作执行情况和管理工作范围。时间盒具有设定wip数量限制，强制排优先级顺序，展示进度，避免不必要的完美主义，促进结束，增强可预测性等优点。就目前我们团队的敏捷实践来看，敏捷开展前期，团队处于传统瀑布式开发向scrum模式的过渡时期，团队成员还没有那么强的迭代时间盒的概念，可以多提醒团队成员时间盒，或者将当前迭代的起始时间张贴到大家每天都能看到的地方，让大家在完成迭代计划的时候有时间概念，达到冲刺的目的。

持续期短：

持续周期短的冲刺跟瀑布式开发模式相比更容易规划，得到反馈的速度更快，如果我们做完一件事很快就可以被检验，就算有错误也能及时纠正，错误成本大大降低。从团队成员来看，持续周期短，反馈迅速能够有效地减少人出现疲颓的现象，提高团队成员的工作效率。

一致的持续期：

一般来说，团队的冲刺时间最好固定，因为这样有助于团队形成一个有节奏感的冲刺活动，几个迭代周期之后，也更方便估算团队的迭代工作量，制定更为合理的迭代计划。说到团队的节奏，我觉得一味地满负荷的迭代冲刺也是不可取的，会造成团队成员疲累，长此以外，便失去了冲刺的“冲”。团队可以根据成员的需要，进行一些帮助团队缓解压力，放松身心的活动，大家可以在迭代回顾会上就这些事进行讨论，比如我们团队之前就有成员提出每周六下午大家一起出去运动，诸如此类。总之，迭代冲刺不是空喊着提高效率一味地干活，而是劳逸结合，形成张弛有度的团队节奏。

锁定冲刺目标：

冲刺目标是团队和产品负责人作出的共同承诺，团队承诺在当前冲刺结束之前完成目标，产品负责人承诺在冲刺执行过程中不改变目标。这涉及到相互之间的承诺，所以冲刺目标在迭代周期内是不允许的变更的，就像是大家都应该遵循的游戏规则，随便更改冲刺目标是十分影响士气的事。但是不可变更并不意味着不可以澄清，变更和澄清的区别在于，变更会涉及需求变更，导致大量的工作返工，而澄清更多的是对需求的补充说明，提供更多的细节来帮助团队实现冲刺目标。

当然游戏规则也是团队和产品负责人一起定的，并不是要求我们墨守目标，盲目地把它当作铁律，团队还是要注重实效，不应该因为团队中某一个群体或个人的原因随意更改目标，但如果是团队共同的效益，我们也可以适时地做一些调整。比如我们团队，会有一些现场的vip任务，如果当一个紧急的vip任务来了，而团队成员又没有闲置的工作来完成的时候，可以在对团队目标没有大的影响的情况下，做一些等工作量的替换，将优先级稍低的工作延后。

另外冲刺目标的达成是跟团队士气息息相关的一件事，所以刚实践敏捷的团队，建议刚开始的迭代周期不要将工作量排得太满，一是因为刚开始团队成员对敏捷的流程把握还不够准确，所以对工作量的评估可能不够准确。举个例子，我们团队的一部分测试工作是由开发人员结对相互测试，第一个迭代周期的时候，我们的开发就只评估了自己开发的时间，而没有考虑到结对测试的时间，导致后面计划完成得很吃力。二是因为一开始的几个迭代周期如果能顺利进行有助于建立团队成员的信心，我们应该尽可能地保证团队能顺利并愉快地进入到敏捷模式中。

完成的定义：

完成的定义是在宣布工作潜在可发布版本之前，要求团队成功完成的各项工作检查。包括开发的DOD，测试的DOD等，团队可以根据自己的特点自定义DOD，并且可以随着团队的敏捷成熟度进行不断的优化调整，形成有自身团队特色的DOD。团队的DOD就像是一些大家都需要遵循的规格，是大家互相之间的承诺，所以我们团队在定义DOD时是大家一起讨论得出的，后续的变更优化也会充分尊重大家的意见。既然是要团队成员一起遵守的事情，那么让团队成员一起讨论制定更有说服力，也更能促进它的落地。

总结：

在我看来，冲刺是敏捷中十分关键的要素，区别于瀑布式开发，它以快速反馈，持续改进的方式，先定一个小目标，小步快跑，从而准确高效地达成项目的长期目标。当然这只是从冲刺的角度看问题，我们不应该被冲刺的一个个小目标遮蔽了双眼，只专注于一个个小的功能特性，而忽视了一些不紧急而重要的工作，团队或者是产品负责人一定还是要有全局的观念，把握住产品的大方向，合理地制定每个迭代周期的计划。