JIRA 敏捷
JIRA 敏捷
敏捷是一种有时间限制的迭代方法，可逐步构建项目，而不是一次性构建所有项目。
敏捷是一种促进整个软件开发和测试的持续迭代的实践。
什么不是敏捷？
召开会议
团队每天召开 10-15 分钟的频繁会议，他们认为频繁召开会议将是敏捷的。但是，只有以下会议不是敏捷会议。
需求随时变化
需求可以随时变化，那么就不是敏捷。例如，客户想要添加一些新功能并希望同时更新更改，那么这将不是敏捷。
非结构化开发
假设您没有遵循任何计划并且您在 Adhoc 基础上工作，那么它不是敏捷，其中 Adhoc 测试，测试人员随机测试应用程序而不遵循任何文档和测试设计技术。
没有文档
如果公司不制作文档，那么它就不是敏捷。
什么是敏捷？
敏捷是一种哲学，即为软件开发做出决策的一套价值观和原则。
敏捷基于迭代增量模型。在增量模型中，我们以增量方式创建系统，其中每个增量都是单独开发和测试的。
上图展示了敏捷模型是如何以增量方式工作的。
什么是价值观？
| 个人和互动 |
关于流程和工具。 |
| 工作软件 |
文档过于全面。 |
| 客户协作 |
合同谈判 |
| 响应变化 |
过度遵循计划 |
在敏捷中，您需要执行上表中提到的所有八项任务。但是，我们必须确保左侧任务的优先级高于右侧任务。
个人和互动，超越流程和工具
假设团队在软件中发现了任何问题，然后他们会寻找其他流程或工具来解决该问题。但是，在敏捷中，最好就问题与客户、经理或团队进行互动，并确保问题得到解决。
可运行的软件，而不是全面的文档
需要文档，但非常需要可运行的软件。敏捷并不是说不需要文档，而是非常需要可工作的软件。例如，您有 20 页的文档，但您没有该软件的单个原型。在这种情况下，客户会不高兴，因为最终客户需要一份文件。
客户合作，过度合同谈判
合同谈判很重要，因为他们制定了软件预算，但客户合作比过度合同谈判更重要。例如，如果您坚持要求或流程，那么请不要选择我们已经协商好的合同。您需要与客户互动，收集他们的需求。
响应变化，而不是遵循计划
在瀑布模型中，一切都是计划好的，即每个阶段将在什么时间完成。有时您需要在软件中间实现新的需求，因此您需要多才多艺以在软件中进行更改。
注意: 根据敏捷方法论，左边的任务应该比右边的任务更优先。
敏捷原则
我们的首要任务是尽早持续交付有价值的软件，让客户满意。根据敏捷原则，客户就是他们的一切。无论客户需要什么，他们有任何问题或想要增加新的要求，他们总是优先考虑客户。倾听客户的意见，并为他们提供优质的软件。
它欢迎不断变化的需求，即使是在开发后期。敏捷流程利用变化来获得客户的竞争优势。在瀑布模型中，如果软件中间有任何新的变化，则整个过程都要重新进行。因此，瀑布模型是僵化的，不是通用的。敏捷说工作就像这样，新的变化可以很容易地合并到软件中。
频繁交付可运行的软件，从几周到几个月不等，并且倾向于较短的时间范围。就像在瀑布模型中一样，当整个系统被开发出来时，只将它交付给客户，而敏捷则说不要等待太久，只等待几周或几个月。无论您开发了什么，都可以向客户演示，这样可以让客户大致了解您在初始阶段正在开发的软件。
业务人员和开发人员必须在整个项目中每天一起工作。这意味着客户、客户和团队应该每天互动。
围绕积极进取的个人构建项目，为他们提供所需的环境和支持，并相信他们能够完成工作。敏捷说相信你的团队、客户、公司。假设向团队成员分配了一项任务，然后提供他需要的所有资源，例如文档、系统、信息研究等。
向开发团队和在开发团队内部传达信息的最有效和最有效的方法是面对面交谈。假设在某些情况下，您需要与客户、开发团队进行互动，通常通过邮件或电话进行，但最好是面对面交谈。
工作软件是衡量进度的主要标准。敏捷表示，开发的任何内容都不是通过文档或您的项目经理所说的，已开发或工作的软件数量是进度的衡量标准。
敏捷流程促进可持续发展。赞助商、开发商和用户应该能够无限期地保持恒定的步伐。敏捷说，让你的团队在交付中保持不变，这样团队应该有固定的工作时间，这意味着如果公司的工作时间是 8 小时，那么团队应该每天工作 8 小时。
对技术卓越性和良好设计的持续关注可增强敏捷性，这意味着团队成员应具备良好的技术能力，以便在进行任何更改时能够做出出色的设计，然后可以轻松地将其纳入软件中。
最好的架构、要求和设计来自自组织团队。无论架构团队做了什么设计，他们都会确保与开发团队坐在一起讨论软件的架构。
团队会定期反思如何提高效率，然后相应地调整和调整其行为。该原则表示团队应该经常开会，以便他们可以讨论他们面临的问题并能够有效地解决。
