敏捷方法不过就是几个业务人员跟开发人员坐在一起，桌子上摆上比萨饼，拿起比萨饼就吃同时就开始动手写代码，没有任何架构设计、流程、工具及操作方法，而实际上敏捷方法是需要计划的，也需要清楚地定义执行流程。在快速开发环境中，使用一些工具来管理开发过程也是非常必要的。
“没有规范的敏捷就像是创业公司初创之时的那种激情，而真正卓越的公司针对它们的目标和环境既有规范又有敏捷性，两者缺一不可。”
真正有效地实施某种敏捷方法要求项目团队中的每个人都有更强的技能和自我管理能力：
“尽管听起来跟通常的理解不同，但是敏捷其实是一种高度规范的方法。敏捷不等同于随心所欲。大多数人适应它的过程都会比较艰难。”
2．非此即彼论
从事敏捷的人士中有一些人高调地鼓吹Scrum和极限编程的好处，达到了一种非黑即白的境地。要不你就完全地采用这些具体的方法，要不你就根本不是敏捷。实际情况是：
敏捷方法包括Scrum背后的原理，可以根据不同类型的项目制定，还可以根据需要同其他的项目管理方法结合起来使用，获得灵活性和控制性之间的平衡。
在纯敏捷的方法和传统的瀑布模型之间有很多其他的选择。而让一个机构变得更敏捷，可以渐进地采用一些新的方法，而不是一夜之间变成纯敏捷，如图1.4所示。
3．传统开发方法死亡论
这是另外一种误解，认为传统的开发方法及所有跟此相关的实践论和工具都过时或没有意义了，将被敏捷的方法、实践论和工具完全取代。实际情况是：
对于特定的项目，根据项目的风险、复杂程度及其他因素，很多时候传统的项目驱动的开发方法仍然有效。
图1.4 非此即彼论
有很多方法可以在传统方法中应用敏捷的原理使之变得更加敏捷。
同样，在需要的时候，也有很多方法在敏捷方法中采用传统的实践论和工具，以获得更多的控制和可预测性。
4．敏捷只是加快速度而已
软件开发类的项目，越来越多地被人们冠以“急行军”的名目。爱德华·约顿定义了何为“急行军”项目。
“很简单，急行军项目就是项目实际的资源需求超过分配资源的50%以上。在大多数项目中意味着，以下的某个限制被强加给了项目：
项目时间在合理的预算基础上被压缩了一半，如一个预计12个月的项目被要求在6个月内完成……
项目团队人员跟同等规模的项目相比减少了一半……
项目预算和其他的资源被减半……
对功能和性能的需求或其他技术上的要求翻倍于通常情况……”
通常来说，“急行军”项目就是指要求项目团队不改变项目的执行方法，但以更快的速度完成同样的工作。这种粗暴地压缩项目时间的行为非常令人担忧，有很多潜在的风险。
约翰·伍登是非常著名的执教加利福尼亚州大学洛杉矶分校的篮球教练。“在约翰·伍登的最后12年执教生涯中，加利福尼亚州大学洛杉矶分校篮球队获得了10次全美大学生体育学会冠军。而在他执教该队的27年中，没有任何失败赛季。他们的88场连胜纪录可能永远无法超越。”约翰·伍登跟他的队员说：“再快点，但是别着急。”加快速度需要更好的纪律和更多的训练，而着急只是粗暴地加快速度，使成功率下降。
5．敏捷只适用于开发部门
很多人认为变得敏捷只对产品开发部门有好处，这是业务部门中常见的误解：只要使产品开发部门变得更加敏捷、效率更高，就可以解决所有问题。事实是，变得敏捷不只影响产品开发部门，同时也要求业务部门承诺同开发部门非常紧密地合作。同时还要求转变整个组织的文化和思维方式。
如果没有管理层的鼎力支持和长期承