敏捷和迭代横行的时代，你的开发还顺利吗？

自敏捷思想进入国内以来，软件开发便进入了敏捷横行的时代，似乎每一个人都在谈敏捷，谈迭代，不管有没有尝到敏捷带来的甜头，先捧起来再说，至少沾上了敏捷的边，就好像走在了时代的前列，未来一片光明啊。

那么所谓的敏捷和迭代是一回事吗？

记得有一次跟朋友吃饭，说他们现在的项目用敏捷开发，每个迭代都能看到不断完善的产品，非常有成就感，客户的满意度也提升了不少；另一个朋友说，我们用迭代开发，也是这样，而且客户想加什么需求就加什么，直接按照优先级排到迭代周期就行，也不用为改需求而烦躁。当时我就想，敏捷开发不就是分迭代周期的吗，他俩好像说的是一回事吧，后来证明还真不一样。

迭代开发流程:

什么叫迭代开发？

在迭代开发中，整个开发工作被组织为一系列的短小的、固定长度（如3周）的小项目，被称为一系列的迭代，这叫迭代开发。每一次迭代都包括了定义、需求分析、设计、实现与测试。而敏捷开发是以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。前者是软件开发的生命周期模型，是一种开发过程；后者是多种软件开发项目管理方法的集合，是一种开发方法。这是两者最根本的区别。与迭代开发对应是瀑布模型，螺旋模型等，而与敏捷开发对应的是Scrum，XP（极限编程），Crystal（水晶编程）等开发方法，所以它俩根本就不是一回事！那么它们俩有没有关系呢？答案是：有…

敏捷-Scrum开发流程:

敏捷开发的定义就已经说明，采用迭代的方法进行软件开发。

那么有人会问，敏捷开发为什么要采用迭代开发呢？

不要忘了敏捷开发的核心原则是拥抱变化，和递增的变化。迭代式开发正适合在那些需求信息不明确的项目，这样在开发过程中遇到需求的变化时，所带来的影响要比其他模型小。而现在的很多项目中，需求在项目进行中变化的事儿经常见，所以显得迭代式开发的优势更明显一些，这正符合敏捷开发的拥抱变化。

迭代开发是不要求每一个阶段的任务做的都是最完美的，明明知道还有很多不足的地方，却偏偏不去完善它，而是把主要功能先搭建起来，以最短的时间，最少的损失先完成一个“不完美的成果物”直至提交，然后再通过客户或用户的反馈信息，在这个“不完美的成果物”上逐步进行完善，这正符合敏捷开发的递增变化。

当然，敏捷开发只是一个总体概念，而迭代式开发只是几乎所有敏捷开发所采用的一个主要的基础实践。敏捷开发除迭代式开发外，还包含了其他许多管理与工程技术实践，如演进式架构设计、敏捷建模、重构、自动回归测试（ART）等等。总而言之，就是敏捷开发与迭代开发是整体与局部的关系，前者就像大家庭，而后者是大家庭中的一员。

敏捷发展历史

敏捷和迭代虽然不一样，但是它们也是分不开的，迭代和敏捷开发方式的结合，既保证了产品的质量又在项目产品的持续改进中具有一定的优势。吸取精华,破其糟粕，只有这样，项目才会达到趋于完美的程度。

那么根据上面的说法，敏捷和迭代的方式一定是完美的？

这还真不一定。不可否认的是敏捷开发相对于传统开发是具有一定的优势的，但是适用性有多强，有待商榷。

近些年来，由于一些特定的需求，越来越多的软件团队开始采用敏捷开发模式，但是在开发过程中却对其思想认识不足，例如，有些敏捷开发团队甚至不设管理人员，只有一个向产品经理汇报的 scrum master，职责不比秘书强到哪里去。产品经理继续向上汇报，直到市场或销售总监，这种开发简直...

排除软件公司，在很多常规企业中，敏捷开发很多已经异化为无人管理、无人负责的开发流程：产品经理、销售、CEO拍脑袋加功能、改需求，然后开发团队就赶快“敏捷”去吧。需求调研？设计？反馈？代码评审？测试？统统不需要。说好听点这叫敏捷开发，说不好听点，这就是技术大杂烩，能做到哪一步算哪一步，完全忽略了敏捷开发的实质，唯一的好处可能是说出去好听罢了。

而实际上，敏捷开发并不是这样来的，迭代的核心在于软件的超前规划，如果没有软件开发经理，所有人都在盲人摸象，造出来的全是 垃圾 -- 时间超限、预算超支、充斥着各种拍脑袋的奇思妙想、根本不管需求是不是合乎逻辑。客户肯定各种抱怨，需要产品支持怎么办？那就从一线开发抽人去维护嘛，结果是最好的码农一天被工单打断八百次。

一线人员每天花 8 个小时擦屁股，虽然如果管理流程良好这些问题根本不会出现；开发时间如果不够，那就 996 或者 9127，码农就是用来加班的。

产品延期了怎么办？告诉 scrum master 们（这些人身上经常挂个敏捷专家的标签，哪怕四体不勤五谷不分），需求变啦。有点能力的程序员肯定气的直接拉勾领英走起了，HR再招一群新兵蛋子进来。项目历史？遗留问题？设计思路？早就丢了。正好，推倒重来吧，周而复始。