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

作者：张飞洪，来源：www.cnblogs.com/jackyfei/p/10078988.html

瀑布和敏捷不是什么新概念，这里只是个人在团队合作中不得不去思考而做的归纳和总结，同时记录自己曾经踩过的坑，新瓶装旧酒，希望对你有所启发。

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

敏捷模式

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

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

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

　　计划纸牌怎么怎么用的呢如A程序员开发一个功能，需要5个小时，B程序员认为只需要半小时，那他们各自取相应的牌，藏在手中，最后摊牌，如果时间差距很大，那么A和B就可以讨论A为什么要5个小时…

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

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

• 每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本，可以机制CI,CD工具进行辅助开发；

• 当一个故事完成，也就是最小目标被完成，这时，我们要进行演示会议，也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个开发成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）；

瀑布vs敏捷

　　为什么说共识很重要呢我踩过的坑进行盘点，有如下几个问题：

• 领导指挥不当：老板重文档，觉得必须有文档往下开发才是规范的，否则后面的工作都是一种浪费，因为你的顶头上司不一定懂技术，这样导致的结果是文档没出来前，底下人只能泡茶聊天了。

• 团队效率极低：因为瀑布强调分工，各自为战，所以有可能架构设计人员在等产品经理给需求文档，开发人员在等待架构设计文档，测试人员在等待开发成果，老板在等待产品交付。这里环环相扣，类似电流串联工作，一个环节出错，造成断电，导致交付延期，后果可能就是互相推诿和扯皮，严重的话可能会引发争吵，团队分崩离析。

归纳盘点

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

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

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

文章引用

• 敏捷开发之Scrum扫盲篇(以上部分图片摘录自该地址)

• 敏捷开发之Scrum扫盲篇 

• 百度百科 

• 敏捷开发 模型讲解

• 软件开发模式之敏捷开发

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览92729 人正在系统学习中

来源：架构师小秘圈