敏捷开发就一定优于瀑布式开发吗？我反对 | IDCF FDCC认证学员作品
最近参与了多轮敏捷开发的讨论，虽说道理越辩越明，可我本人却陷入了关于一个本质问题的思考和自我辩论，那就是：敏捷开发就一定优于瀑布式开发吗？
先从命名说起，“敏捷开发”的名字起得真是太鸡贼了。敏捷的反义词是笨拙、迟缓。于是很多人都会把和“敏捷开发”做对比的“瀑布式开发”说成是笨拙、迟缓的开发方式。
我个人觉得此种说法非常欠妥。更符合实际的情况是：敏捷开发是敏捷的，瀑布式开发是稳重的。
我们尝试回归到敏捷开发的本心，也就是2001年在犹他州的雪鸟城那个滑雪胜地，一群具有反叛性的软件开发人员聚集在一起，制定并签署了行业历史上最重要的文件之一：敏捷宣言。
在敏捷看来，很多情况下，我们都无法了解到全部的内容，或者即使是了解到，我们也不能保证这些内容是不会变化的。所以先根据主路径，完成主要功能后，我们再通过不断地迭代，去完善我们的工作，这样当我们产生变化的时候，我们推翻的工作量也是少量的，可以很快地去完成新的需求变更。通过这样的不断地变更、重构，我们可以获得一个相对客户满意的产品。
随着互联网的普及，涌现出越来越多面向个人用户的产品。这类产品的需求总是在不断增加和变化的，产品不得不拥抱变化，而敏捷开发更适用此类产品。因此我们总是强调敏捷开发，强调精益产品。
在这个高速发展的时代，客户的需求日新月异的变化，很多软件的开发确实会面临着一边开发一边过时的问题，为了解决这个问题，敏捷开发是没有错的。
但是，这并不代表所有面向敏捷的转型都是有正面意义的。
第一个问题，是不是所有的软件开发需求都是会发生变化的？
一些面向政府或者大型机构的产品，往往有其业务逻辑支撑，需求固化（组织也相对抵触新的风险）。这种类型的项目往往需要前期花大量时间进行设计，以便对其现有业务进行匹配。
就像航空航天工业汽车军事领域的开发，都是用CMM流程，因为这些领域的需求是不会变的，目标参数都摆在那里，你不需要频繁地开发出版本去问客户这个是不是你想要的。在这种项目中，如果你频繁的去确认什么是客户想要的，可能直接就被开掉了。
而通常这种需求固定的项目，其组织对预期（时间）也会有强烈的要求，瀑布式开发更容易把控进度。
瀑布的开发模型具有更可靠的工作逻辑，一个工程或项目分为多个阶段，每一个阶段都投入相应的资源，来完成本阶段的工作。
每一个阶段到下一个阶段，都有明确的输入输出产物，不同的阶段根据自己所需的输入，进行工作活动之后，产生自己阶段的产出，投入到下一个阶段的工作中。如果不放心的话，每一个阶段还可以增加一个审批环节，让每一个环节都可以经过可靠的审批之后，再投入到下一个环节当中。
首先，在敏捷众多成功的案例中，鲜有提到敏捷可以缩短开发周期的。而更多对于敏捷开发的诟病在于，如果组织中不是从上至下完全接受敏捷的概念，并将其思想彻底应用于开发中，敏捷开发的时间可能会比瀑布开发的时间还要长。
再来，说敏捷可以频繁测试的。可是这和敏捷有什么关系呢？
测试前移、测试驱动开发（TDD）、自动化测试这些概念是在软件开发中越来越重视测试后，整个测试工作的技术变革。
换句话说，没有敏捷，一样可以使用先进的测试方法频繁的对软件进行测试。
只要拥有足够的测试人员，瀑布的开发也是完成一个小模块，就对一个小模块进行测试的。难道瀑布式开发的项目中，项目经理会让测试人员闲着等待整个软件开发完再测试吗？这真是人为的把瀑布污名化。
搭建了支持CICD的系统和平台，使用先进的部署和测试方式，瀑布式开发一样可以尽早的发现BUG，尽可能避免项目后期发现BUG造成的难以想象的工作量。
所以，我们是完全可以通过使用工具提升瀑布开发的灵活性的。
2001年，敏捷宣言诞生，给出的是一种软件开发上的价值观，它是一套与产品开发相关的原则和价值，而并不是“方法论”。
而后人根据经验总结得出了“Scrum”、“SAFe”等实践。
可是，当要求所有的项目团队必须按照一定的节奏、一定的sprint长度进行迭代和交付的时候，这种毫无灵活性的要求真的能达到敏捷的效果吗？
大家可以围观知乎的一个特别搞笑的问题：
什么是「中华田园敏捷开发」？
这个问题现在有90多个回答，高赞的几个回答简直笑破肚皮。
我在这里并没有diss敏捷开发的意思，相反，我觉得应对变化的需求这是一种非常合理的开发方式。可是当应用者不考虑实际情况，不探索适合自己的路，为了敏捷而敏捷之后，就变成了所谓的中华田园敏捷开发，也就是伪敏捷。
-
有些公司的软件，需求固定，直到项目交付前客户都不会参与Demo（2B的软件这种不在少数）。非得严格的两周一个迭代，你迭代出来的东西要给谁看？你逼着开发人员非得把2.5周的模块开发拆的七零八落，给客户获得了什么价值？
-
现阶段，有经验的PO/PM太欠缺。PO/PM成了客户的传声筒，客户说什么就直接复述给团队，不会和客户谈判，不会引导客户的需求。宇宙第一产品经理乔大爷说过，客户并不知道自己想要什么。传声筒的PO/PM，会造成瀑布项目的重复开发，一样会造成敏捷项目的重复开发。这是人员能力的问题，和采用什么样子的开发方式真的无关。于是乎，敏捷的满足客户需求的愿望没有达到，但是敏捷的返工倒是发生了。
第四，敏捷转型为什么这么难？为什么很多公司在敏捷转型中要么不了了之要么走向了中华田园敏捷？
首先，思想的转变是最难的，特别是要求整个团队进行思想的统一和改变。
尤其是团队中的领导者一定要从自身开始要求，充分理解敏捷开发的思想，能够准确的判断到底什么情况下应用敏捷会获利，什么情况下应用敏捷和瀑布其实效果相差不大，又或什么情况下直接用瀑布就好了。
而伪敏捷往往发生在这种情况下，领导者听别人说敏捷好，就直接拍板，我们用敏捷吧！Project Manager来做Scrum Master，Product Manager来做PO，不要team leader了，我们要自组织自学习.........
敏捷的转型不是把一个一个的角色进行对应之后就行了的，必须要从理念上让这些角色清楚，转型前和转型后自己的职责发生了什么变化，为什么会发生这些变化，以及发生这些变化会带来哪些好处。形势上的转型很容易，思想上的转型才最难实现。
另外，还想补充一点，从团队的角度来进行分析，敏捷开发强调直接沟通，如果在团队人数众多，以及人员变动的情况下，就要花费许多时间使团队达成一致。
因此敏捷开发更适合稳定的，以及容易达成共识的团队。而人员变动频繁，则适合瀑布流开发中强调的文档及管理工具方法。
最后，还是想说，我不反对敏捷以及敏捷转型，在某些项目中我自己也会蠢蠢欲动的想要尝试这种新的开发方式。但是我始终不同意敏捷开发全方位吊打瀑布开发的这种说法。
在实际的软件开发项目中，我们不应该纠结在我们用不用敏捷开发。我们应该关心的是这个项目应该用哪个开发方式更合理，更能带来好处。
敏捷开发适合那些需求不明确的需求，如果需求明确，就像航空航天工业汽车军事领域的开发，就用瀑布开发。
而在实施中，我们要专注于怎么通过使用一些先进的技术和平台，使我们的代码质量更高、部署更容易、测试更全面。这些不管是瀑布项目还是敏捷项目都是适用的。
敏捷当然存在缺陷，瀑布也存在缺陷，问题的关键不在于缺陷，而在于你需要什么。不要为了敏捷而敏捷，低头快跑会导致忘了抬头看路，我们的初衷是交付更好的软件，勿忘！
所以我们只能是在该敏捷的时候敏捷，该瀑布的时候瀑布。
IDCF DevOps黑客马拉松2020年再度开跑，北京、深圳、西安、上海四城报名通道已经开启！打造端到端的DevOps教练，快扫码报名加入吧~
标签:
