敏捷软件开发方法论
如今，每个技术组织似乎都在为软件开发或它的一种版本实践敏捷方法。 或者至少他们相信他们这样做。 无论您是敏捷应用程序开发的新手还是几十年前使用瀑布式软件开发方法学过的软件开发，如今，您的工作至少都受到敏捷方法论的影响。
但是什么是敏捷方法论？在软件开发中应如何实践？ 实践中，敏捷开发与瀑布有何不同？ 什么是敏捷软件开发生命周期或敏捷SDLC？ 与看板和其他敏捷模型相比，Scrum敏捷是什么？
[DevSecOps：如何将安全性引入敏捷开发和CI / CD]
敏捷于2001年正式启动，当时有17位技术专家起草了敏捷宣言 。 他们编写了敏捷项目管理的四项主要原则，旨在开发更好的软件：
个人与流程和工具之间的互动 通过全面的文档工作软件 客户合作而非合同谈判 响应计划变更
敏捷之前：瀑布方法论的时代
像我这样的老手记得瀑布式方法成为软件开发的金标准的时代。 在开始任何编码之前，软件开发过程需要大量的文档。 通常是业务分析师的人首先编写了业务需求文档，该文档捕获了应用程序中所需的所有业务。 这些业务需求文档很长，详细介绍了所有内容：总体策略，全面的功能规格以及可视用户界面设计。
技术人员获取了业务需求文档并开发了自己的技术需求文档。 本文档定义了应用程序的体系结构，数据结构，面向对象的功能设计，用户界面和其他非功能性要求。
这个瀑布式软件开发过程将最终开始编码，然后进行集成，最后进行测试，然后再将应用程序视为生产就绪。 整个过程可能需要花费几年时间。
我们希望开发人员像完整的文档一样被称为“规范”，就像文档的作者一样。如果我们忘记正确地实施200-200的第77页概述的关键细节，我们常常会受到责备。页面文档。
那时，软件开发本身也不容易。 许多开发工具都需要经过专门的培训，并且当今没有开源或商业软件组件，API和Web服务。 我们必须开发低级的东西，例如打开数据库连接和对数据处理进行多线程处理。
对于基本应用程序来说，团队很大，而通讯工具却很有限。 我们的技术规格是使我们保持一致的要素，我们像圣经一样利用它们。 如果需求发生变化，我们将让业务领导者进行漫长的审查和签字，因为在团队中沟通变更和确定代码非常昂贵。
由于该软件是基于技术架构开发的，因此首先开发了较低级别的工件，然后才开发了相关工件。 任务是由技能分配的，数据库工程师通常首先构造表和其他数据库工件，然后由应用程序开发人员对功能和业务逻辑进行编码，然后再覆盖用户界面。 几个月后，任何人都无法看到该应用程序正常运行，到那时，利益相关者变得烦躁不安，通常对他们真正想要的东西更加精明。 难怪实施更改如此昂贵！
并非您摆在用户面前的所有内容都能按预期工作。 有时，用户根本不会使用任何功能。 有时，一项功能大获成功，但需要重新设计以支持必要的可伸缩性和性能。 在瀑布式世界中，您只有在部署软件之后，经过漫长的开发周期后才了解这些知识。
相关视频：敏捷方法的真正作用
似乎每个人都在谈论敏捷软件开发，但是许多组织对流程的运作方式没有把握。 观看这五分钟的视频，以加快速度。
敏捷软件开发的关键
瀑布式方法于1970年发明，具有革命性，因为它为软件开发带来了规范，以确保遵循明确的规范。 它基于从亨利·福特（Henry Ford）的19装配线创新中获得的瀑布式制造方法，该方法为生产过程的每个步骤提供了确定性，以确保最终产品与最初指定的产品相匹配。
[同样在InfoWorld上：启动devops程序的3种方法]
当瀑布方法论进入软件世界时，计算系统及其应用程序通常是复杂且整体的，需要纪律和明确的结果才能交付。 与今天相比，需求的变化也很缓慢，因此大规模的工作没有那么多问题。 实际上，系统是在假设它们不会改变而是永久的战列舰的前提下建造的。 多年的时间框架不仅在软件开发中很常见，在制造业和其他企业活动中也很常见。 但是，瀑布式的刚性成为互联网时代的致命弱点，因为互联网时代要求速度和灵活性。
当开发人员开始处理Internet应用程序时，软件开发方法就开始发生变化。 许多早期工作是在团队较小，位于同一地点且通常没有传统计算机科学背景的初创公司完成的。 财务和竞争压力迫使网站，应用程序和新功能更快地推向市场。 开发工具和平台响应Swift变化。
这导致我们中的许多人在初创公司中工作，以质疑瀑布式方法论并寻找提高效率的方法。 我们无力承担所有详细的文档，因此我们需要一个更加迭代和协作的过程。 我们仍然在讨论对要求的更改，但是我们更愿意进行试验并适应最终用户的需求。 与企业遗留系统相比，我们的组织结构更少，我们的应用程序也没有那么复杂，因此与购买应用程序相比，我们对构建更加开放。 更重要的是，我们正在尝试发展业务，因此当我们的用户告诉我们某件事不起作用时，我们通常会选择不听他们的话。
我们的技能和创新能力在战略上变得至关重要。 您可以筹集所需的全部资金，但是如果您打算按照“规范”将它们视为从属编码人员，您将无法吸引能够与快速变化的互联网技术合作的软件开发人员。 我们拒绝了提供端到端时间表的项目经理，这些时间表描述了我们应该开发什么，何时发布应用程序，有时甚至是如何构造代码。 我们很难达到瀑布项目经理起草并不断更新的三个月和六个月的时间表。
取而代之的是，我们开始告诉他们如何设计Internet应用程序，并按迭代制定的时间表提供结果。 事实证明，当我们兑现承诺（每隔一周到四周一次）时会做到的话，我们并不差劲。
在2001年，一群经验丰富的软件开发人员聚在一起，意识到他们正在集体实践不同于经典瀑布方法的软件开发。 而且它们并非全部都在初创公司中。 这个包括技术专家Kent Beck，Martin Fowler，Ron Jeffries，Ken Schwaber和Jeff Sutherland的小组提出了“ 敏捷宣言” ，记录了他们对现代软件开发过程应该如何运作的共同信念。 他们强调在文档，自组织而不是严格的管理实践方面的协作，以及在不断变化而不是将自己锁定在严格的瀑布式开发过程中的能力。
从这些原则中诞生了软件开发的敏捷方法论。
敏捷方法中的角色
敏捷软件开发过程始终始于定义用户并记录有关要解决的问题，机会和价值范围的愿景声明。 产品负责人抓住了这一愿景，并与一个或多个多学科团队合作实现了这一愿景。 以下是该过程中的角色。
用户
敏捷过程始终始于用户或客户。 今天，我们经常用用户角色来定义它们，以说明软件所支持的工作流程中的不同角色或不同类型的客户需求和行为。
产品拥有者
敏捷开发过程本身始于要求包括客户内部利益相关者在内的客户的声音。 该人会提炼所有见解，想法和反馈以创建产品愿景。 这些产品愿景通常是简短而直接的，但是它们描绘了客户是谁，正在解决的价值以及如何解决这些问题的策略。 我可以想象Google的原始愿景看起来像是“让具有互联网访问权限的任何人都可以使用简单的关键字驱动界面和一种算法，在搜索结果中将信誉良好的来源排名较高，从而轻松地找到相关的网站和网页。”
我们称此人为产品负责人。 他或她的责任是定义此愿景，然后与开发团队合作使其实现。
为了与开发团队合作，产品负责人将产品愿景分解为一系列用户故事 ，这些故事更详细地说明了目标用户是谁，正在为他们解决什么问题，解决方案为什么对他们很重要以及什么约束和接受标准定义了解决方案。 这些用户故事由产品所有者确定优先级，并由团队进行审查，以确保他们对所要询问的内容有共同的理解。
软件开发团队
在敏捷中，开发团队及其成员的职责与传统软件开发中的职责不同。
团队是多学科的，由具有完成任务的技能的不同人群组成。 因为重点是交付工作软件，所以团队必须完成端到端的功能应用程序。 因此，开发，然后演示了应用程序一部分的数据库，业务逻辑和用户界面，而不是整个应用程序。 为此，团队成员必须合作。 他们经常会面，以确保每个人都对他们正在构建的内容，谁在做什么以及精确地开发软件保持一致 。
除开发人员外，软件开发团队还可以包括质量保证（QA）工程师，其他工程师（例如数据库和后端系统），设计师和分析师，具体取决于软件项目的类型。
[也在InfoWorld上：如何通过左移测试改善CI / CD]
Scrum，看板和其他敏捷框架
许多敏捷框架提供了有关软件开发生命周期的开发流程和敏捷开发实践的详细信息。
最流行的敏捷框架称为scrum。 它关注于称为sprint和会议结构的交付节奏，包括以下内容：
规划-确定冲刺优先级 承诺-团队审查用户故事的列表或待办事项，并确定在sprint持续时间内可以完成多少工作 每日站立会议-团队可以交流其发展状况和策略的最新信息）
Sprint会在演示会上结束，在演示会上向产品所有者展示该功能，然后在回顾会议上，团队讨论进展顺利的过程以及需要改进的过程。
许多组织雇用Scrum管理员或教练来帮助团队管理Scrum流程。
尽管Scrum占主导地位，但还有其他敏捷框架：
看板是一个扇入和扇出的过程，在该过程中，团队从入口板上提取用户故事，并通过分阶段的开发过程将其归纳，直到完成。 一些组织采用混合敏捷和瀑布方法，将敏捷过程用于新应用程序，将瀑布用于旧应用程序。 还有一些框架可以使组织将实践扩展到多个团队 。
尽管敏捷框架定义了流程和协作，但是敏捷开发实践特定于解决与敏捷框架保持一致的软件开发任务。
因此，例如：
一些团队采用结对编程，其中两个开发人员一起编码以驱动更高质量的代码，并使更多的高级开发人员可以指导初级开发人员。 更高级的团队采用测试驱动的开发和自动化来确保基础功能能够提供预期的结果。 许多团队还采用技术标准，以便开发人员对用户故事的解释不仅能带来所需的功能，而且还满足安全性，代码质量，命名约定和其他技术标准。
为什么敏捷方法更好
翻译自: /article/3237508/what-is-agile-methodology-modern-software-development-explained.html
敏捷软件开发方法论
