什么是敏捷开发？
敏捷开发的实现主要包括Scrum与XP（极限编程，ExtremeProgramming），还有其他的一些方式。
（Scrum：橄榄球的并列争球，橄榄球并列争球的全体前锋，相互拥挤的人群）
Scrum是迭代式增量软件开发过程。
同样是敏捷开发，XP极限编程更侧重于实践，并力求把实践做到极限，实践可以是测试先行，也可以是结对变成，关键要看具体的应用场景。
SCRUM则是一种开发流程框架，也可以说是一种套路。SCRUM框架中包含了三个角色，三个工件，四个仪式。其目的是为了有效完成每一次迭代周期的工作。SCRUM是一个重点。
什么是SCRUM？SCRUM是一个适用于增量式产品开发的管理框架，由一个5-10人左右的跨职能和自组织的团队组成。
它提供了一个包含角色、规则和工件的结构。团队负责在此框架范围内创建和调整他们的流程。
几个基本术语：冲刺周期（Sprint）
中文译为冲刺、短跑，是Scrum的专有术语。冲刺周期，通俗的讲就是实现一个“小目标”的周期。一般需要2-6周时间。
用户故事（User Story）
用户的外在业务需求。拿银行系统来举例的话，一个Story可以是用户的存款行为，或者是查询余额等等。也就是所谓的小目标本身。
开发任务（Task）
由故事拆分成的具体开发任务。
三大角色产品负责人（Product Owner）
主要负责确定产品的功能和达到要求的标准，制定软件的发布日期和交付的内容，同时有权利接收或拒绝开发团队的工作成功。
流程管理员（Scrum Master）
主要负责整个Scrum流程再项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。
开发团队（Scrum Team）
主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5-10人左右，每个成员可能负责不同的技术方面，但要求每个成员必须要有很强的自我管理能力。同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。
三个工件产品需求列表（Product Backlog）：产品首先将需求按照优先级进行排列，产生一个Product Backlog。作用类似于传统开发中项目经理确定需求文档。产品待办列表就是产品的“what”。PO（产品负责人）通过讲故事的方式，让团队理解产品的目标，帮助整个团队对用户故事有充分和统一的理解。
迭代需求列表（Sprint Backlog）：有了Product Backlog，我们需要通过Sprint Planning Meeting（Sprint计划会议）挑选出用户故事（Story）作为每次迭代完成的目标。
冲刺燃尽图（Sprint burn down）：它表示的是剩余工作量与剩余时间的关系，用于提醒大家项目进度和要完成的任务。说白了就是记录当前周期的需求完成情况。
四个仪式Sprint计划会（Sprint Planning Meeting）：在每个Sprint开始时召开，由全体人员参加。这个会议主要有两件事情要确定。①确定当前Sprint的目标 ②选定当前Sprint要处理的最具价值的用户故事，创建Sprint Backlog（需求列表）
每日站会（Daily Scrum Meeting）：一般在15分钟以内。团队成员相互交流任务的进展，计划以及遇到的困难。
Sprint评审会（Sprint Review Meeting）：又叫Sprint演示会、Sprint展示会等，是团队用来展示当前Sprint开发成果的会议。
Sprint回顾会（Sprint Retrospective Meeting）：用来回顾在当前结束的Sprint中的工作、进行经验总结、反思，并拟定响应的改进措施。
5个价值观 承诺专注开放 Scrum中一切信息对所有人开放，让问题无所隐藏尊重勇气 Scrum开发流程1.我们首先需要确定一个产品需求列表（Product Backlog），这个是由PO负责的。
2.有了Product Backlog，我们需要通过Sprint Planning Meeting（Sprint计划会议）来从中挑选出一个Story作为本次迭代完成的目标。
3.Sprint Backlog是由Scrum Team完成的，每个成员根据Sprint Backlog再细化成更小的任务（每个任务的工作量可以在2天内完成）。
4.进行Daily Scrum Meeting（每日站会），每次会议控制在10分钟以内，每个人都必须发言，并且要向所在组成员当面汇报你昨天完成了什么，并且向所有组成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，相关人员在会后进行解答、处理。
5.当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行Sprint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品。
6.最后就是Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言式进行，每个人都要发言，总结讨论改进的地方，放入下一轮Sprint的产品需求中。
总结：1、确定产品需求列表-2、Sprint计划会议-3、Strum Team开始分工Sprint-4、Daily Strum Meeting每日站会-5、Sprint Review Meeting，Sprint的评审会议，演示会议-6、Sprint Retrospective Meeting，Sprint的总结会议。
敏捷开发和瀑布式开发比较工作方式：
瀑布式开发：①重视和强调过程文档，以文档驱动项目，将软件项目开发周期严格划分为几个固定阶段（需求分析，系统设计，软件设计，编码，测试，交付），每个阶段结束都有对应的详细文档作为输出；②上一个阶段的输出就是下一个阶段的输入，直至完成整个开发流程。
敏捷开发：①更加强调人和协作（团队之间，客户与团队之间），在高度协作的环境中使用迭代方式进行增量开发。②客户可对每次迭代的成果提出修改意见，开发人员进行调整和完善。③进行多次迭代直至完成完整产品交付。
优点：
瀑布式：
①每个阶段目的明确，阶段人员完全专注于该阶段的工作，有助于提高阶段效率。②由于存在详细的过程文档，在早期就能明确提出项目的范围和概况，能够更有效的组织和调配资源开展项目。
敏捷开发：
①阶段性成果可以在开发过程中被客户查验，从而降低软件开发风险性。
②灵活性高，需求的变更可在任何时候进行。
缺点：
瀑布式开发：
①开发过程中大量的文档，极大的增加了工作量。②项目后期才能展示成果给客户，增加了项目开发的风险。③需求变更成本高。
敏捷开发：
①最终交付的内容无法预测，预期和实际完成的内容经常会有很大差异。②敏捷需要高水平的协作以及开发人员和用户之间的定期沟通。业务和IT人员在沟通前需要做大量的准备工作，在很多情况下，业务的沟通时间无法保证。
适用项目：
瀑布式开发：
软件需求十分明确并且不会有频繁变化的项目
敏捷开发：
需求不明确、具有创新性或者需要抢占市场的项目。
总结 很显然，敏捷开发与瀑布式开发有着质的区别，但总的来说，在管理项目过程中，都不会严格的按照完全的敏捷开发或者完全的瀑布开发，而是各自参杂了其他的方式。
可见，项目管理过程中，过于强调模式并没有意义，重要的是要能预防问题的发生，在问题发生之后，能用最小的成本解决，模式起到的更多是一个参考作用。