敏捷项目管理
软件项目管理的两大主流管理模式分别是传统项目管理和敏捷项目管理。
传统项目管理通常采用的是瀑布式、部分迭代开发模式，要求在项目建设时，需求足够明确、文档足够规范，迭代过程中需求变更越多、越晚，对项目影响越大，会影响到项目的交付质量。
敏捷项目管理作为新兴的项目管理模式，简化了传统项目管理的繁琐流程和文档。以 Scrum 为代表，欢迎需求变更，在客户需求不明确的时候，以在较短的周期内开发出可用的软件为目标，来帮助客户描述自己的需求。迭代过程中的需求变更会加入到项目继续迭代需求池，丰富项目的产品功能。
一、 管理流程
完整的项目管理流程可以总结分为五个过程组： 启动、规划、执行、监控、收尾。
敏捷项目管理框架是：构想、推测、探索、适应、结束
和PMBOK知识体系项目管理五大过程组一一对齐。
- 构想阶段：确定产品的构想、项目范围、项目团队以及团队共同的工作方式。（产品愿景-组建团队-项目章程-流程裁剪）
- 推测阶段：制定基于功能发布计划、里程碑和迭代计划，确保交付构想的产品（产品线路图-产品待办列表-产品发布计划）
- 探索阶段：在短期内提供经测试的功能，不断致力于减少项目风险和不确定性。
- 适应阶段：审核提交的结果、当前情况以及团队的绩效，必要时做出调整。
- 结束阶段：终止项目，交流主要的学习成果并庆祝。
1、传统项目管理
传统的项目管理要对项目的所有过程进行管理和风险把控，并要求在不同环节的有文档输入和输出。比如，PMBOK 对项目整合管理的过程组做了文档输入和输出的整理， 但是，项目管理主要是对范围、进度、成本、质量、人力资源、沟通、风险、采购和干系人进行管理，每个环节都存在启动、规划、执行、监控和收尾过程。
如果采用传统的项目管理模式，每个环节都必须要进行严格的规划，一旦出现规划以外的变更，都需要经过批准后才能执行改变。
2、敏捷项目管理
敏捷项目管理简化了繁琐的流程和文档管理，主张团队内部的面对面沟通和交流。以Scrum为代表，简单、持续集成、不断交付、价值优先、拥抱变化的原则在面对时刻变化的市场经济和不断发展的技术时变得十分友好。 敏捷项目中，项目管理计划分不同的等级，可以用一个洋葱图来表示，也就是洋葱计划图，如下图所示：
战略和投资规划在敏捷项目管理的最外层，由更广泛的组织管理系统来处理。由外往内，不断切分项目计划，最后实现最小周期的可行性版本迭代。对复杂或不明确的客户需求进行合理的分割，最终实现总体上的统一。
传统铁三角：范围、成本、进度（范围不可变）
敏捷铁三角：进度、范围、成本（进度不可变）
敏捷三角：价值、质量、三重约束（成本、进度、范围）
敏捷三角形的演变过程（详见《敏捷项目管理》P12-13页）：
敏捷三角形：
1、价值目标：提供可交付的产品
2、质量目标：提供可靠的、适应性强的可交付产品
3、约束目标：在可接受的约束内，实现价值和质量目标
项目管理的铁三角，从原来的时间，范围，成本质量的几个要素，逐渐过渡到了敏捷所追求的价值，质量以及时间，范围，成本构成的约束，形成了敏捷的三角形。
有了这个理念，我们就可以把敏捷和项目管理做融合，项目管理多一些授权，多一些拥抱变化，就可以向敏捷靠近，敏捷多一些体系化，就可以向项目管理延伸，二者是一个融合的过程，这将是一个趋势。
二、风险控制环节
项目风险在任何项目中都存在不确定性，一旦发生，会对项目造成积极或消极的影响，如范围、进度、成本和质量。
传统项目管理：
传统项目管理要求项目在规划过程中规划风险管理、识别风险，并且对风险进行定性/定量分析，给出风险应对方案。虽然已知的风险可以在被识别和分析后采取应对措施，但正是因为风险的不确定性，要求项目风险管理必须给未知风险或者已知却又无法主动管理的风险分配一定的资源储备。
所以，传统项目管理会要求提供风险登记表，并且记录风险应对措施在处理已识别风险及其根源方面的有效性，完成风险再评估和风险审计，直到风险被降到最低。
敏捷项目管理：
敏捷项目管理不同于传统项目管理，开发评估是以工作量为导向，而非时间导向。所以，在进行开发任务评估时采用的是相对估算而不是绝对估算，为风险留足了应对空间。同时，Scrum集合了一线人员的参与，经验分享，集思广益，将小型团队转化成独立的管理者，更有利于问题的解决。
敏捷项目管理在项目没有正式结束前，交付的可用软件是允许风险存在的，并且是根据风险的优先级来进行排期修复。
三、企业项目管理分析
项目管理模式：外瀑布内敏捷（有人称为“信封法”）
第三方业务风险控制服务行业目前还没有发展出固定的行业标杆，大家都在竞争中追求最大范围的满足行业需求。在这样的背景前提下，大部分项目都没有明确和长久稳定的需求，Scrum 管理模式很好的满足了这个行业的项目管理现状。
但是，作为行业客户，在大部分的商务场景下客户都会希望通过固定成本合同来实现自己的利益最大化，问题是现在合同双方都很难在项目开始时明确约定需求和最终实现方式。所以，在客户不能接受 Scrum 时，通常会选择外瀑布内敏捷的项目管理模式，满足双方的利益。
举例：
如果把拍婚纱照作为一个项目，摄影师和新人作为项目主要成员，项目基本流程满足：
- 选婚纱照的套餐（固定成本，确定基本需求）
- 拍摄（项目启动）
- 挑照片（提交测试，开始验收）
- 根据底片修图（修复）
- 拿到照片（项目结束）
以上就是顺序执行，瀑布式的结果。
然而，拍摄的过程中新人通常都会要求：
较短时间内提出新增造型、内景换外景的要求（切换pose的任务）
配合摄影师完成拍摄环节的工作（通过迭代，完成项目）
以上就是内部快速迭代，敏捷式的结果。
很显然，新人在拍婚纱照之前并不知道自己最终拿到的照片穿的会是哪套衣服，摆的会是哪个pose；但是，很清楚的是哪天拍照、哪天挑照片、哪天可以拿到照片，这套流程同时满足了内部和外部需求。
只是，为了项目顺利结束，可能在内部和外部需求时，并没有要求完全以相同的速度前进，就像你不能以你配合完成摄影的速度去要求摄影楼马上提供婚纱照。
四、传统 VS 敏捷 ？ 适者生存
敏捷项目管理只是一个灵活的实践框架，提供的是一套清晰游戏规则，根据不同的环境可以提供一系列不同的途径。
传统项目管理却是一套中央集权制管理法，要求按计划行事，任何环节发生变更都必须获准后才能进行改变。
我们的项目经理或管理者们，很多都是从传统项目管理或实践中开始了解敏捷或在进行转型的，但敏捷和传统项目管理却有着很大的不一样。这些不同，不是表面上的框架和方法论，也不仅是工具和技术的应用，更为关键的是思维方式不一样！
在市场经济不断发展、时刻变化的现代互联网环境下，适应变化、拥抱变化的项目管理，才是友好的、可行的管理模式。
不管是传统的瀑布式开发管理还是敏捷迭代式管理，没有哪个好与不好，只有在不同的项目环境中哪个更适合。敏捷已逐渐融入渗透到传统的项目管理中，彼此相互相生的状态。
五、阅读参考
某博主po的一个很有趣的“敏捷和瀑布”对比例子，给大家作为阅读参考：
1、 敏捷开发
- 客人到餐馆来点菜（新项目）
- 不确定客户想吃什么的时候，通常选好餐厅后会先看看餐厅的菜单（客户往往提不出具体的需求）
- 根据图文菜单，客人点了是个菜（根据原型和设计稿，基本确定了需求）
- 后厨开始准备（项目启动）
- 配菜、炒菜，先上了两盘，让客人尝了尝味道（先提供可用实例给客户用）
- 客人说还不错，后厨继续准备后面的菜，陆续上菜（不断迭代，不断测试）
- 上菜过程中，客人突然发现有个菜的味道太淡了，让后厨加了点盐又端上来了（敏捷的好处，可以不断测试和需求变更）
- 又上了两盘，不够辣，又拿到后厨加了辣（敏捷的坏处，需求没有提前明确，反复迭代，增加了工作量）
- 到最后两盘时，客人要求换两个菜，还好没炒（迭代的好处，随时接受需求变更） 客人吃完，很满意（基本满足了全部的要求）
2、瀑布模型开发
- 客人到餐馆来点菜（新项目）
- 不确定客户想吃什么的时候，通常选好餐厅后会先看看餐厅的菜单（客户往往提不出具体的需求）
- 根据图文菜单，客人点了十个菜（根据原型和设计稿，基本确定了需求）
- 后厨开始准备（项目启动）
- 根据客人的下单配菜，炒菜（基本上不会主动去了解完整需求）
- 半个小时了，菜还没上桌，客人饿极了（项目启动后很长一段时间客户什么都看不到）
- 再过了二十分钟，十个菜都一起上来了（项目最终一次交付）
- 客人说，有几个菜挺好的，但是有个菜味道淡了，有两个不够辣，还有两盘重复了想换掉（我是买单的，我要变需求）
- 这时候大堂经理来了，说，“味道淡了可以加盐，不辣可以加辣，但是换菜不行，已经炒好的那两盘菜也是要算成本的”（瀑布的坏处，需求变更比较麻烦）
- 于是，后厨只给客户加了盐，加了辣。客人吃完，不是很满意，下次不来了（没有满足需求）
接下来我们通过几张图片总结一下敏捷项目管理方法的要点。
