瀑布模型是比较传统一种开发模式，特别是在2B的传统企业，包括ERP，MES，WMS，CRM，OA，IBMS等系统当中可以经常见到他们的影子。现在这种模式仍然流行在一些大的项目或者是外包的一些项目当中。
-
阶段清晰。从计划到开发再到上线运行，三个阶段非常清晰。
-
时间顺序。每个阶段顺序必须是从上到下，严格按照时间先后进行。
-
环环相扣。在每一个阶段都必须有产出物然后才能进入到下一个阶段进行。
-
黑盒模式。每个阶段都有各自的角色和分工，各自只关心自己的任务。比如需求阶段开发人员无需关注。
-
需求隔离。由于各阶段的人员只能接触到自己工作范围内的东西，所以对客户需求的理解程度高低不等，开发人员更像是定义为流水线上的工人。
-
变更代价大。既然叫做瀑布，就意味着不应该走回头路。否则如果出现返工，付出的代价会很大。需求变更，编码人员会很强的抵触情绪。
-
束缚创造性。由于强调文档管理，所以管理人员会比较喜欢，但是他束缚了开发人员的创造性。
-
周期漫长。整个开发持续的生命周期很长，需求和设计的时间会耗费特别多，有时候会占用三分之一甚至更多时间，这样整个周期就会变长，大都在半年到一年左右的时间，所以更适合需求相对稳定的大项目。
归纳总结
根据以上分析，我们知道瀑布模式强调里程碑，重视文档，强调分工，避免变化，凡事喜欢规划和做计划，但是代价就是拖沓笨重，反应迟钝。
敏捷开发借助互联网浪潮开始流行起来，这也是2C的业务特点决定的，看过QQ和微信长大的人，这种体会特别深。互联网产品不可能一步规划到位，一般都是核心功能优先，比如微信，先是实现聊天功能，然后才是漂流瓶，钱包，小程序……
互联网业务有何特点呢？借用雷军的七字诀：专注、极致、口碑、快。
-
唯有专注才能聚焦能量，引爆燃点。
-
唯有极致才能排除竞争，争取用户。
-
金杯银杯不如口碑。
-
天下武功唯快不破。
敏捷无疑更加贴近互联网的这种业务需求，如果纯用瀑布模式，估计黄花菜都凉了。敏捷还有一个更极致的做法，直接上PPT通过类似众筹的方式进行开发，这种从群众中来到群众中去的个性化定制功能非常的有创意，如果众筹的结果是没有人感兴趣，就可以直接否定该产品开发，可以避免无谓的“库存”导致的开发压力，节省巨大的成本浪费。
Scrum的意思是橄榄球运动的一个专业术语，表示“争球”的动作。把一个开发流程的名字取名为一项体育运动，你一定能感受到其中的碰撞，冲突，激情。如果是这样，Scrum如何能提高开发效率呢？敏捷开发是一种指导思想，Scrum和XP则是敏捷开发的具体开发流程，这里只选择Scrum进行探讨。
我们先来看下Scrum的三个角色：
-
产品负责人：提供整体产品需求清单，确定产品边界，功能组合图谱，交付内容和日期。另外产品负责人有权拒绝开发团队的开发成果。
-
开发团队：因为追求快，开发人员需要很强的自我管理能力，需要主动反馈，主动沟通。
-
流程管理员：主要任务是疏通开发和业务的障碍，起到一个胶水的粘合作用，所以一旦开发进行，流程管理员有权拒绝需求的变更或修改。
Scrum是一个理想化的开发流程，前提条件是角色完整，分工明确，配合默契，沟通融洽。如果出现其中任何一个环节的故障，可能都会破坏流程的效率，比如，开发经理和流程管理员脾气一样倔强，脾气互斥，那么整个效率就打折扣。我感觉在招聘人员，团结组建的过程中，我们务必要寻找气味相投的人，这可以减少开发过程中的冲突。
Scrum和瀑布的本质区别是，一个以文档为本，一个以人为本。在以人为本的团队里，领导者的文化就是团队的文化。如果领导者不透明，喜欢玩虚假，自大，官僚气十足，这个团队基本上就没什么希望了。人必须是主人，有能动性，这个高度困难。因为如何让团队觉得公司的事是我家里的事是高度困难的，因为有些开发人员自己家的事都没怎么认真过。想要做到这点，需要老板重视，否则中层领导我感觉一般都心有余力不足。
-
首先需要确定一个产品需求列表，由产品负责人负责；
-
开发团队根据列表，做工作量的预估和安排；
-
有了产品需求列表，我们需要通过计划会来从中挑选出一个故事作为本次迭代完成的最小目标，这个目标的时间周期是1~4个星期，然后把这个故事进行细化，形成一个最小产品需求。比如该故事是登陆的功能故事，那么登陆的需求就要进行完整的细化工作；
-
开发成员根据故事再细化成更小的任务（细到每个任务的工作量在2天内能完成）；
计划纸牌怎么怎么用的呢？比如A程序员开发一个功能，需要5个小时，B程序员认为只需要半小时，那他们各自取相应的牌，藏在手中，最后摊牌，如果时间差距很大，那么A和B就可以讨论A为什么要5个小时...
开发过程需要设置每日站会，每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报三个问题：A.你昨天完成了什么；B今天要完成什么；C.什么问题不能解决。
每个人回答完成后，要走到黑板前更新自己的sprint燃尽图；
每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本，可以机制CI,CD工具进行辅助开发；
当一个故事完成，也就是最小目标被完成，这时，我们要进行演示会议，也称为评审会议，产品负责人和客户都要参加（建议本公司老板也参加），每一个开发成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）；
然后就是回顾会议，也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮sprint的产品需求中；
大家如果认真的看完整个Scrum的开发流程，会发现这个过程还真的是很完美，不妨可以用在你的团队开发过程中。
瀑布敏捷是有边界的，我觉得团队在整体学习开发模式优劣后，需要对二者的边界有一个清晰的认识，并在整个团队上下都要达成一致的共识，否则后果可能会很严重。双方的边界如下图所示:
为什么说共识很重要呢？就我踩过的坑进行盘点，有如下几个问题：
-
领导指挥不当：老板重文档，觉得必须有文档往下开发才是规范的，否则后面的工作都是一种浪费，因为你的顶头上司不一定懂技术，这样导致的结果是文档没出来前，底下人只能泡茶聊天了。
-
团队效率极低：因为瀑布强调分工，各自为战，所以有可能架构设计人员在等产品经理给需求文档，开发人员在等待架构设计文档，测试人员在等待开发成果，老板在等待产品交付。这里环环相扣，类似电流串联工作，一个环节出错，造成断电，导致交付延期，后果可能就是互相推诿和扯皮，严重的话可能会引发争吵，团队分崩离析。
就个人的经验来看，瀑布和敏捷不是天然分割的，只是针对业务各有侧重，应该是你中有我，我中有你的混合体。比如微信首版的时候，聊天核心功能的迭代一定也有内部的小瀑布，如果没有计划-开发-测试-运维根本就无法进行下去。再比如瀑布，特别对创业团队，刚开始人手不多，分工不明，架构师有可能要去画原型图，做需求调研；产品经理业务模糊，还在探索，各种短板和不足就像黑洞一样存在你的周边，你浑然无知。如果你一定要等整个调研完成，PRD文档周全再做开发，估计也要歇菜。
既然各有利弊，那么中间的这个平衡点如何拿捏就非常重要，如何在前期设计的时候既能不过渡导致交付延迟，又能兼顾后续的演进和变化导致的修改可控，这需要开发经理丰富的实战历练和审时度势的判断力。
另外叨叨一下，开发模式贯穿做整个开发的生命周期，但是团队各个成员包括产品经理，技术经理，架构师，开发人员对项目管理的流程理解各不相同，深浅不一，很难想象如果大家没有达成共识，整个开发团队的效率会有多高？但是现实当中，大部分团队成员没有开发模式的培训和上下达成一致依然在进行着开发的工作…
