作者：张飞洪，来源：www.cnblogs.com/jackyfei/p/10078988.html
瀑布和敏捷不是什么新概念，这里只是个人在团队合作中不得不去思考而做的归纳和总结，同时记录自己曾经踩过的坑，新瓶装旧酒，希望对你有所启发。
瀑布模式
优点明显：
阶段清晰。从计划到开发最后到上线运行，三个阶段非常清晰。 时间顺序。每个阶段顺序必须是从上到下，严格按照时间先后进行。 环环相扣。在每一个阶段都必须有产出物然后才能进入到下一个阶段进行。 黑盒模式。每个阶段都有各自的角色和分工，各自只关心自己的任务。比如需求阶段开发人员无需关注。
缺点突出：
需求隔离。由于各阶段的人员只能接触到自己工作范围内的东西，所以对客户需求的理解程度高低不等，开发人员更像是定义为流水线上的工人。 变更代价大。既然叫做瀑布，就意味着不应该走回头路。否则如果出现返工，付出的代价会很大。需求变更，编码人员会很强的抵触情绪。 束缚创造性。由于强调文档管理，所以管理人员会比较喜欢，但是他束缚了开发人员的创造性。 周期漫长。整个开发持续的生命周期很长，需求和设计的时间会耗费特别多，有时候会占用三分之一甚至更多时间，这样整个周期就会变长，大都在半年到一年左右的时间，所以更适合需求相对稳定的大项目。
归纳总结
敏捷模式
发展背景
唯有专注才能聚焦能量，引爆燃点。 唯有极致才能排除竞争，争取用户。 金杯银杯不如口碑。 天下武功唯快不破。
Scrum是什么
产品负责人：提供整体产品需求清单，确定产品边界，功能组合图谱，交付内容和日期。另外产品负责人有权拒绝开发团队的开发成果。 开发团队：因为追求快，开发人员需要很强的自我管理能力，需要主动反馈，主动沟通。 流程管理员：主要任务是疏通开发和业务的障碍，起到一个胶水的粘合作用，所以一旦开发进行，流程管理员有权拒绝需求的变更或修改。
Scrum流程图
首先需要确定一个产品需求列表，由产品负责人负责；
开发团队根据列表，做工作量的预估和安排； 有了产品需求列表，我们需要通过计划会来从中挑选出一个故事作为本次迭代完成的最小目标，这个目标的时间周期是1~4个星期，然后把这个故事进行细化，形成一个最小产品需求。比如该故事是登陆的功能故事，那么登陆的需求就要进行完整的细化工作； 开发成员根据故事再细化成更小的任务（细到每个任务的工作量在2天内能完成）；
开发过程需要设置每日站会，每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报三个问题：A.你昨天完成了什么；B今天要完成什么；C.什么问题不能解决。
每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本，可以机制CI,CD工具进行辅助开发； 当一个故事完成，也就是最小目标被完成，这时，我们要进行演示会议，也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个开发成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）；
最后就是回顾会议，也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮sprint的产品需求中；
瀑布vs敏捷
对比一览图
领导指挥不当：老板重文档，觉得必须有文档往下开发才是规范的，否则后面的工作都是一种浪费，因为你的顶头上司不一定懂技术，这样导致的结果是文档没出来前，底下人只能泡茶聊天了。 团队效率极低：因为瀑布强调分工，各自为战，所以有可能架构设计人员在等产品经理给需求文档，开发人员在等待架构设计文档，测试人员在等待开发成果，老板在等待产品交付。这里环环相扣，类似电流串联工作，一个环节出错，造成断电，导致交付延期，后果可能就是互相推诿和扯皮，严重的话可能会引发争吵，团队分崩离析。
归纳盘点
文章引用
敏捷开发之Scrum扫盲篇(以上部分图片摘录自该地址)
敏捷开发之Scrum扫盲篇
百度百科
敏捷开发 模型讲解
软件开发模式之敏捷开发
