我们知道项目管理的核心理念：三重制约，即项目的三要素：范围、时间、成本。
在这里，我想提一个问题，为什么范围是处于三重制约的顶端？而不是时间和成本这些要素？这其实意味着通常的项目是先确定范围，我们可以回想一下我们所学习的课程逻辑：是先明确需求，再确定工作分解结构。工作分解结构（项目范围）确定后，我们再确定项目的进度（进度网络计划）和成本（挣值管理）的。
这意味着什么呢？其实我们先前所学的项目管理思路有一个前提，就是需求和项目范围尽可能要不变或少变，这样才能使得项目三角形相对稳定，否则需求和项目范围一发生变化，整个项目系统就要发生变化：进度、成本、资源、风险等等…
我知道你会有一些疑惑：有些项目可能用这样的思路来管理是可以的，但有些项目就很难让需求和项目范围不变或少变。例如现在热玩的“王者荣耀”游戏、小米手机的MIUI，像这类产品的开发都是不断贴近用户需求，一直处于变化状态的，唯有这样才能有更好的用户体验，才能得到用户的认可。
那我们先前学习的项目管理思路（我们通常称为瀑布式方法）用到这样的项目中就挺难奏效了，所以今天我们学习一种新的项目管理思维：敏捷。
能用一句话跟我说说什么是敏捷吗？敏捷是一种拥抱变化，快速响应的产品开发方法。
敏捷的本质是什么呢？如同下图所示，以前的瀑布式项目管理思维是项目范围是相对固定量，而进度和成本是作为估算量不断调整；而敏捷思维恰恰相反，往往进度和成本是相对固定量，而不断调整项目范围而适应用户需求的不断变化。
明确了敏捷的思想，下面介绍两种敏捷的核心方法：迭代-增量模式和每日站会。
迭代-增量模式意味着开发周期非常短（通常2-6周，有的只有1周，甚或8小时），每个开发周期都有完整的需求-设计-开发-测试-上线等完整的闭环。迭代所带来的项目节奏非常快，而且优先开发对用户价值最高的产品功能。
而增量的方式则是有点像切蛋糕，将项目切成若干个块，我们在开始的时候不知道我们需要多少块，也不知道这个会是哪种蛋糕。我们会随着项目的进行，一块一块地弄明白。这样在一个迭代的末期，一个优先级排序比较高的需求中的一块，就完成了，这是迭代-增量开发的真正的亮点。
完成一个迭代后，一项功能需求就被转化成了可工作的产品并且可以向客户展示。而这种方法最大的有价值之处在于，客户可以在项目早期就进行反馈，我们也可以更快的速度响应客户，并在下一个迭代做出变更并且按照客户所期待的正确方向进展项目。
每日站会是敏捷项目的常见惯例。在每日站会中，每个团队成员只对三个问题提供答案：
1、昨天你做了什么?
2、今天你计划做什么?
3、你遇到什么问题?
敏捷项目感兴趣的是可交付和切实可见的结果，每日的进展会让团队成员感受到成就感，因为这是每个团队成员的真实成就，而不是应付项目经理和老板的。
总结一下，今天我们一起学习了敏捷的思维—一种有别于先前的瀑布式项目管理思维的全新思维。其本质是以客户价值为核心，不断拥抱变化、快速响应客户需求。并且我们介绍了两种敏捷方法：迭代-增量模式和每日站会。
敏捷思维非常好，但并不代表以前我们所学的瀑布式项目管理思维不好，而是各有其适用范围。核心在与敏捷适用于变更成本较小的情况，如软件开发、新产品的开发、互联网项目等；而先前的瀑布式项目管理思维适用于变更成本较大的情况，如硬件开发、运营型项目、工程项目等。所以说，各有千秋。作为新时代的项目经理，掌握两种思维方式都是有必要的，因为你将来不知道你会遇到什么样的项目，所以还是先做好准备吧。
