软件开发模式：瀑布与敏捷

瀑布和敏捷不是什么新概念，这里只是我的在团队合做中不得不去思考而作的概括和总结，同时记录本身曾经踩过的坑，新瓶装旧酒，但愿对你有所启发。

瀑布模式

　　瀑布模型是比较传统一种开发模式，特别是在2B的传统企业，包括ERP，MES，WMS，CRM，OA，IBMS等系统当中能够常常见到他们的影子。如今这种模式仍然流行在一些大的项目或者是外包的一些项目当中。

 　　

如上图所示，瀑布模型优缺点都很突出。

优势明显：

• 阶段清晰。从计划到开发最后到上线运行，三个阶段很是清晰。
• 时间顺序。每一个阶段顺序必须是从上到下，严格按照时间前后进行。
• 环环相扣。在每个阶段都必须有产出物而后才能进入到下一个阶段进行。
• 黑盒模式。每一个阶段都有各自的角色和分工，各自只关心本身的任务。好比需求阶段开发人员无需关注。

缺点突出：

• 需求隔离。因为各阶段的人员只能接触到本身工做范围内的东西，因此对客户需求的理解程度高低不等，开发人员更像是定义为流水线上的工人。
• 变动代价大。既然叫作瀑布，就意味着不该该走回头路。不然若是出现返工，付出的代价会很大。需求变动，编码人员会很强的抵触情绪。
• 束缚创造性。因为强调文档管理，因此管理人员会比较喜欢，可是他束缚了开发人员的创造性。
• 周期漫长。整个开发持续的生命周期很长，需求和设计的时间会耗费特别多，有时候会占用三分之一甚至更多时间，这样整个周期就会变长，大都在半年到一年左右的时间，因此更适合需求相对稳定的大项目。

概括总结

　　根据以上分析，咱们知道瀑布模式强调里程碑，重视文档，强调分工，避免变化，凡事喜欢规划和作计划，可是代价就是拖沓笨重，反应迟钝。

敏捷模式

发展背景

　　敏捷开发借助互联网浪潮开始流行起来，这也是2C的业务特色决定的，看过QQ和微信长大的人，这种体会特别深。互联网产品不可能一步规划到位，通常都是核心功能优先，好比微信，先是实现聊天功能，而后才是漂流瓶，钱包，小程序……

互联网业务有何特色呢？借用雷军的七字诀：专一、极致、口碑、快。

• 惟有专一才能聚焦能量，引爆燃点。
• 惟有极致才能排除竞争，争取用户。
• 金杯银杯不如口碑。
• 天下武功惟快不破。

　　敏捷无疑更加贴近互联网的这种业务需求，若是纯用瀑布模式，估计黄花菜都凉了。敏捷还有一个更极致的作法，直接上PPT经过相似众筹的方式进行开发，这种从群众中来到群众中去的个性化定制功能很是的有创意，若是众筹的结果是没有人感兴趣，就能够直接否认该产品开发，能够避免无谓的“库存”致使的开发压力，节省巨大的成本浪费。

Scrum是什么

　　

　　Scrum的意思是橄榄球运动的一个专业术语，表示“争球”的动做。把一个开发流程的名字取名为一项体育运动，你必定能感觉到其中的碰撞，冲突，激情。若是是这样，Scrum如何能提升开发效率呢？敏捷开发是一种指导思想，Scrum和XP则是敏捷开发的具体开发流程，这里只选择Scrum进行探讨。

　　咱们先来看下Scrum的三个角色：

 　　

• 产品负责人：提供总体产品需求清单，肯定产品边界，功能组合图谱，交付内容和日期。另外产品负责人有权拒绝开发团队的开发成果。
• 开发团队：由于追求快，开发人员须要很强的自我管理能力，须要主动反馈，主动沟通。
• 流程管理员：主要任务是疏通开发和业务的障碍，起到一个胶水的粘合做用，因此一旦开发进行，流程管理员有权拒绝需求的变动或修改。

　　Scrum是一个理想化的开发流程，前提条件是角色完整，分工明确，配合默契，沟通融洽。若是出现其中任何一个环节的故障，可能都会破坏流程的效率，好比，开发经理和流程管理员脾气同样倔强，脾气互斥，那么整个效率就打折扣。我感受在招聘人员，团结组建的过程当中，咱们务必要寻找气味相投的人，这能够减小开发过程当中的冲突。

　　Scrum和瀑布的本质区别是，一个以文档为本，一个以人为本。在以人为本的团队里，领导者的文化就是团队的文化。若是领导者不透明，喜欢玩虚假，自大，官僚气十足，这个团队基本上就没什么但愿了。人必须是主人，有能动性，这个高度困难。由于如何让团队以为公司的事是我家里的事是高度困难的，由于有些开发人员本身家的事都没怎么认真过。想要作到这点，须要老板重视，不然中层领导我感受通常都心有余力不足。

