敏捷开发

• 敏捷是一种时间盒、迭代的方法，用于逐步构建项目，而不是一次性完成。
• 敏捷是一种在整个软件开发过程中促进持续迭代开发和测试的实践。

什么不是敏捷？

• 举行会议
  团队每天频繁召开 10-15 分钟的会议，他们认为频繁召开会议就是敏捷。然而，仅是以下会议并不会使你变得敏捷。
• 随时更改需求
  如果可以随时更改需求，那么它就不是敏捷的。例如，客户想要添加一些新功能并希望同时更新更改，那么这不会是敏捷的。
• 非结构化开发
  假设您没有遵循任何计划，并且您正在临时工作，那么它就不是敏捷的，其中临时测试，测试人员随机测试应用程序，而不遵循任何文档和测试设计技术。
• 没有文档
  如果公司没有制作文档，那么它就不是敏捷的。

什么是敏捷开发？

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

上图显示了敏捷模型如何以增量方式工作。

什么是价值观？

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

• 个体和互动，重于流程和工具
  假设团队在软件中发现任何问题，然后他们搜索另一个流程或工具来解决该问题。但是，在敏捷中，最好与客户，经理或团队进行关于问题的互动，并确保问题得到解决。
• 可工作的软件，重于全面的文档
  需要文档，但更需要可工作的软件。敏捷并不是说不需要文档，但更需要可工作的软件。例如，您有 20 页的文档，但您没有软件的单个原型。在这种情况下，客户不会感到满意，因为最终，客户需要文档。
• 客户合作，重于合同谈判
  合同谈判很重要，因为它们制定了软件的预算，但是客户合作比合同谈判更重要。例如，如果您坚持需求或流程，请不要签订我们已经谈判过的合同。您需要与客户互动，收集他们的需求。
• 响应变化，重于遵循计划
  在瀑布模型中，一切都是计划好的，即在什么时间完成每个阶段。有时您需要在软件中间实施新的需求，因此您需要精通更改软件。

注意：根据敏捷方法，左侧任务应比右侧任务具有更高的优先级。

敏捷原则

• 我们最高的优先级是通过早期和持续交付有价值的软件来满足客户。根据敏捷原则，客户对他们来说就是一切。无论客户需要什么，他们有任何问题或想要添加新需求，他们总是优先考虑客户。倾听客户所说的话，并向他们提供高质量的软件。
• 它欢迎不断变化的需求，即使是在开发后期。敏捷流程利用变化来获取客户的竞争优势。在瀑布模型中，如果在软件中间进行任何新的更改，则需要再次完成整个过程。因此，瀑布模型是僵化的并且不是通用的。敏捷说工作就像这样，以便可以轻松地将新更改纳入软件。
• 经常交付可工作的软件，从几周到几个月不等，最好选择较短的时间。就像在瀑布模型中一样，当整个系统开发完成后，只会将其交付给客户，而敏捷则说不要等待太久，仅等待几周或几个月即可。无论您开发了什么，都向客户提供演示，这让客户对您在初始阶段正在开发的软件有所了解。
• 业务人员和开发人员必须在整个项目中每天一起工作。这意味着客户，客户和团队应每天进行互动。
• 围绕积极进取的个人构建项目，为他们提供他们需要的环境和支持，并信任他们可以完成工作。敏捷说，相信您的团队，客户，公司。假设将任务交给团队成员，然后提供他所需的所有资源，例如文档，系统，信息研究等。
• 向开发团队内部和外部传递信息的最有效方法是面对面的对话。假设在某些情况下您需要与客户，开发团队进行交互，通常通过邮件或电话进行交互，但是最好进行面对面的对话。
• 可工作的软件是衡量进度的主要标准。敏捷说，无论是通过文档还是项目经理所说，已经开发出的东西，开发或工作了多少软件才是衡量进度的标准。
• 敏捷流程促进可持续发展。发起人，开发人员和用户应该能够无限期地保持稳定的步伐。敏捷说，使您的团队在交付方面保持不变，以便团队应具有固定的工作时间，这意味着如果公司的工作时间为 8 小时，则团队每天应工作 8 小时。
• 持续关注技术卓越和良好的设计可以提高敏捷性，这意味着团队成员在技术上应能胜任，以便他们可以进行良好的设计，如果进行任何更改，则可以轻松地将其纳入软件中。
• 最佳的架构，需求和设计来自自我组织的团队。无论架构团队做出什么设计，他们都要确保与开发团队坐在一起并讨论软件的架构。
• 团队定期反思如何变得更有效率，然后相应地调整和调整其行为。该原则说，团队应经常开会，以便他们可以讨论他们面临的问题，并且可以有效地解决这些问题。