我对“瀑布”与“敏捷”的争辩

“敏捷”挑战

在今年，敏捷开发模式就如狂风一般，向我的耳中吹来，无论是公司的实际项目还是与客户进行的交流，都投入了很多的精力都投入在敏捷的转型上来。一时间，开发团队是否敏捷，敏捷的项目如何管理，敏捷项目中如何跟住变更，都成为了时常在讨论的话题。

Scrum实施方法，迭代会，站立会议，都在工作环节上面产生了很多的变化。Epic、Feature、UserStory，也变换了之前对业务需求、系统需求、功能点等的描述。最明显的感觉就是，这样敏捷的实施方式，对工作产生的变化是极大。

在敏捷看来，很多情况下面，我们都无法去了解到全部的内容，或者即使是了解到，我们也不能保证这些内容是不会变化的。所以先根据主路径，完成主要功能后，我们再通过不断地迭代，去完善我们的工作，这样当我们产生变化的时候，我们推翻的工作量也是少量的，可以很快的去完成新的需求变更。通过这样的不断地变更、重构，我们可以获得一个相对客户满意的产品。

在高举效率与拥抱变化的大旗之下，似乎敏捷模式，就是最好的开发模式。与之相比的是瀑布模式，在这样的呼喊之中，显得有些无法跟得上步伐，体现的是陈旧、死板的。

“瀑布”辩驳

对于瀑布的开发模型来看，似乎依然具备很可靠的工作逻辑，一个工程或项目分为多个阶段，每一个阶段都投入相应的资源，来完成本阶段的工作。每一个阶段到下一个阶段，都有明确的输入输出产物，不同的阶段根据自己所需的输入，进行工作活动之后，产生自己阶段的产出，投入到下一个阶段的工作中。如果不放心的话，每一个阶段还可以增加一个审批环节，让每一个环节都可以经过可靠的审批之后，再投入到下一个环节当中。

说到需求变更，瀑布也可以走需求变更，提变更申请，按照环节一步一步走，去规划这样的工作量，来完成需求变更不久可以了么？虽然比敏捷是要慢一些，但是我整个流程是可靠的！为什么就说瀑布是死板的，不符合时代的呢？

似乎瀑布的做法也没有错误，我们何不按照这样的步骤，来完成我们的工作呢？这样的过程听起来是如此的可靠。看，我有明确的阶段；看，我有明确的审批；看，我有明确的变更流程。

以瀑布模式进行开发的项目有这么多，已经证明了这是一个有效的实施方法，难道不是么？

焦点碰撞

而现在转变成敏捷模式之后，希望通过敏捷模式，两周一个迭代，每个迭代都能进行一定功能模块的交付，让用户更早的看到交付物，虽然只有部分，也可以让用户来提出自己的看法，产生变更的时候，开发人员也可以在下个迭代中进行修改，让用户进行再次的确认。

从这样看来，两者的碰撞就是在交付的及时性上与面对变更的成本上，所看到有极大的变化。瀑布在交付阶段比较靠后，交付的模块比较完整，在面对变更的时候，变更影响范围就比较大，变更的成本就极大。问题发现的阶段越靠后，解决问题所需要付出的成本就更高。这样，就体现出来了敏捷对瀑布在这样的情景下面的优势。

时间和成本，看起来就是敏捷和瀑布在选择时主要考虑的两个方面。

猜测本源

那么如果这两项作为基本因素的情况下，为什么敏捷比瀑布就有这样的优势呢？因为只在当前公司进行工作，所涉猎的范围也都是公司内部的传统IT项目，对于其他公司与互联网的项目，都是基于了解后的揣测。以下就是我的不负责任的猜想。

由于现阶段互联网的高速发展，互联网公司占据了大量IT资源，并且影响力极大。对于互联网公司，绝大部分与用户的接口只有它的互联网应用。并且公司很多时候都靠着一个“点子”成立，依赖投资，占据流量，在较长的时间内无法盈利。

对于这样的互联网公司，我认为具备很多敏捷实施环境。

首先，互联网公司最初都是从思考到落地的一个过程。由于并不能确认是否可以获得用户的支持，并且最初也无法实现盈利，并且产品容易被模仿，所以公司采用快速推出软件，来验证思路，如果验证思路是正确的，再不断加码进行投资，来维持公司的持续扩张。所以互联网公司发展快、烧钱、钱烧完了做不好倒的快，也是对互联网公司的清晰的印象，因为这是由于这些公司的模式决定的。快速验证用户想法，倒金字塔加码投资，是这些公司主动选择敏捷模式的原因。

