敏捷开发中的10大错误认识
原文：
作者：PeterMeasey
译者：张某人ER
摘要：对于快速发展的敏捷软件开发领域，本文将对其最常见的错误认识进行分析。
成为一个关键的促进因素。
敏捷开发中的错误认识
对于任何框架或方法来说，随着时间的推移，对它们的错误认识和理解可能会获得信任与认同，继而成为常识。
错误认识1——“敏捷”是新概念
已是很多人固有的熟知方法。在本质上，“敏捷”是在动态环境的可变性下，能够做出检验和适应。这是众多理论中的一个基本原则，例如，进化论。这也是人类在日常与世界互动的方式——实际上是人类可以有效与这纷繁复杂世界互动的唯一途径。
错误认识2——敏捷开发的执行很容易
通常，将一个复杂系统的交付周期变为简易的事，并不那么容易。（使用敏捷开发的）组织发现，复杂化事物通常比简化它们更容易。
遗憾的是，在一些组织中，他们试图“照搬书本”式地实现一个敏捷操作模型或单一的敏捷框架，而不理解使用敏捷开发时转变的复杂性。因此，这些组织要么没能实现“敏捷”，要么取得一些成就，相较高效的应对转变，却付出了更高的成本和痛苦。
错误认识3——敏捷开发是急功近利
尽管对敏捷开发的变通运用，可以带来巨大的效益，但现实情况是，多数变通能力需要经历学习曲线的规律。当人们和组织在学习的过程中，在经历阶跃变化前，交付能力可能还会下降，当经历这个转变后，才开始获得交付能力的提升。
错误认识4——敏捷开发意味着没有开发文档
这个错误认识可能源于对敏捷宣言的误解，在宣言中有这样一句：“我们重视编写软件胜过全面的开发文档”。然而宣言并不是说开发文档是不需要的，它只是强调将精力集中在开发软件上，而不是花过多的时间在创建详细的前期开发文档上，理解这一点是很重要的。
所有有效的敏捷交付，应考虑并备有专注于目标的，价值驱动的，具有商业利益的文档，才能使企业有效地使用该产品，并使技术团队可以继续支持和维护产品。未能留存相应的文档是技术债务的一个典型例子。
错误认识5——敏捷开发意味着“拼接”代码，却只需很少的架构或设计思想
错误认识6——敏捷开发是最有效的技术
，每个框架会提供部分解决方案。交付和管理的执行必须讲求实效，如敏捷开发。整个系统的执行和使用必须认识到其所处的真实世界的环境，同时需考虑敏捷和非敏捷框架的最佳整合，因为整合的系统将在真实世界的环境中运行。单一的“万能”框架并不存在。
错误认识7——敏捷开发：读本书就够了
通过简单地读一本书，并不能很好理解敏捷开发的概念。当然，选择并阅读一些行家所著的书籍，是一个很好的主意。但仅仅阅读书本并不能代替实战经验，对于想真正掌握“敏捷”的思维模式，并成功的将一个组织或团队变为“敏捷”开发模式，实战经验是至关重要的。
错误认识8——“敏捷”只涉及软件的交付
敏捷宣言中确实描述了在软件交付情境下的“敏捷”概念，但“敏捷”概念不光可以运用在软件相关的领域，同样可以成功地应用于商业环境中。本质上，“敏捷”的思维模式适用在任何动态变化的商业环境中，如市场营销或业务变化。
错误认识9——敏捷开发应该在大爆炸式的转变中同时替换所有事情
当敏捷开发被大爆炸式地应用于大型项目、方案或整个组织时，存在一个显著的风险，即一个敏捷开发模式的好处可能不会被意识或理解。组织及其员工常常会继续着他们一直在做的事情，却自认为已经使用了一个“敏捷”方法。转变能力是一个长期的学习和改变的过程。企业在发展，同时执行业务最好的方式也在不断转变。因此，执行一个大爆炸式的“敏捷”转型后，想当然地认为进一步的改进不再必要，是一个错误认识。
这里有一个有趣的引用，出自阿尔伯特·爱因斯坦，是爱因斯坦关于疯狂的定义：“疯狂就是用相同的方式做同样的事情，却期待不同的结果出现。”
这句话很好地总结了失败的敏捷开发转换，这些组织仍然在做着它们以前在做的事情，即便它们没有实际的改变任何事情，却期待着增加的价值。
错误认识10——敏捷开发意味着不需规划，只管做就是
绝大多数的敏捷框架都涉及经常的、定期的和不断发展的规划。如果一个团队主要是做维护工作或缺陷修复，或生产一个产品时，在数周内并不需要客户任何进一步的需求变化，他们可能只需在单次迭代/sprints中做出规划。
如果客户仅需大概了解产品将在多长时间周期和多少成本下交付，团队可以在包含迭代/sprints的产品发布中做出规划。
如果有发布规划，一个高级的协定将会取代何种产品将被交付，以及花费多少时间和成本等问题的重要地位。然而，协定和规划应该被设定为允许变化的，因为会存在不断出现的规划。
这种精神使人能在旅行中和大自然更加接近，
