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