敏捷开发中，如何理解迭代开发和增量开发

敏捷开发.png

Scrum基于迭代开发和增量开发。

这两个术语经常被用作一个概念，但是他们俩实际是有区别的。

敏捷原则中，有提到可变性与不确定性。并以此为长期的指导原则。

计划驱动的顺序开发方式假设我们事先就能把事情做对，大多数或者所有产品部件到后期再集成。可是随着软件行业的技术革新与信息爆炸，一个复杂的项目已经不可能再采用计划驱动的方式处理，否则将承受很大的失败风险。

迭代开发

迭代开发承认我们在把事情最对之前有可能做错，在把事情做好之前有可能做坏。迭代开发本身是一种有计划的修改策略。通过多次开发来改善正在构建的特性，逐步得出一个完善的解决方案。

不过产品迭代开发的最大缺点是在遇到不确定因素的时候，很难事先确定需要改进多少次。

理解迭代.png

此图非常经典，用于阐述很多敏捷方面的概念和理念。最开始是解释MVP的概念，但是正好借助MVP也可以更好的理解迭代开发。

客户需要一种工具，希望可以从A地快速的到达B地。于是研发团队开始开会研究，假设他们严格的执行了迭代开发的原则（因为他们也不确定最后造出来的到底是什么）。因为用户的需求很迫切，研发团队要快速的占领市场。所以首批推向市场的工具：滑板。

交到用户手里时，用户很高兴。这个小东西可比走路快多了。但是随着使用的时间增加，会很累。研发团队在得到用户的反馈之后，又快速迭代。在原有滑板的基础上，增加了扶手装置。有了扶手装置，明显没有那么累了。但是长距离使用时，还是需要一只脚登地发力，还是很累。

好，又得到了用户的反馈。针对反馈优化产品放入下一轮迭代。这次交付到客户手中的产品，被设计成了一个具有两个大大轮子的东西。用户骑起来，果然又快又省力。可是，用户又问，还能更快吗？

还能更快吗？对于研发团队没有什么做不到的，发挥集体智慧。在第四个迭代完成后，交付到客户手中的是具备发动机提供动力取代人力的东西。根本不需要人出力，用户非常的高兴。

这个时候用户已经可以很快的从A地到达B地了。但是用户的需求永远的不会满足，“我需要带着我的家人去海边度假”，“我需要拉些重物到XX”。最后交付到用户手中，是一辆崭新的骑车。

从一开始用户提出需求后，任何人都没有想到最后交付的尽然是一辆汽车。但是这些都是在一次一次不断的迭代中，逐步形成的。但是这其中有一个环节是不能被忽视的，发布、反馈和调整。这是一个正向的闭环。发布完版本之后，听取使用者的反馈，在根据反馈进行调整。反馈可能或者一定与研发团队预想的不一致，所以需要先接纳变化，内化后再输出。

增量开发

增量开发基于一个古老的原则：先构建部分，在构建整体。我们避免到最后才冒出一个大的、爆发式的活动，集成所有组件和交付所有产品。相反，我们把产品分解成更小的特性，先构建一部分，再来做出调整，构建更多的特性。

增量开发展示了一个重要的信息，使我们能够适应开发工作并改变工作方式。增量开发中最大的缺点是逐步构建的过程中，有迷失全局的风险。

Scrum

Scrum综合了迭代和增量两种开发模式的有点，消除了单独使用其中一种模式的缺点。Scrum使用一系列固定时长的适应性迭代来同时利用这两种方法的思想，这种迭代便是冲刺。

在每个冲刺都进行所有必要的活动，常见可工作的产品增量。

对于冲刺的一种误解为：每个冲刺只集中做一种类型的工作。Scrum并不是每次做一个阶段的工作，而是每次做一个特性（增量模式）。这样一来，在冲刺结束的时候就可以创建一个有价值的产品增量。在收到冲刺结果的反馈后（迭代模式），我们可以减性调整。在接下来的冲刺中可以选择开发其他特性或是修改用于构建下一组特性的过程。

最后，敏捷转型与实践是一个长期的过程。其中受于人和环境的影响，可能不同的公司、团队的效果预期会不一样。这就需要我们不断的思考，尝试，反馈，调整。

It's a long term......Good Luck!