敏捷

• 敏捷是一种有时间限制的迭代方法，可以逐步而不是一次全部构建项目。
• 敏捷是一种在整个软件中促进开发和测试的连续迭代的实践。

什么不是敏捷?

• 进行会议团队每天进行10-15分钟的频繁会议，他们认为进行频繁会议将是敏捷的。但是，只有以下会议不会敏捷。
• 随时更改需求可以随时更改需求，所以它不是敏捷的。例如，客户想要添加一些新功能并希望同时更新更改，那么这将不是敏捷的。
• 非结构化开发假设您没有遵循任何计划，并且在Adhoc的基础上工作，那么在进行Adhoc测试时，测试人员会随机测试应用程序，而无需遵循任何文档和测试设计技术，因此这不是敏捷的。
• 没有文档如果公司不提供文档，则说明它不是敏捷的。

什么是敏捷?

• 敏捷是一种哲学，即，一套决定开发软件的价值观和原则。
• 敏捷基于迭代增量模型。在增量模型中，我们以增量创建系统，其中每个增量都是单独开发和测试的。

上图显示了敏捷模型如何逐步工作。

什么是价值观?

在敏捷中，您需要执行上表中提到的所有八项任务。但是，我们必须确保左任务比右任务具有更高的优先级。

• 个人和交互，过流程和工具假设团队在软件中发现任何问题，然后他们搜索另一个流程或工具来解决问题。但是，在敏捷中，最好与客户，经理或团队就问题进行互动，并确保问题得到解决。
• 工作软件，需要全面的文档，但需要文档，但非常需要工作软件。敏捷并不是说不需要文档，但是非常需要工作软件。例如，您有20页的文档，但没有该软件的单个原型。在这种情况下，客户将不满意，因为最终客户需要文件。
• 客户协作，过度合同谈判合同谈判很重要，因为他们要制定软件预算，但是客户协作比过度合同谈判更重要。例如，如果您坚持要求或流程，那么不要去寻求我们已经协商的合同。您需要与客户互动，收集他们的需求。
• 响应计划，对变化做出响应在瀑布模型中，所有事情都已计划好，即何时完成每个阶段。有时您需要在软件的中间实现新的要求，因此您需要具有多功能性才能对软件进行更改。

注意：根据敏捷方法论，应将左任务比右任务赋予更高的优先级。

敏捷原则

• 我们的首要任务是通过尽早并持续交付有价值的软件来满足客户。根据敏捷原则，客户就是他们的一切。无论客户有什么需求，他们有任何问题或想要添加新的要求，他们总是优先考虑客户。听客户说他们的话，并向他们提供优质的软件。
• 它欢迎不断变化的需求，甚至在开发的后期。敏捷过程利用变化来满足客户的竞争优势。在瀑布模型中，如果要在软件中间进行任何新更改，则整个过程将再次执行。因此，瀑布模型是刚性的而不是通用的。敏捷说，工作就像这样，以便可以将新更改轻松地集成到软件中。
• 频繁交付工作软件，从几周到几个月不等，而更倾向于缩短时间范围。就像瀑布模型一样，当开发整个系统时，仅将其交付给客户，而敏捷则表示不要等待太久，而要等待几周或几个月。无论您开发了什么，都可以向客户进行演示，这可以使客户对软件有个初步的了解。
• 在整个项目中，业务人员和开发人员必须每天一起工作。这意味着客户，客户和团队应每天进行互动。
• 围绕有积极性的人建立项目，为他们提供所需的环境和支持，并信任他们能够完成工作。敏捷说，相信您的团队，客户，公司。假设给团队成员一个任务，然后提供他需要的所有资源，例如文档，系统，信息研究等。
• 向开发团队内部传达信息的最有效方法是面对面的交谈。假设在某些情况下，您需要与客户，开发团队进行交互，通常是通过邮件或电话进行的，但是最好进行面对面的对话。
• 工作软件是进度的主要衡量标准。敏捷说，开发的内容既不是通过文档，也不是您的项目经理说的，开发的软件数量或工作量是进度的衡量标准。
• 敏捷过程促进可持续发展。赞助商，开发人员和用户应能够无限期地保持恒定的步伐。敏捷说，使您的团队的交付保持恒定，以便团队应有固定的工作时间，这意味着如果公司的工作时间为8个小时，则团队每天应工作8个小时。
• 持续关注技术卓越性和良好的设计可增强敏捷性，这意味着团队成员应具有良好的技术水平，以便在进行任何更改后可以进行良好的设计，然后可以轻松地将其合并到软件中。
• 最好的体系结构，需求和设计来自自组织团队。无论架构团队进行什么设计，他们都必须确保与开发团队一起坐下来讨论软件的架构。
• 团队会定期思考如何提高效率，然后相应地调整和调整其行为。该原则表示，团队应该经常开会，以便他们可以讨论他们面临的问题并可以有效解决。