再一个，只有一个应用，作为与用户连接的唯一渠道。互联网应用的巨大特点，就是可以实时的获取用户的反馈信息，用户实时在线，用户的操作过程、使用习惯、问题都可以实时获取。在极短的时间里面就可以获得用户访问量、使用情况等，都可以得到快速的验证。这样的条件下，如果经过一段时间的验证，各项指标并不能达到公司的预期，那么“干掉”这个项目，对公司来说也是一个很好的选择。这样的反馈速度也不是常规行业可以达到的。

所以，对于互联网公司，敏捷是一个很好的开发模式，它完全契合了公司的运营特点，使得敏捷在这种环境下，也极大的体现了它的价值。互联网现在对IT行业影响巨大，使得传统的IT公司，机构，也都希望像互联网企业那样，来提高交付效率，降低变更成本。

体系的进化还是两种方式

那么，是不是敏捷就是一种开发体系的进化？我认为并不是。

对于互联网产品，很多情况下都是对用户的偏好的一种探索，听到的最多的一个词，叫“痛点”。由于并不清楚用户的实际情况和偏好，自身的理解总是有一定偏差，所以通过敏捷的方法进行频繁的验证与变更，是很好的解决时间和成本问题的方法。

但是，如果验证成本并不像互联网产品一样，只是一个部署就可以解决的问题，而是需要花费很多的资源去进行验证，那么，去频繁确认最终结果，并不是一个优秀的方法。谁会没事放个火箭来验证自己对火箭的猜想是正确的？虽然只是一句玩笑话，但是在传统IT行业中，验证成本较大的时候，并不一定适合频繁交付。

再一个，对于研究型或者较为庞大的项目中，敏捷开发中的重构，对于这些项目，由于架构复杂，庞大，并不能达到快速与小成本来完成重构。就像很多医药的研制，都需要经过一层一层的实验，不断地深入验证，最终才能推向市场。这个过程中，每一个环节都不能少，明显在验证过程中，针对不断的阶段做决策是一个最良好的选择。

我从上面的思考当中，想到在如下的场景中，瀑布模式可能是一种更好的模式：工程目标明确，方法论与结构复杂，验证成本高。在这种条件下，瀑布模型可以更好的去控制成本，并且通过一个一个模型的模拟，来逐步达到工程的目标。

由此表述来说，可以看到，在我的眼中，将敏捷与瀑布作为两种方式来看，是我做出的一种判断。

合二为一

作为项目的决策者和实施者，把这“瀑布”与“敏捷”看作实施项目过程中的方法、手段，在合适的时候挑选合适的方法，可能是一个更好的选择。单纯的选择“敏捷”，与单纯的选择“瀑布”一样，都是一种偏执的做法。

芒格的一句话让我有很深的印象，“如果你手里拿着锤子,在你眼里满世界都是钉子”。不能拿着一种模式套用在所有的场景之下。这不是一个非黑即白的问题，而是哪一种模式可以解决我当前问题，我就选择哪一种模式，永远选择最优的解决方案。

并且，一个项目当中，并不是选择一种方案到底。根据项目的特点，在某一个阶段选择一种合适的办法，在其他的阶段选择另外一种方法，这也能体现出来项目管理的灵活。再进一步，甚至一个阶段当中，可以根据工作内容的不同，划分不同团队，使用不同的工作模式来共同完成项目。作为项目的管理者，如何能够使用这些开发方法，较好的达成项目目标，才是真正体现能力的地方。

这样，学习scrum这样的敏捷实施体系，对于一个项目管理者来说也是很有必要的一门功课，就如同多学会了一种工具，在处理很多的情况下，可以更加的得心应手。

回到最初

很多的人贡献出来的思路，想到的方法，解决了诸多工作中遇到的问题。我总是抱着一个想法，我遇到的绝大部分问题肯定很多人都遇到过，如果发现没有人讨论过这些问题，可能是我的问题过于简单，由于自己的失误造成的，亦或是自己的思路不对。只有极少的时候，能发现极特殊的问题。

去更多的学习他人的智慧成果，来解决自身的问题，去了解别人在什么样的环境下面，提出的这样的解决办法，可能会更加的游刃有余。

就像在之前面对项目的需求频繁变更时，通过老师的指点，学习了项目管理的思路方法，才发现自己遇到的问题是有这么多的解决办法，需要自己转变思路去使用这些方法。同样，我认为敏捷也是这样，在项目的过程中，学习这些方法，理解它的使用范围，在遇到适当的问题时，用这些方法去解决，就能收获最好的效果。