敏捷改进应该问题驱动（Problem Driven）。如果组织或团队中不存在需要改进的问题，那么就没有必要敏捷。

在正式启动敏捷改进之前，应该先问一问我们为什么要敏捷？敏捷能解决我们公司、我们团队现有的哪些问题，给我们带来哪些潜在的价值、额外的收益？敏捷改进成功的一个重要前提是首先对自己团队、公司/企业/组织的现状和存在的问题有一个清晰和清醒的认识。不管 CMMI 过程改进，还是敏捷过程改进，这***步的现状评估都是非常重要的。

有网友说，我们两年之前就对敏捷很感兴趣，早就跃跃欲试想敏捷了，可是到现在还是老样子，公司领导也不大感冒，因此一点进展也没有。应该逆向思考。如果两年都过去了，你们公司采用传统的做法都还运作得好好的，那为什么要敏捷呢？这正说明你们公司可能不需要敏捷。不要为了敏捷而敏捷。不要因为外面流行敏捷，媒体和 marketing 都在宣传敏捷，敏捷看起来很时尚，很时髦，很 cool，就盲目地尝试敏捷，何必劳民伤财呢？还是采取保守疗法好。

通常在紧迫性越大，大家一致希望改变的动力越大的情况下，敏捷改进的效果越好。

选择敏捷方法：Scrum？

有网友说，既然有统计表明 Scrum 是目前***的敏捷方法，那我们就试试 Scrum 吧。

且慢，敏捷不是某一种具体的方法，敏捷不是 Scrum，也不是 XP，因为除了 Scrum 和 XP，还有 AgileUP、FDD、Crystal、太极敏捷（Taiji）等等方法。敏捷是一套价值观和原则，至少也是一个集合的概念。究竟哪一种敏捷方法适合你，需要进行认真的调查、研究和分析。别人的敏捷不是你的敏捷，别人的成功也不是你的成功。所以，不要先入为主地认为，要敏捷，就一定要 Scrum，或者一定要 XP。

经典的 Scrum 在某种意义上是对传统项目管理的颠覆，Scrum 过程大胆地取消了项目经理这个角色，项目管理的工作由产品负责人、ScrumMaster 和自组织的开发团队共同来完成，这势必要求企业对原有的管理文化、开发文化包括考核文化作出调整，估计光这一点就会把很多人吓跑。

在尝试 Scrum 之前，应该先作一下评估，问这样一些问题：我们企业现在存在哪些问题，Scrum 能否解决这些问题；Scrum 是否与我们公司的管理制度和企业文化相匹配，如果不匹配，需要我们作出多大程度的改变，能否承受？如果 Scrum 不是适合我们企业的***敏捷方法，那么是否可以采用其他的或者混合的敏捷方法？单个方法不行，复方的行不行？西式的做法不行，中式的行不行？...

在明确了企业存在的问题和改进目标，并大致挑选出可以实现这一改进目标的敏捷方法集之后，才是挑选何种工具的问题。即便是同一种、同一类敏捷方法，比如 Scrum、XP 或 Scrum + XP，也都有很多种来自多个厂家的敏捷管理和开发工具可供挑选。

如果经过仔细的评估和分析，发现 Scrum 和/或 XP 确实有可能是适合我们企业的***方法，那么此时再大胆推进也不迟。

以上是比较合理的问题驱动敏捷改进的思考逻辑和顺序。如果颠倒顺序，在没有弄明白企业什么要敏捷、什么是敏捷的情况下，盲目地采用厂家优先、工具优先的做法，这种敏捷实施的失败可能性是很高的。

掌握了正确的思路和方法，敏捷可以离你很近。

【编辑推荐】

1. 再谈Jazz与敏捷：全球性的分布式开发
2. 争辩一下：敏捷开发不是XP
3. 浅谈敏捷开发思想中的简单***原则
4. WebWork敏捷开发尝试
5. 敏捷开发中的Scrum流程和术语