并非每个人都能正确实施敏捷，这没关系：您应该避免的5个敏捷神话

在本文中揭穿了一些关于敏捷的最常见误解。你做对了吗 如果没有，这篇文章应该可以帮助您从神话中辨别真相。

自从一组软件开发人员于2001年以敏捷宣言的形式提出敏捷以证明其对传统“瀑布”发展的反应后，敏捷已被证明对所有类型的企业都是两极分化力量，他们发现这种传统的“瀑布”发展功能失调且缓慢给出结果。与Waterfall方法相比，Agile具有灵活性，并鼓励快速响应不断变化的业务需求和用户需求。

无论我们是谈论IT还是其他业务社区，所有业务部门都有理由积极地迅速实现预期结果，并且其中一些公司接受了敏捷培训，以充分利用高级软件开发方法。

由于种种原因，并不是每个人都能正确实现敏捷。原因之一是敏捷性的破坏性变化，从而建立了流程，给用户带来了更多负担。现实在中间。

敏捷神话常常充斥于将敏捷作为其软件开发模型的商业领袖之间进行的激烈讨论。

敏捷是新的

敏捷不是一个新概念。2001年，发布了《敏捷宣言》；Scrum模式语言是在1995年的面向对象编程，系统和语言（OOPSLA）会议上提出的；在1995年的PLoP中描述了极端编程的先驱Episodes模式语言。因此，敏捷方法已经存在了一段时间。

简而言之，敏捷在变化多端的动态环境中培养适应能力。该原理适用于例如进化论。这也是每天与他人互动的方式–实际上，这是在复杂世界中进行有效互动的唯一方式。

敏捷易于实现

很难将复杂的系统交付生命周期更改为简单的生命周期。大多数组织可能会使事情变得复杂而不是简化。刚接触敏捷的公司常常被敏捷规模会困扰吗？如果没有，我们应该怎么做？

令人遗憾的是，一些组织经常尝试“靠书本”来实现敏捷的运营模型或单个敏捷的框架，但对转换的复杂性一无所知。结果，他们要么无法实施敏捷，要么在某种程度上成功地实施了敏捷，但是却要偿还更高的成本，而如果他们能更有效地应对转型，他们将无法支付更高的成本。

这些组织没有意识到敏捷的全部好处。要开始敏捷，您首先需要发展自己的思维定势。从理论上讲，学习理论上的飞机飞行是比较容易的，但是不要指望我在您的第一次起飞时和您坐在一起！

敏捷意味着没有计划

与瀑布类似，详细的计划对于敏捷性的有效性至关重要。两种方法的时序有所不同。计划主要在瀑布项目开始时进行，而敏捷项目则在进行中。

增量计划方法限制了前期投资，并导致项目随着项目的进展而适应快速变化的需求，优先级，范围等。

每个sprint的开头都有一个计划会议，以就所解决的需求达成协议，并且他们需要高度的准确性才能正确估计每个需求完成所花费的时间。在会议上，团队将协作确定不同任务的优先级。每次冲刺期间的每日站立会议详细定义了当天的活动。无论团队是在同一个房间中还是分布在同一房间，Scrum主管都可以确保在每次迭代结束时在团队内部进行sprint回顾。

对于增量计划方法，大多数企业都面临着技术债务管理（代码质量成本）的挑战。但是，由于他们愿意根据更多信息对先前的决定进行重新处理，因此他们能够解决大多数挑战。随着项目的进展变得可用。

对于企业，至关重要的是要同时了解用户需求和系统需求，以便在积压细化流程中有效地对用户需求进行优先级排序。

敏捷不需要任何项目文档

文档可作为任何应用程序开发工作的路线图：它使业务，最终用户和开发人员的目标保持一致，并解释了特定系统的工作方式及其包含的内容。

此外，由于整个敏捷开发项目中协作的增加，使所有利益相关者对最终产品有了更好的了解，因此团队对设计文档的需求减少了。

实际上，即使与Waterfall不同，敏捷也会产生文档。例如，项目经理可能不会创建一个列出所有项目需求的冗长文档，而是会编译用户故事，这些故事易于使用软件进行更新和维护，并且可以实时确定优先级，并确保整个开发过程中的实时可见性。

敏捷无法有效满足联邦软件的开发要求

联邦法规是什么都没关系；您可以继续使用敏捷方法。有时，特定的标准联邦惯例可能给与使用敏捷方法的软件开发人员签约的企业带来挑战。面临挑战的三个主要领域是：收购，企业架构以及安全认证与鉴定。

考虑一下：大多数机构在发布软件开发合同之前，都会列出项目要求以及最终产品的详细描述。这样做是希望从确定的供应商那里购买特定的产品。这里的问题是，如果在项目进行过程中结果随结果而变化，那么代理商将做什么？

“敏捷很灵活，可以接受最新的变更，从而可以满足代理商的要求，而不会造成任何延误，变更单和预算超支。但这并不意味着敏捷只是更快。我们必须具有流动性。”专家说。

在完成所有项目需求之后，更改通常变得很难进行，并且通常在联邦项目中明确规定在供应商合同中。因此，在敏捷（例如，用户故事和一定数量的冲刺）中，焦点可能会从固定范围转移到固定时间表和购买能力。