诺，走向敏捷之路也许注定失败。在很多时候，业务部门需要在这个转变过程中扮演领导者的角色。
“业务部门代表必须真正介入并了解这个过程。是否这样做了差异巨大（如沟通的术语、采用的方法等）。一旦他们了解了，他们将看到介入并主导开发过程的好处。同时业务部门还需要清楚地了解他们必须承受的东西，因为当他们看到每个迭代中暴露出来的问题时，他们可能会变得沮丧，如未完成的工作、团队犯下的错误和其他各种问题，这些问题在其他方法中都被掩盖了，因为业务部门参与很少，参与时间间隔很长。”
6．敏捷只是一种开发方法
跟前者类似的一种误解认为敏捷只是一种开发方法，而不是项目管理方法和框架。这种认知很可能来自敏捷在早期时主要是开发方法，没有或缺少框架和流程。但从那时起，敏捷已经越来越成熟，Scrum已经成为一种比较完善的方法和流程，并已经建立了相对完备的知识体系。
以下原因解释了为何这种认知依然存在。
（1）在敏捷项目中，开发方法和项目管理方法直接的分界线有些模糊：
·开发过程并不是同需求管理和其他项目管理完全分开的，通常来说，它们紧密地结合在一起。
·项目管理方法没有被正式地定义为同开发流程相独立的流程，在很多时候，敏捷方法中根本就不用“项目经理”这个词。
（2）敏捷方法作为组成部分之一，通过整合和扩展，构建了一个完整的项目管理框架。敏捷并没有详细地定义大型的和复杂的项目所需要的高层次的计划制定和项目管理，但将其描述为仅仅是开发方法是不准确的。
1.7 敏捷不是万能的
关于敏捷的误区有多个原因。
（1）敏捷方法设计时不是规定式的：它们没有告诉你需要做什么或如何去实施。总体来说，敏捷方法定义了一些基本原理而在具体情况下需要具体的解释。例如，敏捷宣言中定义了4个价值观和12个原则。“我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下4个价值观：
· 个体和互动高于流程和工具。
· 工作的软件高于详尽的文档。
· 客户合作高于合同谈判。
· 响应变化高于遵循计划。
也就是说，尽管右项有其价值，我们更重视左项的价值。”
具体如何在具体的情景中诠释这些价值观取决于做实施的人，他们将决定如何把它们应用到具体的业务和项目环境中。有时这些价值观可能被错误解释了。比如说，有些人会比较极端地解释这些价值观：
· 敏捷完全不需要文档、流程和工具。
· 敏捷不适用于依据客户合同的场景。
· 变更控制不适用于敏捷方法。
如此绝对化的解释绝对不是起草敏捷宣言的人的本意，价值观的描述原本就是相对的，关键就是你必须根据具体的业务和项目境况来解释和实施它们。很不幸，通常的情况不是这样的，而是敏捷方法被错误地实施或效果不佳。
（2）敏捷方法还在不断成熟过程中，还需要了解哪些是正确的而哪些是错误的。实际上，敏捷是非常强调持续改善的，整个体系追求的就是不断进化，随着与敏捷相关的知识体系不断发展，进化正在发生中。吉姆·哈史密斯把最终要的敏捷工具和方法划分为以下4个层面：
· 技术实践。
· 迭代管理。
· 项目管理。
· 组合治理。
敏捷方法深植于技术实践当中，这个层面也是最成熟的和最确定的，有一个已经被广泛接受的知识体系。但往更高层面上走，相对应的知识体系就变得越来越不成熟。例如，关于组合治理的书籍还非常少，而这个领域内又有很多需要学习了解的。
传统的项目管理办公室（Project Management Office，PMO）需要做出很大的改变以适应敏捷。很多时候，项目管理机构除了作为企业项目管理的流程和规章的制定者外，应逐步地将重心转移到一个增值咨询机构，以帮助企业实施更灵活的和自适应的流程。
关于敏捷很重要的一点是机械的教条式的实施注定失败，你需要真的理解其背后的原理，才能有针对性地根据具体业务和项目来实施。这也是为什么没有关于如何实施敏捷的规定的方法。
要选择适合具体业务环境的方法（不管是敏捷的，还是非敏捷的），根据项目情况量体裁衣，非常核心的一点是对每种方法有深层次的理解（了解其原理）。这也就是本书所要做的。