什么是敏捷方法论？[关闭]

有人可以用简单的句子解释敏捷方法吗？

敏捷是很多事情和实践，但是我认为它的核心只是迭代开发。

迭代： 考虑一堆非常小的瀑布。也就是说，采用瀑布方法（requirements-> spec-> code-> test），但是要花整整几周的时间而不是在一年左右的时间内完成，项目。在“迭代/冲刺/增量”末尾，您将获得少量但完整且经过测试的附加功能。

如果事实证明您所做的不是客户想要的东西，业务需求的变化或任何其他事情，这使您可以快速更改项目的过程。因此，术语“敏捷”。

我认为没有什么比敏捷宣言本身更好的了：

我们正在探索
通过开发软件并帮助他人开发软件的更好方法。
通过这项工作，我们开始重视：

通过流程和工具进行个人和交互通过综合文档的
工作软件通过合同谈判的
客户协作
响应计划变更

也就是说，尽管
右侧的项目有价值，但我们更重视左侧的项目。

来自http://agilemanifesto.org/

对我来说，最重要的想法是：

需求变更将发生，因为我们被迫在了解所需知识（项目开始）的最低点来设计软件，并且需求只会在项目过程中变得更加清晰。

传统的（瀑布式）方法试图通过在项目开始时使每个人都签署全面的规范来将他们锁定在合同中来减轻这种变化。这也许可以作为CYA，但是它并不能使任何人高兴地交付不满足用户需求的东西，特别是如果他们的反对通过“请您签字同意！”来解决。

敏捷方法旨在容纳不可避免的变更，而不是使开发团队免受这些变更的影响。它以多种方式做到这一点，其中主要是迭代开发和利益相关者在该过程中的持续参与。以我的经验，这最终会使每个参与其中的人都感到更快乐，尽管对于某些作为核心计划者的管理人员来说可能会更不舒服。

一句话看起来像这样：

敏捷软件开发是基于迭代和增量开发的一组软件开发方法，其中需求和解决方案通过自组织，跨职能团队之间的协作来发展。

这来自维基百科的定义，我非常喜欢。我强调了核心原则。

我还想补充一下敏捷不是。那里有很多商店声称自己是敏捷的，但是这意味着他们对计划的项目不感兴趣，并且期望在不合理的短时间内完成工作。

敏捷！=没有项目计划。很难处理那些暗中认为陈述是错误的人，因为他们往往是管理类型，并不总是容易矛盾。

安迪已经与《敏捷宣言》建立了联系，我认为这将涵盖该宣言。

我认为查看敏捷宣言的来历也很有用。那里有许多方法，这些方法具有一些共同的元素，并且具有许多相似的动机：极限编程（XP），Scrum，DSDM，自适应软件开发，Crystal，功能驱动开发，实用编程（来自Alistair Cockburn的列表）。提出这些方法的人们决定提出一个营销术语，以涵盖他们共有的东西，从而增强他们所说的力量。

有趣的是（根据某人告诉我的信息），入围列表中有许多名称可以代替“敏捷”来使用-其中之一是“自适应”。我个人认为，作为一个概括起来更好的词，真正的敏捷要比“敏捷”更好！

采用敏捷方法归结为在产品开发的其他方面强调提供优质产品，并意识到来自用户社区的反馈是创建优质产品的重要组成部分。

与传统/瀑布式开发方法相反，该方法强调前期设计，文档和接口定义，同时不强调实现并将产品从开发过渡到发行。

在我看来，团队可以将内在素质融入产品中，我认为这是通过验证产品是否符合开发团队的意图并可以合理地容纳可预见的增强功能来实现的。还有完全基于感知的质量因素，可以衡量产品满足其用户需求的程度。

敏捷方法倾向于迭代地交付产品，将用户反馈和开发人员反馈合并到每个迭代中，并在实现最小生存能力时促进传递功能的每个增量，以此作为强制功能来引起频繁的用户反馈并抵消开发活动继续进行的趋势。长时间没有用户的反馈。在我看来，敏捷方法的其他方面倾向于支持这些关键原则。

• 强调频繁的客户协作会产生用户反馈，同时保持对需求变化的灵活性，从而使产品开发可以定期集成该反馈
• 频繁集成到相关的部署配置和环境中，同时不断识别哪些配置和环境仍然相关，以确保产品仍然有价值并与提供反馈的用户相关
• 自组织和提升跨职能团队的作用是在团队内部建立个人问责制，使团队有权确定如何以有效方式最好地消除障碍，而不会受到团队中预先分配的角色和管理层次的阻碍