瀑布模型
瀑布模型是将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作，形如瀑布流水，最终得到软件产品。
瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法
将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，
并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
瀑布模型有以下优点
1）为项目提供了按阶段划分的检查点。
2）当前一阶段完成后，您只需要去关注后续阶段。
3）可在迭代模型中每轮迭代很类似一个小的瀑布模型。
增量迭代应用于瀑布模型。每次迭代产生一个可运行的版本,同时增加更多的功能。每次迭代必须经过质量和集成测试。
4）它提供了一个模板，这个模板使得分析、设计、编码、测试可以在该模板下有一个共同的指导。
瀑布模型有以下缺点
1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
4）瀑布模型的突出缺点是不适应用户需求的变化。
迭代模型
迭代包括产生产品发布（稳定、可使用的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。
在某种程度上，一次迭代是一次完整地经过所有工作流程的过程：计划 、需求分析、设计、编码和测试工作、
发布流程。实质上，它类似小型的瀑布式项目。每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。
优点
与传统的瀑布模型相比较，迭代过程具有以下优点：
1）降低了在一个增量上的开发风险。如果某个迭代完成后的软件不符合客户要求，那么损失只是这一个开发有误的迭代的花费。
2）降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙。
3）加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率。
4）由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。
缺点
对产品人员的节奏把控能力（定每周目标，需求优先级剖析，以及临时需求的处理）有较高要求，不然容易陷入每周发版日加班加死的节奏。
接触过几家互联网创业公司，发现在快速迭代上都有一个明显的误区：那就是只注重产品功能层面的快速迭代，而无视系统架构层面的快速迭代。
造成的结果就是在系统后段架构还是一团混沌，甚至还没有后端架构的时候，就已经在产品上堆砌了一堆功能。
这无异于在地基倾斜的地面上盖楼，盖得越高，越危险。当你发现你的后端系统已经病入膏肓急需改造时，却发现上面已经跑了大大小小各样的功能，积重难返。
不注重后端架构的迭代是个通病，原因不外乎：
1） 初期产品用户规模小，性能并不是主要瓶颈
2） 团队里面没有优秀的架构师，优化力不从心。
3） 后端架构优化是个慢活，它不像产品功能层面的迭代那样可以快速被感知，对于强产品驱动而非强技术驱动的公司来说，不够重视。
4） 后端架构优化更是个细活，它也不像产品功能一样有很明显的“产出”，对于不懂技术的领导或者以KPI为导向的公司文化来说，员工去优化后端的意愿并不强烈。
5）产品交付进度压力比较大，没有时间去思考架构的优化，精力都在聚焦怎么实现功能上面
下图是 每一个迭代产品样子，随着迭代的增加，产品的功能是越来越丰富的，由于每个迭代都在根据用户反馈调整需求，最终的产品也一定是负责用户要求的
