敏捷项目管理门派林立，比如Scrum、极限编程(XP)、看板方法、精益(Lean)和水晶(Crystal)等。

　　具体可用的工件包括电子或物理看板(即可挂在墙上的大白板)、每日站立会、发布/迭代(冲刺)计划会、迭代(冲刺)评审/回顾会、持续集成(CI)、结对编程和(验收)测试驱动开发(ATDD)等

一、敏捷是什么

1、敏捷是来源于软件开发领域的思想、实践、框架

2、敏捷是一种开发方式、以人为核心、迭代、循序渐进的开发方式，把产品开发引到了小步快跑的线路上

3、敏捷是为了更好的满足客户需求，交付周期短，创造更高价值，拥抱变化心态，无固定模式的价值观驱动

01 关于敏捷，两个业界公认的说法

'Agile is a mindset: defined by values, guided by principles, manifested through many different practices.'

-- Ahmed Sidky. co-author of Becoming Agile in an Imperfect World.

02 业务角度，敏捷要达到2个目的

1、能够更早向客户交付更高价值的软件。

2、能够更好应对需求的变化。

二、“敏捷开发方法”与“项目开发方法”的区别

项目有独立的产品服务开发目标和开发时间起点终点;

而“敏捷开发方法”是在一个既定的短时间内将本应由一个项目组开发的独立产品服务开发任务切分成若干个有关系或没关系的开发任务，并行或迭代开发。

三、敏捷项目管理与瀑布式项目管理的区别

最大的区别:在敏捷里，交付和反馈是重点，完成很重要，但可能不是最重要的。

缺点:大家可能认为敏捷很快，但其实恰恰相反，敏捷项目管理可能会使得项目花费的时间更长。

四、传统瀑布开发团队转敏捷 如何让团队抵触小

首先要从产品层面看，为什么要做敏捷?对谁影响最大，支持和反对的人是谁，他们的诉求是什么?搞清楚这些就会知道你可以得到谁的支持和反对，在做的时候如果遇到困难就可以知道谁可以支持你，也可以评估一下，有这些支持和反对的情况下，转型是否能够做下去;

其次要搞清楚这件事对团队和团队成员有什么好处和坏处，因为团队成员只有清楚了对他们的好坏处之后他们才会在内心接受这个新的开发模式;

另外就是要搞清楚是否需要解决成员是否抵触的问题，至上而下和至下而上的方式是不一样 。

五、选择敏捷试点团队的标准

1、上下愿意改变(尤其是上)

2、跨职能自组织独立完成项目

3、团队人数5-9人(不含PO和SM)

4、项目变化多，瀑布不能应付

5、敏捷团队集中办公

6、人员素质(Scrum价值观)

7、有Agile coach

8、团队愿意接受新事物

9、有问题解决，要能看到效果

10、团队压力适中

11、项目周期推荐6个月

12、项目要相对独立

13、试点项目的可见度和重要性

14、交付周期短、频繁交付

15、人员的稳定性

16、软件架构的支持

六、 敏捷项目管理十大原则

在敏捷项目管理的道路上，我们需要边实践、边思考，通过管理方法上的“改进实验”，改变很多以往传统项目管理中的低效做法，迭代，改进，总结引出敏捷项目管理的“十大原则”。

七、传统企业如何推广敏捷

对于传统企业推广敏捷，最重要的是建立共识，企业领导与部门领导，上级与下级，产品团队，研发团队之间的共识，可以不提敏捷，先着眼于当前存在的问题及企业、团队、个人存在的价值、愿景;

提出敏捷的方式，逐步建立信任;这是一个互相调频道的过程，只有在一个频道上，才能依据企业的特色情况，独有文化，对敏捷方式及其它企业的成功模式进行相应的裁剪，打造符合企业自身业务与文化的敏捷方式，从而使敏捷能够落地;

对于快速达成共识这一目标，集体参与敏捷相关培训不失为一个快速的办法，同时在日常工作中建立知识共享机制，从而使企业团队之间沟通能够在同一个出发点与层次进行沟通，迅速达成共识，对多变的业务需求进行快速且合理准确的响应。

八、敏捷项目经理应考虑的措施

● 简化流程

● 投入自动化

● 确保领导参与

● 建立改进目标

● 让组织文化和绩效管理更符合敏捷理念

在当今的商业环境中，不敏捷的工作方式已经不再是企业的选择。实施敏捷不是为了时尚，不是为了跟上“最新和最伟大”的潮流。实施敏捷是一个生存的根本动作。没有敏捷，就难以执行任何其他战略举措，例如数字化转型。

希望我们的这些总结和反思，能给正在实施敏捷或将要实施敏捷的项目经理们，提供有价值的参考和指导，让大家少走一些弯路，早日实现敏捷项目开发。