关注+星标公众号，不错过精彩内容
瀑布模式
瀑布模型是比较传统一种开发模式，特别是在2B的传统企业，包括ERP，MES，WMS，CRM，OA，IBMS等系统当中可以经常见到他们的影子。
现在这种模式仍然流行在一些大的项目或者是外包的一些项目当中。
如上图所示，瀑布模型优缺点都很突出。
根据以上分析，我们知道瀑布模式强调里程碑，重视文档，强调分工，避免变化，凡事喜欢规划和做计划，但是代价就是拖沓笨重，反应迟钝。
敏捷开发借助互联网浪潮开始流行起来，这也是2C的业务特点决定的，看过QQ和微信长大的人，这种体会特别深。互联网产品不可能一步规划到位，一般都是核心功能优先，比如微信，先是实现聊天功能，然后才是漂流瓶，钱包，小程序……
互联网业务有何特点呢？借用雷军的七字诀：专注、极致、口碑、快。
敏捷无疑更加贴近互联网的这种业务需求，如果纯用瀑布模式，估计黄花菜都凉了。
敏捷还有一个更极致的做法，直接上PPT通过类似众筹的方式进行开发，这种从群众中来到群众中去的个性化定制功能非常的有创意，如果众筹的结果是没有人感兴趣，就可以直接否定该产品开发，可以避免无谓的“库存”导致的开发压力，节省巨大的成本浪费。
Scrum的意思是橄榄球运动的一个专业术语，表示“争球”的动作。把一个开发流程的名字取名为一项体育运动，你一定能感受到其中的碰撞，冲突，激情。如果是这样，Scrum如何能提高开发效率呢？
敏捷开发是一种指导思想，Scrum和XP则是敏捷开发的具体开发流程，这里只选择Scrum进行探讨。
我们先来看下Scrum的三个角色：
Scrum是一个理想化的开发流程，前提条件是角色完整，分工明确，配合默契，沟通融洽。如果出现其中任何一个环节的故障，可能都会破坏流程的效率，比如，开发经理和流程管理员脾气一样倔强，脾气互斥，那么整个效率就打折扣。我感觉在招聘人员，团结组建的过程中，我们务必要寻找气味相投的人，这可以减少开发过程中的冲突。
Scrum和瀑布的本质区别是，一个以文档为本，一个以人为本。在以人为本的团队里，领导者的文化就是团队的文化。
如果领导者不透明，喜欢玩虚假，自大，官僚气十足，这个团队基本上就没什么希望了。人必须是主人，有能动性，这个高度困难。因为如何让团队觉得公司的事是我家里的事是高度困难的，因为有些开发人员自己家的事都没怎么认真过。想要做到这点，需要老板重视，否则中层领导我感觉一般都心有余力不足。
计划纸牌怎么怎么用的呢？比如A程序员开发一个功能，需要5个小时，B程序员认为只需要半小时，那他们各自取相应的牌，藏在手中，最后摊牌，如果时间差距很大，那么A和B就可以讨论A为什么要5个小时...
每个人回答完成后，要走到黑板前更新自己的sprint燃尽图；
大家如果认真的看完整个Scrum的开发流程，会发现这个过程还真的是很完美，不妨可以用在你的团队开发过程中。
瀑布敏捷是有边界的，我觉得团队在整体学习开发模式优劣后，需要对二者的边界有一个清晰的认识，并在整个团队上下都要达成一致的共识，否则后果可能会很严重。双方的边界如下图所示
为什么说共识很重要呢？就我踩过的坑进行盘点，有如下几个问题：
就个人的经验来看，瀑布和敏捷不是天然分割的，只是针对业务各有侧重，应该是你中有我，我中有你的混合体。比如微信第一版的时候，聊天核心功能的迭代一定也有内部的小瀑布，如果没有计划-开发-测试-运维根本就无法进行下去。
再比如瀑布，特别对创业团队，刚开始人手不多，分工不明，架构师有可能要去画原型图，做需求调研；产品经理业务模糊，还在探索，各种短板和不足就像黑洞一样存在你的周边，你浑然无知。如果你一定要等整个调研完成，PRD文档周全再做开发，估计也要歇菜。
既然各有利弊，那么中间的这个平衡点如何拿捏就非常重要，如何在前期设计的时候既能不过渡导致交付延迟，又能兼顾后续的演进和变化导致的修改可控，这需要开发经理丰富的实战历练和审时度势的判断力。
另外叨叨一下，开发模式贯穿做整个开发的生命周期，但是团队各个成员包括产品经理，技术经理，架构师，开发人员对项目管理的流程理解各不相同，深浅不一，很难想象如果大家没有达成共识，整个开发团队的效率会有多高？但是现实当中，大部分团队成员没有开发模式的培训和上下达成一致依然在进行着开发的工作……
转自: https://www.cnblogs.com/jackyfei/p/10078988.html
