数据结构
网络
关系数据库管理系统 (RDBMS)
操作系统
Java
MS Excel
iOS
HTML
CSS
Android
Python
C语言编程
C++
C#
MongoDB
MySQL
Javascript
PHP
物理学
化学
生物学
数学
英语
经济学
心理学
社会学
服装设计
法学敏捷软件开发流程及其原则？
介绍
在软件工程中，软件开发占据了整个过程的大部分。软件开发本身意味着将整个开发过程划分为多个阶段，例如设计、产品管理、项目管理等。世界各地的组织遵循各种软件开发方法来成功地进行项目管理。
不同的组织使用各种方法，例如敏捷方法、瀑布模型、DevOps 部署、快速应用程序开发等，它们各有优缺点。然而，由于其迭代开发方法，敏捷软件开发方法在全球范围内被广泛使用。
什么是敏捷软件开发流程？
在我们了解敏捷方法是什么之前，让我们先看看传统的瀑布模型。在瀑布模型中，整个开发过程以更顺序的方式进行，项目被划分为多个阶段。在初始阶段，定义需求，然后进入构建阶段。构建过程完成后，产品进入测试阶段，然后是部署。
虽然瀑布模型在初始需求分析期间为需求和项目范围的变更提供了充足的余地，但在后期阶段却缺乏灵活性。同样，由于客户在构建过程中参与度不高，当测试阶段开始并且不幸发现一些严重的错误时，有时整个过程需要从头开始。
为了避免瀑布模型中遇到的所有这些问题，组织开始采用敏捷模型。在敏捷开发中，整个过程以更迭代的方式进行，项目被划分为不同的冲刺。敏捷允许持续改进和更好的客户互动和参与，并且在任何阶段都非常灵活地应对需求变化。
瀑布模型主要关注产品完成，而敏捷模型主要关注客户参与和满意度。敏捷不关注阶段，而是关注按冲刺进行的小规模发布，并优先考虑客户反馈。与瀑布模型不同，瀑布模型将所有流程划分为各个阶段，一个阶段接着一个阶段，而敏捷模型的所有流程都是迭代的，并在每个冲刺中重复。
例如，在瀑布模型中，设计阶段后是开发阶段，开发阶段后是测试阶段，而在敏捷开发中，每个冲刺都包含设计过程、开发过程和测试过程。在每个冲刺结束时进行用户验收测试。这使得团队互动得到增强和提高，客户参与项目更多。与瀑布模型不同的是，瀑布模型在开发阶段完成后才进行测试，而在敏捷开发中，开发人员和测试人员一起工作。
敏捷软件开发流程的类型 -
虽然敏捷本身可以定义为一种软件开发方法，它有一套自己的思想和原则，或者更像是一份宣言，但有不同类型的模型可以将其应用于实际的开发过程中。虽然所有这些方法中都体现了敏捷的核心思想，但执行方式和关注点却使一种方法与另一种方法区别开来。让我们看看不同类型的敏捷流程：
Scrum -
Scrum 是一种广为人知且常用的敏捷类型，通常在小型团队中使用。它主要关注于管理开发团队中的流程。它使用 Scrum 看板，并将整个开发过程划分为冲刺。虽然冲刺的持续时间可能在 2 周到 1 个月之间变化，但每个冲刺都由分析、开发和用户验收定义。
Scrum 还关注团队互动和有效的客户参与。Scrum 团队中的人员扮演着不同的角色，例如：
**Scrum Master** - Scrum Master 负责安排会议、团队组建以及整个冲刺式开发的整体管理。他还负责处理开发过程中遇到的任何障碍。
**产品负责人** - 产品负责人负责创建和维护产品待办事项列表，这是一个包含特定冲刺所有开发计划或需求的存储库或仪表板。产品负责人还根据每个冲刺中任务的优先级顺序分配和管理需求。
**Scrum 团队** - 负责开发或完成任务并成功执行每个冲刺的开发团队。
对于每个冲刺，产品负责人都会准备产品待办事项列表，其中包含该特定冲刺的需求或任务以及用户故事。一旦为该冲刺待办事项列表选择任务，开发团队就会处理这些任务并按冲刺将其执行为产品。Scrum Master 管理整个冲刺过程，并确保计划顺利执行。
每天都会举行大约 15 分钟的简短会议，称为每日 Scrum 或站立会议，Scrum Master 在此会议上获取有关产品待办事项列表的状态更新，并尝试找出是否有任何阻碍进一步行动的障碍。一些非功能性测试类型包括负载测试、兼容性测试、可用性测试、可扩展性测试等等。
看板
看板方法在某种程度上类似于 Scrum。由大野耐一开发，它来源于日语单词“看板”，指的是在产品生产周期中遵循的指令卡。它是一种更直观的可视化方法，非常依赖于它的看板，类似于 Scrum 看板，其中包含开发过程的完整工作流程安排。
与 Scrum 不同的是，Scrum 只将冲刺任务添加到看板中，而看板将所有与生产计划相关的任务都以卡片的形式添加到看板中。通常，任务被分为三列，例如已完成的任务、待办事项、正在进行的任务。与 Scrum 不同的是，看板中基于优先级的任务完成是可选的，它可以在一个地方包含与整个开发周期相关的所有任务。
极限编程 (XP)
极限编程，简称 XP，优先考虑客户满意度。由 Kent Beck 开发，XP 要求客户和开发人员有更高水平的参与。客户需求频繁变化的开发案例可以选择 XP，因为它在生产的任何时间都灵活地应对变化。
它专注于短期交付，并在整个项目中设置检查点，以分析需求是否发生变化并相应地采取行动。小的交付和迭代开发周期以更混乱的方式发生，没有任何清晰的画面。然而，一旦整个开发完成，它就变得有意义了。XP 在很大程度上取决于其开发团队的协调能力。极限编程有五个阶段：
规划 -
初始阶段，客户和开发人员会面，讨论开发的需求和范围。根据客户的输入，开发团队为整个开发准备简短的迭代用户故事或开发周期。根据创建的故事，定义项目的持续时间和成本。
设计 -
在此阶段，所有用户故事都被分解成更小的任务，并对执行进行进一步的分析。甚至在设计过程中也会规划开发标准，例如类和方法名称、体系结构和格式等。同时为这些迭代任务准备测试用例。对于可能出现的问题，甚至还会讨论应急计划和解决方案。
编码 -
最重要的阶段，根据计划进行开发，包括基于需求的编码以及同时进行的文档更新，以便向客户更新当前状态。设计过程中定义的编码标准和体系结构得到严格遵守，每周工作时间严格控制在 40 小时以内。
测试 -
编码完成后，开始进行用户验收测试。XP 将测试集成到编码阶段本身，以便测试和开发同时进行。根据测试结果，消除错误，然后产品经过基于客户需求的客户验收测试。测试通过后，产品连同测试结果一起交付给客户。
结束 -
在此阶段，产品交付后，团队等待客户和管理层的反馈。根据反馈，他们再次遵循相同的计划-编码-测试迭代，直到客户验收测试通过。团队还在生产过程中提供技术支持，以防出现进一步的问题。
水晶方法
水晶方法更像是一个通用术语，包含多种敏捷方法。根据水晶方法，应根据团队规模、项目的重要性、项目优先级等因素选择不同的方法框架。
不同类型的水晶方法包括：
**水晶清晰** - 团队成员少于 8 人
**水晶黄色** - 团队成员 10 至 20 人
**水晶橙色** - 团队成员 20 至 50 人
水晶红 (Shuǐjīng Hóng) − 由 50 到 100 名团队成员组成
与其他敏捷方法类似，水晶方法也从计划开始，其中根据客户需求和可行性分析定义任务。然后是实际的开发周期。水晶交付也提倡快速和短期的交付。整个过程中计划安排大约 2 个或更多个交付周期，并集成同步测试。测试结束后，交付产品以及测试结果。开发完成后，团队将处理客户反馈以及生产支持。
精益开发 (Jīngyì Kāifā)
虽然精益本身是一种独立于敏捷的方法，但基于其原则和工作机制，它也被认为是一种敏捷类型。精益方法诞生于丰田，专注于价值、原则以及更好的编码标准和实践。其主要目标是以更低的生产成本加快开发速度。精益方法基本上有 7 个原则，它们是：
删除所有对客户需求无用的内容。
鼓励具有完整性和纪律性的高质量开发。
记录整个开发过程以创建知识。
在对客户需求有完整了解之前，不要开始计划和设计。
专注于更快地交付给客户。
专注于优化代码，消除错误和 bug。
尊重、激励和赋能团队。
特性驱动开发 (Tèsè Qūdòng Kāifā) −
特性驱动开发方法（FDD）依赖于并优先考虑其开发人员，因为它更注重设计和开发。与其他敏捷方法类似，它专注于多个小型开发周期，其中重点严格在于设计、编码和分析。
因此，基于特性需求，计划设计和开发周期，并在每个周期结束时执行单元测试和代码检查。它更注重严格的文档编制和计划。一旦特性列表得到充分记录和理解，团队就开始进行开发。
动态系统开发方法 (Dòngtài Xìtǒng Kāifā Fāngfǎ) −
动态系统开发方法（DSDM）是一种快速行动开发 (RAD) 模型，其重点更多地放在开发上，而不是计划和设计。DSDM 是基于对通用 RAD 框架的需求而形成的。虽然团队承担了大量的责任并积极参与其中，但所有开发工作都具有灵活性，可以在需求变更的情况下进行调整。
与其他敏捷方法类似，DSDM 也专注于更好的团队参与和互动、迭代开发周期中的最佳产品交付、客户满意度和频繁交付。
敏捷原则 (Mǐnjié Yuánzé) −
虽然敏捷本身更像是一种思想或宣言，但如上所述，它有不同的实现形式。然而，仔细观察这些方法，可以发现它们都有一些共同的框架或一些基本思想，所有这些方法都是基于这些思想的。根据敏捷宣言，共有 12 条原则或指导方针，所有敏捷方法都遵循这些原则：
敏捷提倡尽早并持续地交付有价值的软件。这意味着虽然客户满意度是敏捷的主要关注点之一，但客户总是希望更快地交付，尽早或按时交付是让客户满意的一种方式，因为归根结底，他们主要关心的是最终产品，而不是整个过程。
在开发的任何阶段都灵活应对变化。敏捷的主要关注点之一是客户满意度，敏捷的全部内容都是关于客户的投入和参与，包括在开发过程中的任何时间点整合需求变化。
在整个开发过程中进行频繁且短期的交付。这些交付可以根据周期/冲刺持续时间每周或每月进行，以便定期向客户更新开发的当前状态。
敏捷提倡业务人员和开发人员之间的透明度，并要求他们一起工作，这有助于更好地协调、风险管理以及从技术和业务角度理解产品开发流程。
敏捷提倡激励团队中的个人。通过提供更好的生产环境并为他们提供所有支持、动力和尊重，将会有一个充满动力并相互信任的团队，这对于提高生产力非常有效。
虽然技术进步为我们提供了许多替代的沟通方式，但敏捷认为面对面的沟通是开发团队之间以及与开发团队沟通的最有效方式。
敏捷专注于周密的计划和设计，以便清楚地了解用户需求。敏捷鼓励持续关注有效的设计和技术卓越，通过遵循最佳代码标准来实现这一点。这可以通过定期进行代码检查、技术评审和基于评审的重构来实现。
敏捷提倡可持续发展。开发人员、用户和赞助者应该一起工作，以便以恒定的速度交付产品。由于需求变化以及开发过程中的阻塞是不可避免的，因此整个团队必须一起工作，以便持续进行交付过程。
工作的软件是衡量进展的主要标准。简单来说，如果最终产品无法正常工作，那么任何计划、设计或整体开发过程都没有意义。正常工作的最终软件产品是敏捷过程成功的关键。
简洁——最大限度地减少未完成的工作量——至关重要。简单来说，就是用最少的努力获得最大的成果。敏捷提倡去除不必要的任务，优先处理能够以较少而有效的工作量产生最大影响的活动。
最佳的架构、需求和设计源于自组织团队。敏捷提倡鼓励和欣赏团队中那些对整个开发过程充满热情、承担任务责任并在彼此之间通过有效的沟通分享想法的积极分子。这将导致一个由积极进取、高价值的团队成员组成的团队，他们拥有主人翁意识，共同努力提高生产力。
定期团队反思如何提高效率，然后调整其行为。改进和变化总是有空间的。敏捷提倡团队成员应该专注于自我改进。他们应该定期进行分析并努力改进整体交付或开发过程。
结论 (Jiélùn) −
敏捷方法诞生于 90 年代的技术困境。敏捷宣言是在考虑健康的开发环境和快乐的客户的情况下制定的。没有什么是完美的，即使在敏捷过程中，人们仍然面临一些问题。然而，在一个不断变化的技术竞争激烈的世界中，我们仍然可以期待敏捷宣言中不断改进和变化，以获得更好的开发体验。
5K+ 次浏览
