很多团队在使用Scrum的时候，都知道两到四周为一个周期，这个周期叫冲刺；进入到冲刺后，团队一定会有人提到“这个冲刺我们要xxx”、“本迭代还有xxx没完成”、“这个sprint还要xxx”——一会“迭代”，一会“冲刺”，一会“sprint”，这些词到底是不是一个意思呢？

“迭代”和“冲刺”的定义

按照惯例，先查验身份——我们看看这俩词的定义。

在维基百科中，迭代（iteration）在软件开发领域没有单独的词条解释，而是将迭代与增量开发捆绑到一起，即迭代增量开发（iterative and incremental development），在敏捷软件开发这一词条中，有一句关于迭代的介绍：“Iteration, or sprints, are short time frames that typically last from one to four weeks”——即迭代/冲刺都是一个时间盒的概念，通常持续一到四周。

冲刺（sprint）源于Scrum，在最新2020版的Scrum Guide中，对于冲刺的定义是“Sprints are the heartbeat of Scrum, where ideas are turned into value.They are fixed length events of one month or less to create consistency.”。

通过两个定义可以看出，冲刺和迭代大方向上好像确实没啥区别，都是时间盒的概念，持续时间也都差不多，那细节方面有没有啥不同呢？

“迭代”与“冲刺”的区别

迭代这词诞生的比较久——20世纪60年代就已经开始出现迭代增量开发了。最早的迭代增量开发不是出现在软件行业，而是航天事业——美国通过迭代增量的开发方法，造出了水星太空舱，帮助美国完成了第一次航天载人计划。后来迭代增量开发被应用到软件研发行业。

“软件研发的每个迭代都涉及一个跨职能团队，负责所有职能：规划、分析、设计、编码、单元测试和验收测试”（Each iteration involves a cross-functional team working in all functions: planning, analysis, design, coding, unit testing, and acceptance testing. ——维基百科），“规划、分析、设计、编码、单元测试和验收测试”听起来是不是很耳熟？是的，这是瀑布模型的内容。迭代很像一个小瀑布，每个迭代产生一部分产品功能，多个迭代就可以堆砌成一个产品。和瀑布不同的是，迭代和迭代之间，可以对产品做出一定量的调整，保证产品沿着正确的方向发展。

冲刺一词则来源于Scrum，Scrum本意是橄榄球中争球，Scrum团队应该像橄榄球游戏中的持球者一样，为了团队目标，朝着一个方向冲刺。在最新版的Scrum Guide中，能够查到116处“sprint”，而“iteration”出现的次数则是0——在Ken Schwaber 和 Jeff Sutherland两位老爷子看来，冲刺sprint才是Scrum的官方唯一指定时间盒代名词。

Scrum中的冲刺由计划会议展开，这点和迭代的规划比较像，评审会议则相当于软件的一次小的交付。但冲刺和迭代还是略有差别——首先，冲刺中我们提倡测试驱动开发，而不是必须等功能开发完成，再着手测试工作。

其次，冲刺中每天都会开每日站会，将一个大的冲刺分解成多个小的冲刺，团队成员通过“昨天做了什么”，“今天要做什么”，“遇到什么阻碍”三个问题，了解团队每个人的工作状况，以便于共享项目进度，早日发现问题，快速做出调整应对生产，而迭代则没有每日站会的相对的规定。

最后，冲刺完成后还有回顾会议，团队通过回顾这个迭代哪些做的好，哪些做的不好，可以对以后迭代做出调整。以上几个点是迭代没有明确的。

搞混了，没啥大不了

综上，严格意义上迭代和冲刺是两个概念。

从专业角度来说，Scrum中应该使用冲刺（sprint），而非迭代（iteration），冲刺一词也会给团队成员带来一种紧张感，促使团队更好的完成计划会议制定的目标。

从非专业角度来说，只要教练和团队成员能够领悟彼此的意思或者能够做到术语统一，并且提到“迭代”或“冲刺”的时候知道对方说的是什么，把“冲刺”叫成“迭代”也无伤大雅，毕竟大多数时候，大家说的都只是一个时间盒。