迭代=冲刺？

本文作者：特邀敏捷教练梁堃

 

前段时间在和一个小伙伴聊天的时候，他问了阿甲这样一个问题：Scrum guide中把固定时间盒周期称为sprint（冲刺）,但是为什么大家在平时都愿意把它称为迭代（iteration）呢？

从阿甲接触敏捷至今，对于sprint和iteration这两个词也是经常混着用，但关于这两个词之间的关系和区别，还真的没有思考过。正好阿甲也想趁这个机会和小伙伴们一起把这个概念理清楚，所以-

“干货还有5秒钟到达战场”

 

大家先看下iteration和sprint这两个英文单词的本源之意。

以下是剑桥词典对于iteration和sprint的解释：

 

Iteration :

the process of doing something again and again, usually to improve it, or one of the times you do it.

 

Sprint：

to run as fast as you can over a short distance, either in a race or because you are in a great hurry to get somewhere。

 

在wiki中：

迭代是重复反馈过程的活动，其目的通常是为了接近并到达所需的目标或结果。每一次对过程的重复被称为一次“迭代”，而每一次迭代得到的结果会被用来作为下一次迭代的初始值。

 

在Scrum中，Sprint 说的是类似橄榄球比赛中的冲刺：大家团结一致，为了完成该Sprint的目标疯狂向前冲。

 

通过以上对于冲刺和迭代的字面分析，我们可以看到迭代的重点在于重复（again and again）过程，而冲刺的重点则是在相对短的时间尽快（run as fast as you can）到达终点。

这也和我们在产品开发管理中运用这两个词语的场景基本符合，下面我们从产品开发过程来更深入认识下面这两个单词是从哪里来，要到哪里去这个深刻的哲学问题。

 

早在20世纪50年代末期，软件领域中就出现了迭代模型。

最早的迭代过程可能被描述为“分段模型（stagewise model）”。迭代模型是RUP推荐的周期模型。被定义为：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。

 

在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：需求分析、设计、实施和测试工作流程。

实质上，它类似小型的瀑布式项目。

RUP认为，所有的阶段都可以细分为迭代，每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。

 

迭代开发承认我们在把事情做对之前有可能做错，在把事情做好之前有可能做坏。（Goldberg and Rubin，1995）

 

迭代开发本身是一种有计划的修改策略：通过多次开发来改善正在构建的特性，逐步得出一个完善的解决方案。例如，对一个知之甚少的产品，开始时可以先创建原型以获得重要知识，接着可以创建一个更好一点的修订版，再接下来是一个相当好的版本。例如，在文章写作过程中，我在收到反馈以及对如何表达主题有了更深刻的理解后，把每章都修改了几次。

 

在scrum框架中则整合了迭代和产品增量2个概念使用冲刺（sprint）来作为固定时间盒的描述。Sprint 是 Scrum 的核心，其长度（持续时间）为一个月或更短时间的限时，在这段时间内构建一个“完成的”、可用的和潜在可发布的产品增量。在整个开发过程期间， Sprint 的长度通常保持一致。前一个 Sprint 结束后，新的下一个 Sprint 紧接着立即开始。

 

冲刺则更强调在短的时间内“撞线”，团队成员确定冲刺的目标之后，以尽可能快的速度来进行协同工作，帮助团队在冲刺结束的时候达成目标。这个目标可能是产品增量，也可能是一些独立的特性，但是在Scrum中称其为PSP（潜在可交付）。冲刺的另外一个特性则是在每个冲刺中一定要有计划/评审/回顾/每日站会等仪式来确保冲刺能够达到应用的效果。而在迭代中则不必须要。

 

举个例子：

阿甲以前在某大型电信企业参与开发一个复杂系统，全部开发周期为一年，项目经理将项目分解为几个小的里程碑，然后确定了每个里程碑要交付的功能特性和相关交付物，接着客户在每个里程碑截至日期进行验收，我们可以认为这就是一种迭代开发模式。

但是在这个项目中，需要注意的是前期需求分析，功能设计都是在迭代开始前就已经做好的，这也是很多大型企业使用迭代来进行产品开发的一个习惯做法。而且每个里程碑实际上不一定能产生增量或者特性，比如说有一些是文档的输出或者单独测试，基础架构搭建完成等。

 

而大部分scrum团队则采用的是1-4周sprint来进行开发，每个sprint有固定的仪式来让大家参与，同时结束的时候要产生PSP（潜在可交付），业务和市场每个sprint都会参与团队评审，通过这种方式来获取快速反馈和高效协同。

每个sprint的产出一定是可以交付（但不一定交付），能够通过客户的评审并且验收，同时也是要有价值的！

这就要求团队成员不仅仅是完成任务，更多的是思考如何给客户带来价值。

 

从上面我们可以看出冲刺和迭代实际上是有一些区别的，但在实际应用中，阿甲发现很多SM或者coach在讲述这个问题的时候经常使用迭代来进行替代，这是一个习惯问题。不过阿甲发现，更多的时候如果我们使用冲刺概念则能够给团队带来的一些更好的效果，因为冲刺更可能带来短时间撞线的紧促感，更好地让团队成员计划每日的工作，反思自己每天的工作给予我们冲刺结束交付带来的帮助和阻碍。而另外一点则是如果使用迭代，则意味着不一定要有实际可用的交付物，但是冲刺则不然。

 

对比	迭代	冲刺
时间周期	不一定，但是往往会时间比较长。	时间有明确固定，一般不超过一个月，在实际应用中会变的更短。
开发内容	有可能是单独的开发，测试，需求设计等。	完整的包括设计开发测试所有内容。
交付目标	不一定可以使用，而且可能会发生变化。	潜在可交付物，一般不会发生改变。
应用场景	大部分以产品和项目为主，涉及到多个组件团队。迭代总时间经常以产品开发周期为结束。	以团队为主，团队要求是特性团队，能够端到端交付价值，只要团队在就会以这种模式来进行开发。
团队	团队成员一般关注于自己的工作任务，团队整体目标由项目经理等人把握。	因为时间盒短，所以经常几个开发人员共同协作完成一个用户故事或者功能
仪式	不一定需要计划/评审/回顾会议。	Scrum中的冲刺则明确要求有计划/评审/回顾会议组成。

 

上面就是阿甲自己对于迭代(iteration)和sprint（冲刺）在敏捷和scrum中的理解，不知道小伙伴们是否认同呢，当然也欢迎各位小伙伴们批评指正和补充。

阿甲的一个特质优点就是脸皮厚，不怕板砖哦。

转载于:https://www.cnblogs.com/ylsara/p/9188110.html