JIRA敏捷

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

什么不需要敏捷？

• 主持会议
  团队每天进行10-15分钟的频繁会议，他们认为频繁的会议将是敏捷的。但是，只有以下会议才会敏捷。

• 需求随时变化
  需求可以随时更改，那不需要敏捷。例如，客户想要添加一些新功能并希望同时更新更改，那么这将不是敏捷。

• 非结构化发展
  假设您没有遵循任何计划并且您正在开发Adhoc，那么它不是敏捷的，其中Adhoc测试，测试人员随机测试应用程序而不遵循任何文档和测试设计技术。

• 没有文档
  如果公司没有制作文档，那么它不是敏捷的。

什么是敏捷？

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

下图显示了敏捷模型如何逐步工作 -

什么是价值？

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

• 个人和互动，优先于过程和工具
  假设团队在软件中发现任何问题，然后他们搜索另一个流程或工具来解决问题。但是，在敏捷中，最好与客户，经理或团队就问题进行互动，并确保问题得到解决。

• 工作软件，优先于文档
  需要文档，但是更需要工作软件。敏捷并不是说不需要文档，但是更需要工作软件。例如，您有20页的文档，但您没有软件的一个原型。在这种情况下，客户端就会不满意，因为最终客户端需要一个原型。

• 客户协作，优先于合同谈判
  合同谈判在制定软件预算时很重要，但客户协作比合同谈判更重要。例如，如果您坚持要求或流程，那么就不要签订我们已经协商的合同。您需要与客户互动，收集他们的需求。

• 遵循变更，优先于遵循计划
  在瀑布模型中，一切都是有计划的，即，在什么时间，每个阶段都将完成。有时您需要在软件中间实现新要求，因此您需要具备多种功能才能对软件进行更改。

注意：根据敏捷方法，左侧任务应优先于右侧任务。

敏捷原则

• 首要任务是通过尽早和持续交付有价值的软件来满足客户。根据敏捷原则，客户就是他们的一切。无论客户需要什么，他们都有任何问题或想要添加新的要求，他们总是优先考虑客户。倾听客户的意见，并为客户提供高质量的软件。

• 它欢迎不断变化的要求，甚至在开发的后期。敏捷流程利用变革为客户带来竞争优势。在瀑布模型中，如果要在软件中间进行任何新的更改，则整个过程将再次完成。因此，瀑布模型是刚性的而不是通用的。敏捷可将这样的工作可以很容易地将新的变化整合到软件中。

• 经常提供工作软件，从几周到几个月，优先考虑更短的时间尺度。在瀑布模型中，当整个系统开发出来时，只有它被传递给客户，而敏捷说不要等待太久，等待几周或几个月。无论您开发了什么都要向客户端演示，这样就可以向客户提供您在初始阶段正在开发的软件的每个功能。

• 业务人员和开发人员必须在整个项目中每天一起工作。这意味着客户，客户和团队应该每天进行交互。
• 围绕有动力的个人建立项目，为他们提供所需的环境和支持，并信任他们完成工作。敏捷相信你的团队，客户和公司。假设给团队成员一个任务，然后提供他需要的所有资源，如文档，系统，信息研究等。
• 向开发团队内部和内部传达信息的最有效和最有效的方法是面对面交谈。假设有些情况需要与客户进行交互，开发团队通常通过邮件或电话进行，但最好进行面对面交谈。
• 工作软件是进步的主要衡量标准。敏捷无论是通过文档还是项目经理所说的内容，开发或工作的软件数量都是进度的衡量标准。
• 敏捷过程促进可持续发展。赞助商，开发者和用户应该能够无限期地保持稳定的步伐。敏捷说，让你的团队在交付时保持不变，这样团队应该有固定的工作时间意味着如果公司的工作时间是8小时，那么团队应该在一天工作8小时。
• 持续关注技术卓越和良好的设计提高灵活性意味着团队成员在技术上应该是合理的，以便他们可以做出好的设计，如果做出任何改变，那么它们可以很容易地融入软件中。
• 最好的架构，需求和设计来自自组织团队。无论架构团队进行何种设计，他们都确保他们与开发团队坐在一起并讨论软件的架构。
• 团队定期反思如何变得更有效，然后调整并相应地调整其行为。这个原则说团队应该经常见面，以便他们可以讨论他们面临的问题，并且可以有效地解决。