什么是项目管理的“敏捷”
众所周知，船舶出航前是要制定周密的航行计划的，对出航期间的水文、天气、海况要了如指掌，将电/磁罗经、六分仪、观通导航设备进行彻底的检查与校准，尤其是航海长必须对航海图上的航线烂熟于心。那么从理论上讲出航之后按照既定的航行计划走就是了。可为什么在途中还要设置诸多检查点，在检查点上航海部门要重新校准积算舰位？有航海经验的人都明白，航行计划在实际航行过程中受到诸多因素的影响，单凭仪表盘和图纸是无法保证航行安全的。同理，在项目管理过程中，单凭事前制定的一成不变的计划也很难保证项目的最终成功。于是，“敏捷”一词便引入了项目管理过程中。
其实，敏捷开发对项目经理来说并不陌生。近年来，国内越来越多的互联网软件公司也开始采用敏捷开发的方法来做项目管理，在很多公司的桌椅旁边到处可见白板和贴满各种颜色便签的任务墙，然后，每天大家围着白板开个站会，这其实就是敏捷开发的特征。敏捷的反义当然是不敏捷，但是这个“不敏捷”在软件工程里面却有个专业的术语叫做“瀑布式开发”。
传统项目管理通常采用的是瀑布式、部分迭代开发模式，要求在项目开发时，需求足够明确、文档足够规范，迭代过程中需求变更越多、越晚，对项目影响越大，会影响到项目的交付质量。敏捷项目管理简化了传统项目管理的繁琐流程和文档。以 Scrum 为代表，欢迎需求变更，在客户整体需求不明确的时候，以在较短的周期内开发出可用的软件或功能为目标，来帮助客户描述自己的需求。
传统项目管理一般分为五个过程组：启动、规划、执行、监控、收尾。还有十大知识领域，要对项目的所有过程和领域进行管理和风险把控，并要求在不同环节的有输入和输出。如果采用传统的项目管理模式，每个环节都必须要进行严格的规划，一旦出现规划以外的变更，都需要经过审批后才能执行改变。
敏捷项目管理简化了繁琐的流程和文档管理，主张团队内部的面对面沟通和交流。简单、持续集成、不断交付、价值优先、拥抱变化的原则在面对时刻变化的需求。包括代码部署频率、从提交到部署的前置时间、变更失败率、故障恢复时间都较之传统项目管理有很大的不同。尽管敏捷方法带来了一些成功案例，但还是有很多因素阻碍它被广泛采纳。敏捷方法的组织和管理者经常发现：在应用过程中，对频繁的动态变更很难得到管理方面的支持。这些方法需要开发者、管理者和用户都改变他们工作习惯和思考的方式。从规划和设计，计划与跟踪，迭代开发，持续交付这些方面。敏捷开发意味着不断推翻之前的原型。这就对项目的风险控制产生了极高的要求。传统项目管理要求项目在规划过程中规划风险管理、识别风险，并且对风险进行定性/定量分析，给出风险应对方案。虽然已知的风险可以在被识别和分析后采取应对措施，但正是因为风险的不确定性，要求项目风险管理必须给未知风险或者已知却又无法主动管理的风险分配一定的储备。因此，传统项目管理会要求提供风险登记表，并且记录风险应对措施在处理已识别风险及其根源方面的有效性，完成风险再评估和风险审计，直到风险被降到最低。
有的公司把敏捷项目的开发评估以工作量为导向而非时间导向。需求到交付阶段作为整个设计阶段。敏捷管理在高度变化的项目中始终关注价值、质量和约束条件。承认在开发过程中的变化是正常的，计划是用来适应变化的，并在这个过程中不断调整。所以，在进行开发任务评估时采用的是相对估算而不是绝对估算，为风险留了应对空间。将计划本身作为管理单元，计划对变化的适应能力来源于计划本身粒度的缩小。在项目没有正式结束前，交付的可用软件是允许风险存在的，并且是根据风险的优先级来进行排期修复。
由于在敏捷开发中软件的很多功能是不可能被预定义的，更多的用户直接参与到设计过程中，功能需求即用户需求的转化，项目开发的管理属性和工程属性的衔接点实际上就是版本管理，持续交付就是解决系统耦合性的问题（代码级耦合、组件级耦合、服务级耦合）。那么，如何在敏捷开发项目中更有效的进行运作和管理？
1.优化流程，减小耦合
将服务、功能和任务包进行更小的拆分，进一步减少它们之间的耦合度，减小各个环节交接时所产生的浪费。各个环节之间建立合适的缓冲区，降低工作流程中的同步时间。做好可视化看板的管理，不但要做好每日站会，而且在各个过程中设置检查点，及时互动沟通，收集反馈。
2.控制粒度，及时交付
在移动互联网时代，随着时间的变化，市场环境、用户需求、竞争对手等因素都在时时发生着改变，需求方会不断地赋予产品新的需求来应对这种变化。为了让需求方尽早地看到结果，我们就应该以控制开发和交付过程的颗粒度、小步快跑的姿势来做产品，尽早地交付新的版本。对于敏捷来说，给用户快速交付可用的软件胜过冗长的完备的各类文档。这也意味着产品交付的时间间隔越来越短，也缩短了产品的迭代周期，
3.项目计划是用来适应敏捷变化的
敏捷并不意味着不做项目计划，恰恰相反的是，敏捷更加注重计划的制定，但计划应该具有足够的弹性与针对性。因为敏捷开发就是为了能够及时地响应用户的需求，所以并不会死守着项目开始时的计划不进行调整，一旦情况发生变化，即使到了开发后期，敏捷管理也接收需求的改变，不断地修正自己原先的计划，利用变化来为产品创造竞争优势。
4.迭代版本周期内尽可能少的添加任务
尽管敏捷开发的目的是为了尽量让产品能够适应市场及用户需求的变化，但也并不意味着可以毫无节制地添加和修改项目任务。从这个角度来看，我们可以把每个版本迭代看作一次小的瀑布式开发，那么，每个版本都有自己的开始时间和结束时间，也在项目刚开始的时候就配置了相关的资源来实现此次迭代的需求，如果临时突然插入新的需求或是修改需求的话，肯定会对项目的进度产生影响。所以，还是尽量在版本开始前就规划清楚一些，除非碰到特殊情况，否则尽肯能的做到版本迭代周期内不加任务。
5.进行敏捷的团队结构配置
为了实现项目的敏捷，在团队结构上也是需要进行敏捷编组。在当前的情况下，一个敏捷的项目团队规模将会被做限定，人数太多的话可进行团队分组。将相互强关联的部门进行合并，比如测试部门合并进研发部门等。每个团队人员不超过二三十人，拿每日站会来说，也是要基于敏捷的团队的配置才能更好的完成。如果一个办公场地，站满了几十上百人，每个人说一下自己的日常工作，那么基本上一个上午的时间就过去了，这是效率非常低下的一种表现形式。相反，项目成员在一个办公室进行办公将会大大提高沟通效率，有什么问题可用直接面对面地解决。这样的话，也可以充分利用办公室里的白板和空间。
6.敏捷也是需要总结的
项目阶段完成或结束时一定有项目总结的，在敏捷环境下，项目团队成员也需要定期对前一个或者前一段时间的工作进行总结，以便调整自己的行为，提高项目的开发效率。因为很多不确定的因素都会导致原计划变更，比如需求的变更、人员的变动、组织战略的变化等等都会让我们做出不同的反应。在每次失败中进行反思，吸取经验教训，其实是对敏捷的进一步认识，团队成员只有通过不断地总结、反思和调整，才能更好地保持团队的敏捷性。