Scrum流程图

　　 

• 首先须要肯定一个产品需求列表，由产品负责人负责；

　　

• 开发团队根据列表，作工做量的预估和安排；
• 有了产品需求列表，咱们须要经过计划会来从中挑选出一个故事做为本次迭代完成的最小目标，这个目标的时间周期是1~4个星期，而后把这个故事进行细化，造成一个最小产品需求。好比该故事是登录的功能故事，那么登录的需求就要进行完整的细化工做；
• 开发成员根据故事再细化成更小的任务（细到每一个任务的工做量在2天内能完成）；

 　　

　　计划纸牌怎么怎么用的呢？好比A程序员开发一个功能，须要5个小时，B程序员认为只须要半小时，那他们各自取相应的牌，藏在手中，最后摊牌，若是时间差距很大，那么A和B就能够讨论A为何要5个小时...

• 开发过程须要设置每日站会，每次会议控制在15分钟左右，每一个人都必须发言，而且要向全部成员当面汇报三个问题：A.你昨天完成了什么；B今天要完成什么；C.什么问题不能解决。

　　每一个人回答完成后，要走到黑板前更新本身的sprint燃尽图；

 　　

　　

• 每日集成，也就是天天都要有一个能够成功编译、而且能够演示的版本，能够机制CI,CD工具进行辅助开发；
• 当一个故事完成，也就是最小目标被完成，这时，咱们要进行演示会议，也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每个开发成员都要向他们演示本身完成的软件产品（这个会议很是重要，必定不能取消）；

　　

• 最后就是回顾会议，也称为总结会议，以轮流发言方式进行，每一个人都要发言，总结并讨论改进的地方，放入下一轮sprint的产品需求中；

　　你们若是认真的看完整个Scrum的开发流程，会发现这个过程还真的是很完美，不妨能够用在你的团队开发过程当中。

瀑布vs敏捷

对比一览图

　　瀑布敏捷是有边界的，我以为团队在总体学习开发模式优劣后，须要对两者的边界有一个清晰的认识，并在整个团队上下都要达成一致的共识，不然后果可能会很严重。双方的边界以下图所示

　　

　　为何说共识很重要呢？就我踩过的坑进行盘点，有以下几个问题：

• 领导指挥不当：老板重文档，以为必须有文档往下开发才是规范的，不然后面的工做都是一种浪费，由于你的顶头上司不必定懂技术，这样致使的结果是文档没出来前，底下人只能泡茶聊天了。
• 团队效率极低：由于瀑布强调分工，各自为战，因此有可能架构设计人员在等产品经理给需求文档，开发人员在等待架构设计文档，测试人员在等待开发成果，老板在等待产品交付。这里环环相扣，相似电流串联工做，一个环节出错，形成断电，致使交付延期，后果可能就是互相推诿和扯皮，严重的话可能会引起争吵，团队分崩离析。

概括盘点

　　就我的的经验来看，瀑布和敏捷不是自然分割的，只是针对业务各有侧重，应该是你中有我，我中有你的混合体。好比微信初版的时候，聊天核心功能的迭代必定也有内部的小瀑布，若是没有计划-开发-测试-运维根本就没法进行下去。再好比瀑布，特别对创业团队，刚开始人手很少，分工不明，架构师有可能要去画原型图，作需求调研；产品经理业务模糊，还在探索，各类短板和不足就像黑洞同样存在你的周边，你浑然无知。若是你必定要等整个调研完成，PRD文档周全再作开发，估计也要歇菜。

　　既然各有利弊，那么中间的这个平衡点如何拿捏就很是重要，如何在前期设计的时候既能不过渡致使交付延迟，又能兼顾后续的演进和变化致使的修改可控，这须要开发经理丰富的实战历练和审时度势的判断力。

　　另外叨叨一下，开发模式贯穿作整个开发的生命周期，可是团队各个成员包括产品经理，技术经理，架构师，开发人员对项目管理的流程理解各不相同，深浅不一，很难想象若是你们没有达成共识，整个开发团队的效率会有多高？可是现实当中，大部分团队成员没有开发模式的培训和上下达成一致依然在进行着开发的工做……

文章引用

• 敏捷开发之Scrum扫盲篇(以上部分图片摘录自该地址)
• 敏捷开发之Scrum扫盲篇 
• 百度百科 
• 敏捷开发 模型讲解
• 软件开发模式之敏捷开发