我也来聊聊传说中的敏捷和小瀑布

本文大约1567字，阅读约需5分钟。

关于敏捷和小瀑布的讨论由来已久，有人说它们相爱相杀，有人表示相当滴困惑！听起来还真有点儿复杂呢！来，看看我的观点……

可以明确的是，无论敏捷还是小瀑布，对于软件研发来说，共同点都是一定要遵循需求、设计、开发、测试等这样的顺序。那么它们的区别在哪呢？别着急，我们先从大瀑布说起！

大瀑布中，我们在上线前的范围是圈定的，固定的，把所有功能都开发完了，再进入一个专门的测试阶段。测试老司机都是大心脏，基本开发没有不延期的，而上线的时间点又不能变，导致测试的时间大幅压缩，而测试阶段又是Bug集中爆发期，在此期间，开发和测试来来回回，反反复复，时间根本hold不住，为了能够按时上线，就只能牺牲质量，差不多就上！为啥人们会做出这样的决定？因为通常延期很难看，而质量差，只要对外人来说暂时并不致命，很容易蒙混过关。

这样上线后很大比例时间都在修bug，以致团队开发新功能的时间受到很大影响。有意思的是，很多人并没有意识到这是个大问题，因为这么多年都是这么过来的，实在是司空见惯。

如此尴尬的局面，怎么破？

为了保证有充足的开发和测试时间，聪明的攻城狮想出来一个办法，那就是在承诺的时候加一大堆的缓冲时间，还要祈祷中间不要临时插活！但是如你一般有经验的攻城狮知道，不插活几乎不可能！即使是没有活插进来，那么加一大堆缓冲时间就能解决问题吗？

有一种现象就叫做学生综合征，就是你给他多长时间，他就能给你耗多长时间！开发人员一看，我这么多缓冲时间，先悠闲一下，过过好日子，过段时间加把劲儿，完全不是事儿！结果呢，他在后半段以为自己能做完，哪想到事情远不如想象中那么简单，要花很长时间才能搞定，还是不能按期做完！这个缓冲就这样被他浪费掉了！

所以，传统的这种固定时间，又固定范围的开发方式，到头来不是牺牲质量，就是牺牲工期！

还有一个问题是，在集中的测试阶段发现的Bug，离编写相应代码的时间比较长，程序员需要花更长的时间来回忆当时的编程思路，导致改Bug时间变长了，从而延长了软件的开发周期！非常不划算！

我们迭代啊！双周上线啊！不过这个时候你需要看看了，这每个迭代里面是不是有明显的开发阶段和测试阶段，比如两周迭代中，第二周专门做测试，或者最后三天专门做测试，其余时间都是开发！如果是这样，那么在这个迭代中跑的仍然是瀑布！它仍然具有瀑布的一切特点和问题！只不过这种情况它的影响范围和灾难没有前面的大瀑布那么剧烈。我们因此管这个叫小瀑布。

啊？原来是小瀑布啊！

毫无疑问，小瀑布的方式确实比大瀑布更加敏捷了，因为有了优先级之分了，上一个迭代中工作的优先级比下一个迭代的优先级高，而且能够分拨上线了，更高价值的软件能够更早交付给客户了，我们能够更早收到客户的反馈了，然后可以及时调整我们的产品！注意，即使如此，在一个迭代两周的时间区间内，瀑布固有的问题仍然没有得到解决！

诀窍就是，在质量不投降的前提下，让范围可变，才能解决这个问题！这就是敏捷的倒三角！这也是敏捷的精髓之一，这是敏捷里面解决相当大量问题的法宝！

为什么在敏捷中，范围变化是可以接受的呢？因为1）需求拆分的很细；2）每一小块还能够独立上线；3）按照优先级排序。这样，即使计划的10个故事，我在上线前做完了9个，剩下的一个如果不上，我也能为用户交付价值，而且是用户最在乎的那9个！而不像瀑布一样，一块不上都不行。这就是敏捷里面范围可变的根本原因！

所以大家看到了，敏捷玩转的根本就是需求的拆分！拆好了，一马平川！拆不好，万恶之源！所以为什么我们在辅导的时候，需求的梳理要花大量的时间！就在这里！PO为啥要专职。为啥责任重大！原因在于此！

那么，什么叫拆的细？细和不细都是相对的！相对于原来几个月的需求，我现在拆成2周能干完的，这叫细，但是你两周的迭代，你拆成8天能干完的，这叫瀑布！

所以，通常对于两周的迭代，我们要求拆成3天的故事，这三天包括开发，测试和验收，达到上线标准！只有这样，才能有敏捷的效果！如果实在不行，5 天也不得不忍，再长就没法忍了！

综上所述，敏捷都是相对的，没有一个红线，在红线的左边是非敏捷，在红线的右边就是敏捷。我们能做的就是让我们的工作变得更敏捷。敏捷是一个方向，不是一个目的地！