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

导读：瀑布模型、敏捷方法的对立统一从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. 瀑布、敏捷图形抽象

对于两种模型：

① 瀑布模型像是一条直线 ，给定了初始方向和力，然后沿着线条往前单向推进，直奔原定的目标，如下图（虽然很可能达到目标时候，目标已经没有意义了，就好比你现在要潜心开发一个新汽车发动机可以提高很多燃油效率，但是显然新能源的趋势不可阻挡，你的产品面世之时，说不定汽油发动机都几乎没有市场了）

② 敏捷方法像是一个螺旋线 ，每个小圈就是一次迭代过程，在朝着目标推进的过程中，采用了尽量小的涡旋前进模式，像是对每一个小成果的一次验证，迭代-修正-迭代不断往复推进，显然对于多变的背景是更为适用的。如图：

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

敏捷vs瀑布，下面这张流传的图片很形象的展示给了我们答案，严格的阶段划分+一始而终的前进，如果缺乏必要的中间验证和接触，后果是多么的离谱……

瀑布和敏捷2个阵营还进行过大辩论，网络上相关内容也是纷纷扰扰，到最后的结果也是你中有我我中有你，各有优劣。

假如提出1个新的模型方法，是不是就可以完美解决了呢？

二、流体模型

一个兼具瀑布模型和敏捷方法于一体的模型设想，这个灵感来源于大学时候流体力学那门学科。

1. 物理学角度看流体模型

我们先从流体力学的角度展开，如上图， 湍流和层流都是流体的一种流动状态 ：

• 【瀑布状态】当流速很小时，流体分层流动，互不混合，称为 层流 ，也称为 稳流 或 片流 ；
• 【混沌状态】逐渐增加流速，流体的流线开始出现波浪状的摆动，摆动的频率及振幅随流速的增加而增加，此种流况称为 过渡流 ；
• 【敏捷状态】当流速增加到很大时，流线不再清楚可辨，在流场中有许多小漩涡，层流被破坏，相邻流层间不但有滑动，还有混合，从而形成 湍流 ，又称为乱流、紊流或扰流。

2.  流体模型的拆解

流体模型—— 正是基于瀑布和敏捷的两种理念的交融：

①瀑布状态（层流状态）

如同流体模型中的层流状态，这时候流速很小，也就是外界环境相对稳定不存在多变的条件、复杂的背景。 整个产品开发和项目管理流程按照有序的状态和严格的先后次序进行流水线开发及管理。

②转换条件（过渡区）

随着外界复杂性，变化速度的加快，层流形式（即瀑布模型）不再能够适应环境 。在产品和项目的场景中，外部条件包含：市场的变化、用户需求的变化、政策及经济环境变化、竞品市场变化；内部条件有：战略方向调整、团队变动等。致使若继续一味按照层流即瀑布模型会背离环境变化，导致最终偏离目标。

③敏捷状态（湍流状态）

转换条件发生，模型自动转换为湍流状态，也就是敏捷中的小步快跑、不断迭代、拥抱变化。

1）湍流状态特征

下面聊一下流体模型中转换为湍流状态后的特征表现：

湍流基本特征是流体微团运动的随机性。湍流微团不仅有横向脉动，而且有相对于流体总运动的反向运动，因而流体微团的轨迹极其紊乱，随时间变化很快。湍流中最重要的现象是由这种随机运动引起的动量、热量和质量的传递，其传递速率比层流高好几个数量级。

——引自湍流的物理学释义

2） 湍流特征和敏捷不谋而合

1. 湍流的轨迹紊乱，随时间变化快 ——正是敏捷强调的拥抱变化，变化因素具有相通性质，看似有序的世界和环境，不过是无序的一种特征值体现；
2. 湍流有相对流体总运动的反向运动 ——敏捷中最小成本验证，可以视作如此的案例。每一次验证时一种尝试，可能正确可能方向错误导致失败，正如流体模型中湍流状态时无序甚至和总方向相反的乱流一般；
3. 湍流引起的动量热量和质量传递速率比层流高好几个量级 ——敏捷在不断的找支点、放杠杆，迭代之间可以独立且存在依托，所产生的价值杠杆对于与层流（瀑布模型）的一始而终，是不可比拟的，对于标的达成的撬动能力更是不可言喻。

3.流体模型回顾

流体模型，正是描述同一种流体即同一个组织在产品和项目的实现过程中，当面临不同的外部和内部条件变化，有层流状态（瀑布状态）和湍流（敏捷状态）的衔接切换，中间过渡区的存在，有瀑布和敏捷的相互结合，从而达到目的。

实际工作中，有时即便是在适用瀑布模型的项目中，也难免的采用到敏捷的方法作为支撑，比如：关键时期高频的信息触碰、外部条件的监控等；而敏捷项目中又何尝不存在瀑布的影子，你的需求管理流程等都又是瀑布的做法；现实中已经很难再将瀑布和敏捷完全区分，共生或许已经是常态，只是存在一个“过渡区”让二者可以自由的衔切。

4. 流体模型中将弊端也一并展示

对于一种流体，在外部条件引起湍流后，一方面它强化了动量、热量、质量传递和反应过程；另一方面极大地增加摩擦阻力和能量损耗。

这在组织和项目中何尝不是呢，当我们进入敏捷状态之后，面临的变化、不断迭代、时刻专注、保持接触等，一方面会极大的促进组织活力、产品成长，激活产品生命周期曲线；另一方面，不得不承认这种节奏对精力的消耗，是所有人有目共睹的，快速的人员迭代在组织中也是常态；同时，这种状态下各个小组或产品项目未达成自己的目标，会产生并行情况，比如在职能线的模式中，不同的产品项目就会产生较大的阻力而不得不在产品评审中杀的你死我活。

三、结语

我们在不断的探索中会走过的路有很多：一个需求的生老病死，一个项目的开始完成，一个产品的生老病死，一个组织的生老病死……

但方法终归不是目的，它只是我们实现目的的手段，手段的目的又是为了给使用者提供更有力的抓手（沟通、协作、管理）。

 

本文由 @Kris_3ᶻᶻᶻ 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于CCO协议