传统项目管理与敏捷项目管理

价值理念

        首先来看看在理念方面，两者有何不同。
        项目管理的铁三角是围绕着范围、成本和时间展开的。传统项目管理的特点是强计划驱动，需求范围固定下来后才可分配人员和时间，并在项目推进过程中积极跟踪和控制风险。
        敏捷项目是价值驱动的，在敏捷项目管理中，先固定了成本与时间，需求在交付期间频繁细化，在固定的时间盒中优先交付高价值的需求。

        传统项目管理和敏捷项目管理的背后，也是预定义过程和实验性过程的理念差异。预定义过程更注重计划，控制变化。实验性过程更加拥抱变化，通过快速实践获得反馈后调整前进。
PMBOOK 将项目的开发生命周期可分为预测型(计划驱动型)、适应型 (敏捷型)、迭代型、增量型或混合型。

一个项目可能具备上述一个或者多个阶段，在一家企业当中的不同团队可能使用着一到多种项目
管理模式，比加对于企业核心系练外句式顶目、交付性质强的项目会以传统项目管理的方式
进行，这些系统要么需求变化少，要么需要详细的项目计划和业务承诺。针对互联网产品，其需
求和用户往往都不稳定，采用敏捷模式可以更快地获得市场反馈，这种情况下无法也不适合进行
长期细致的计划。

  研发模型

01-瀑布模型

        业界普遍认为瀑布模型是由温斯顿·罗伊斯(Winston Royce)于1970 年提出的 。瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，以便于协作。瀑布模型将软件生命周期分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
        另外，瀑布模型非常强调文档，前一个阶段的输出就是下一个阶段的输入，文档是各阶段衔接的唯一信息。从瀑布模型角度出发，在设计和记录不充分的情况下，如果团队成员在项目完成之前离开，知识就会丢失，项目可能很难从损失中恢复过来。如果存在可以正常使用的设计文档，新
团队成员甚至是全新团队都应该能够通过阅读文档来接手项目。

02-Scrum框架

        Scrum 是一个解决复杂多变问题的框架。基于经验主义和精益思维，采纳了一种迭代和增量的方法来优化对未来的预测性并控制风险，帮助团队和组织创造价值。

        Scrum的生命力在于面对多变的市场时，它提供的小步快跑思路。产研团队通过“把手弄脏”来得到产品的快速反馈，从而改进产品。为了能够保持紧凑的迭代节奏，Scrum 框架对项目管理过程当中的信息和流程的“透明度“要求很高。
透明使检视成为可能，经常性的”检视”可以快速发现项目中存在的问题。
检视使适应成为可能，针对发现的问题，可以快速地调整。Scrum 实践可以让组织拥有应对变化的能力

 敏捷宣言

01-四条核心价值观

个体和互动                高于                        流程和工具
可用的软件                高于                        详尽的文档
客户合作                    高于                       合同谈判
响应变化                    高于                        遵循计划

02-敏捷十二条原则

我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
。欣然面对需求变化，即使在开发后期也一样

。为了客户的竞争优势，敏捷过程掌控变化。
。经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
。业务人员和开发人员必须相互合作，项目中的每一天都不例外

。激发个体的斗志，以他们为核心搭建项目

。提供所需的环境和支援，辅以信任，从而达成目标。
。不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
。可工作的软件是进度的首要度量标准敏捷过程
开友人员和用户要能够共同维持其步调稳定延续。
坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
。以简洁为本，它是极力减少不必要工作量的艺术。
最好的架构、需求和设计出自组织团队。
。团队定期地反思如何能提高成效，并依次调整自身的举止表现
敏捷管理仍然需要流程和工具、详尽的文档、针对合同的谈判以及遵循开发计划。并且事实上，一个敏捷的冲刺周期，就是一个小型的瀑布。

03-敏捷误区

敏捷开发不是极限开发，上下班或者工作量随意;
敏捷开发拥抱变化不是随意变化，策划往往看了效果再改一版;
敏捷开发不是忽略质量，每个迭代的质量仍然需要保证通过验收;
敏捷开发不会缩短开发周期 (相反因为频繁修改还会拉长)。