瀑布模型|敏捷方法之外，有什么更合适的模型吗？瀑布|迭代|温斯顿|方法

【 瀑布模型|敏捷方法之外，有什么更合适的模型吗？】导读：瀑布模型、敏捷方法的对立统一从20世纪70年代就出现了，其实本质是从不同的角度、不同的粒度去对项目管理提出的方法论，都是实现目的的手段。站在今天，我们是否可以用一个新的名称和模型来统一取代呢？

文章插图
一、瀑布模型vs敏捷方法简述1. 瀑布模型瀑布模型是将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作，形如瀑布流水，最终得到软件产品。1970年温斯顿·罗伊斯（Winston Royce）提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。
核心思想：
瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
瀑布模型有以下优点
1）为项目提供了按阶段划分的检查点，或者叫做里程碑。
2）每个阶段严格区分，前一个不完成不进行下一个，当前一完成后，您只需要去关注后续阶段。
3）可在迭代模型中应用瀑布模型。增量迭代应用于瀑布模型。迭代1解决最大的问题。每次迭代产生一个可运行的版本,同时增加更多的功能。每次迭代必须经过质量和集成测试。
4）它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。
5）瀑布模型把开发人员定义为流水线上的工人。比较适合规模化、流程化的大项目，便于管理效率提升，充分降低人的因素，将人作为螺丝钉功能存在具备可替换性而不影响项目的推进。
瀑布模型有以下缺点
1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。（变化的外部市场和用户在C端市场非常普遍，B端则相对稳定）
3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
4）瀑布模型的突出缺点是不适应用户需求的变化。
瀑布模型有个重要前提是假设条件固定，按照既定的条件和目标往前推进直至标的；好处当然是程式化，管理效率高，减少了人的因素；缺点就是那个要命的前提假设。
2. 敏捷方法首先回答#敏捷#方法是不是什么情况都适用？
答案当然是否定的，适用背景大概如下：
①新兴市场、产品、行业，充满X，很多都是未知的，你的产品不成熟、用户不成熟、市场也不成熟，都在认知成长过程中 ②产品生命周期短、需求变化快、不可控因素增多
所以，我们不得不保持以下原则：

你得用尽量小的脚步，这样你才能灵活（想想凌波微步）即时调整方向；
你得以少为多，化繁为简，也就是MVP最小可用单元，你想吃火锅的时候或许1个馒头也可以
你得明白唯一的不变就是变，拥抱变化（阿里巴巴价值观中就有这么重要的一条）
你得做这一步的时候想着下一步，或者说为了做下一步做了这一步（比如微信当年推出的打飞机游戏，其实主要是为了让你升级版本，用的连环套）
你得找杠杆大的feature，力求四两拨千斤
你得时刻确保你的用户（直接用户、间接用户、支持性用户）想要，你是保持接触的

3. 瀑布、敏捷图形抽象对于两种模型：
①瀑布模型像是一条直线，给定了初始方向和力，然后沿着线条往前单向推进，直奔原定的目标，如下图（虽然很可能达到目标时候，目标已经没有意义了，就好比你现在要潜心开发一个新汽车发动机可以提高很多燃油效率，但是显然新能源的趋势不可阻挡，你的产品面世之时，说不定汽油发动机都几乎没有市场了）
②敏捷方法像是一个螺旋线，每个小圈就是一次迭代过程，在朝着目标推进的过程中，采用了尽量小的涡旋前进模式，像是对每一个小成果的一次验证，迭代-修正-迭代不断往复推进，显然对于多变的背景是更为适用的。如图：

文章插图
敏捷强调拥抱变化，瞬息万变的时代，哪有不变的前提。就像最近的买菜大战，谁想到前两年还是小玩家先烈般的探索，倒下一批又一批，今年后半段大户就一并涌入了，大户也没想到刚涌入国家调控就出了。