让我们一起来搞定 【传统项目管理和敏捷项目管理】
先来一张大图
价值理念
首先来看看在理念方面，两者有何不同。项目管理的铁三角是围绕着范围、成本和时间展开的。传统项目管理的特点是强计划驱动，需求范围固定下来后才可分配人员和时间，并在项目推进过程中积极跟踪和控制风险。敏捷项目是价值驱动的，在敏捷项目管理中，先固定了成本与时间，需求在交付期间频繁细化，在固定的时间盒中优先交付高价值的需求。
传统项目管理和敏捷项目管理的背后，也是预定义过程和实验性过程的理念差异。预定义过程更注重计划，控制变化。实验性过程更加拥抱变化，通过快速实践获得反馈后调整前进。
一个项目可能具备上述一个或者多个阶段，在一家企业当中的不同团队可能使用着一到多种项目管理模式。比如对于企业核心系统、外包式项目、交付性质强的项目会以传统项目管理的方式进行，这些系统要么需求变化少，要么需要详细的项目计划和业务承诺。针对互联网产品，其需求和用户往往都不稳定，采用敏捷模式可以更快地获得市场反馈，这种情况下无法也不适合进行长期细致的计划。
研发模型
瀑布模型
业界普遍认为瀑布模型是由温斯顿·罗伊斯（Winston Royce）于 1970 年提出的 。瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，以便于协作。瀑布模型将软件生命周期分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
另外，瀑布模型非常强调文档，前一个阶段的输出就是下一个阶段的输入，文档是各阶段衔接的唯一信息。从瀑布模型角度出发，在设计和记录不充分的情况下，如果团队成员在项目完成之前离开，知识就会丢失，项目可能很难从损失中恢复过来。如果存在可以正常使用的设计文档，新团队成员甚至是全新团队都应该能够通过阅读文档来接手项目。
Scrum 框架
Scrum 是一个解决复杂多变问题的框架。基于经验主义和精益思维，采纳了一种迭代和增量的方法来优化对未来的预测性并控制风险，帮助团队和组织创造价值。
Scrum 的生命力在于面对多变的市场时，它提供的小步快跑思路。产研团队通过“把手弄脏”来得到产品的快速反馈，从而改进产品。为了能够保持紧凑的迭代节奏，Scrum 框架对项目管理过程当中的信息和流程的“透明度”要求很高。透明使检视成为可能，经常性的“检视”可以快速发现项目中存在的问题。**检视使适应成为可能，**针对发现的问题，可以快速的调整。Scrum 实践可以让组织拥有应对变化的能力。
敏捷宣言
四条核心价值观
敏捷12条原则
我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
业务人员和开发人员必须相互合作，项目中的每一天都不例外。
激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
可工作的软件是进度的首要度量标准。
敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
以简洁为本，它是极力减少不必要工作量的艺术。
最好的架构、需求和设计出自自组织团队。
团队定期地反思如何能提高成效，并依此调整自身的举止表现。
敏捷管理仍然需要流程和工具、详尽的文档、针对合同的谈判以及遵循开发计划。并且事实上，一个敏捷的冲刺周期，就是一个小型的瀑布。
敏捷误区
敏捷开发不是极限开发，上下班或者工作量随意
敏捷开发拥抱变化不是随意变化，策划往往看了效果再改一版
敏捷开发不是忽律质量，每个迭代的质量仍然需要保证通过验收
敏捷开发不会缩短开发周期（相反因为频繁修改还会拉长）
有木有搞定一丢丢呢？
瀑布流开发
从项目计划上看，就像是逐级向下的瀑布，由此得名。轮船、汽车制造业，建筑行业一般沿用此法。要求在项目建设时，需求足够明确、文档足够规范，迭代过程中需求变更越多、越晚，对项目影响越大、成本越高，影响到项目的交付质量。
敏捷Scrum开发
敏捷项目管理强调商业价值的尽早交付，项目团队的自组织，不断响应客户动态的需求变化，持续的优化项目产品和交付流程。它作为新兴的项目管理模式，简化了传统项目管理的繁琐流程和文档
以 Scrum 为代表，欢迎需求变更，在客户需求不明确的时候，以在较短的周期内开发出可用的软件为目标，来帮助客户描述自己的需求。迭代过程中的需求变更会加入到项目继续迭代需求池，丰富项目的产品功能
阅读参考
敏捷开发
客人到餐馆来点菜（新项目）
不确定客户想吃什么的时候，通常选好餐厅后会先看看餐厅的菜单（客户往往提不出具体的需求）
根据图文菜单，客人点了十个菜（根据原型和设计稿，基本确定了需求）
后厨开始准备（项目启动）
配菜，炒菜、先上了两盘，让客人尝尝味道（先提供可用实例给客户用）
客人说还不错，后厨继续准备后面的菜，陆续上菜（不断迭代，不断测试）
上菜过程中，客人突然发现有个菜的味道太淡了，让后厨加了点盐又端上来了（敏捷的好处，可以不断测试和需求变更）
又上了两盘，不够辣，又拿到后厨加了辣（敏捷的坏处，需求没有提前明确，反复迭代，增加了工作量）
到最后两盘时，客人要求换两个菜，还好没有炒（迭代的好处，随时接受需求变更）
客人吃完，很满意（基本满足了全部需求）
瀑布模型开发
客人到餐馆来点菜（新项目）
不确定客户想吃什么的时候，通常选好餐厅后会先看看餐厅的菜单（客户往往提不出具体的需求）
根据图文菜单，客人点了十个菜（根据原型和设计稿，基本确定了需求）
后厨开始准备（项目启动）
根据客人的下单配菜，炒菜（基本上不会主动去了解完整需求）
半个小时了，菜还没上桌，客人饿极了（项目启动后很长一段时间客户什么都看不到）
再过20分钟，十个菜一起上来了（项目最终一次交付）
客人说有几个菜挺好的，但是有个菜味道淡了，有两个不够辣，还有两盘重复了想换掉（我是买单的，我要变需求）
这时候大堂经理来了，说:“味道淡了可以加盐，不辣可以加辣，但是换菜不行，已经炒好的那两盘菜也是要算成本的”（瀑布的坏处，需求变更比较麻烦）
于是，后厨只给客户加了盐，加了辣。
客人吃完不是很满意，下次不来了（没有满足需求）
大部分的项目！！！ 【混合 - > 适者生存】
