敏捷软件开发的方法论及其应用做基本介绍

菏泽炫佑科技

敏捷软件开发的方法论及其应用做基本介绍

本文将对敏捷软件开发方法及其应用进行基本介绍，并描述团队如何协作以实现共同目标。 本文不仅适合软件开发人员阅读，还适合团队领导、项目经理、产品经理、开发经理、测试人员、QA 经理、QA 工程师、技术文档专家、用户体验设计师以及任何其他参与软件交付的人阅读。 人员。 本文重点介绍技术团队如何协同工作来规划、构建和交付软件。 但没有具体的代码编写，没有具体技术的介绍，也不会介绍微软的技术。 我希望这篇文章可以帮助您提高专业水平和团队效率。

背景

罗伊斯瀑布模型

引自 1970 年 IEEE 论文“the of Large”

本文阐述，在计算机程序设计和开发过程中，无论软件的规模和复杂程度如何，都会经历两个必不可少的阶段：软件分析和编码。 虽然还需要许多其他额外的开发步骤，但它们并没有像软件分析和编码那样对*终产品做出*直接的贡献，反而增加了开发过程的支出。

Royce随后介绍了需要在整个开发过程中额外增加5个重要步骤，以*大限度地消除软件开发中的风险：

**步：先编程

软件程序的初步设计阶段插入在软件需求和软件分析阶段之间。 程序员在此阶段将开始软件的整体初步设计，包括设计、定义和指定数据处理模型、定义系统之间的接口、描述输入输出过程、定义初步操作步骤等，同时开始起草设计方案。易于理解且信息丰富的概述文档，并在整个过程中保持更新。

第 2 步：记录设计

软件开发过程管理的首要原则是强制软件开发过程的文档化。 每个开发阶段都需要形成必要的文档。

步骤3：该过程执行两次

确保软件成功的第二个*重要的标准是正在开发的软件产品是否完全从头开始。 *初开发的计算机程序经常会出现问题，*终交付给客户部署的版本实际上是软件的第二个版本。

第 4 步：计划、控制和监控软件测试

在这个阶段，成本和进度控制风险*高。 由于软件测试过程发生在整个项目进度的后期，如果出现问题，此时备份解决方案是*不可用的。

第 5 步：让客户参与进来

在软件过程中，采用正式的方式让客户参与项目非常重要，以便可以在*终交付时间之前做出承诺。

仔细阅读Royce的论文后，我发现：

不幸的是，从软件过程结果的描述中可以看出，这一阶段的编程并不局限于顺序迭代步骤。

这些是什么东西？

答案是：

敏捷开发本身并不是一种独立的方法论，它涵盖并描述了多种敏捷方法论。 在2001年签署的敏捷宣言中，所包含的方法论包括：Scrum、XP、FDD和DSDM。 后来，软件精益实践也显示出了巨大的价值，并被纳入敏捷开发方法论中。

进一步阅读“敏捷与杰夫”

敏捷宣言的签署者

敏捷软件开发宣言

我们一直在实践中探索更好的软件开发方法，在实践的同时我们也帮助别人。 由此我们确立了以下价值观：

也就是说，虽然右边的物品有它的价值，但我们更看重左边的物品。

敏捷宣言遵循的 12 条原则 我们*重要的目标是通过持续、尽早交付有价值的软件来满足客户的需求。 做好面对需求变化的准备，即使是在开发后期。 敏捷流程掌控变革，为客户带来竞争优势。 频繁地交付工作软件，间隔几周或一两个月，有利于缩短周期。 业务人员和开发人员必须在项目的每一天相互协作。 激发个人的斗志，以个人为核心建设项目。 提供实现您的目标所需的环境和支持以及信任。 无论是团队内部还是团队外部，*有效、*快捷的信息传达方式就是面对面的交谈。 可用的软件是衡量进度的主要标准。 敏捷流程促进可持续发展。 业主、开发商和用户必须能够共同努力，保持稳定、持续的步伐。 通过对卓越技术和良好设计的不懈追求，敏捷能力得以增强。 基于简单性，这是*大限度减少不必要工作的艺术。 *好的架构、需求和设计来自自组织团队。 团队定期反思如何提高绩效并相应地调整自己的行为。

由于缺乏实用指导，许多开发人员经历了噩梦般的项目。 缺乏有效的指导可能会导致项目不可预测、重复错误和浪费精力。 客户会对失控的日程、不断增长的预算和糟糕的质量感到沮丧。 开发人员会感到沮丧，因为经过长时间的努力，他们仍然生产出低质量的软件。

DSDM

DSDM ( ) 通过提供考虑整个软件开发周期的框架，填补了快速应用程序开发 (RAD) 方法中的一些空白。 DSDM方法的主要功能是：

用户必须持续参与迭代增量开发，提高产品交付频率，并在每个阶段进行集成测试。 满足业务需求是接受产品交付FDD的主要依据

FDD() 是一个方法包装器。 它允许您应用一种方法来管理较高级别的项目，同时允许您应用其他方法来管理较低级别的项目。 FDD 主要关注的是能够估计工作量和进度敏捷软件开发的方法论及其应用做基本介绍，并且可以报告整个项目或在非常细粒度的级别上的状态。 它没有指定用于创建计划的特定方法，而是由实施者决定。 其理念是实施者需要观察项目的状况，确认项目的状况，是否在进度之内，是否存在偏差等。

倾斜

精益思想提供了一种系统级优化方法，重点关注减少浪费和提高整个系统流程的价值。 精益在制造业有着丰富的历史，并且近年来在软件开发界变得流行。

精益源于精益制造理论，它提供了一套实现质量、速度改进、客户满意度等的原则。精益软件开发有7个原则：

消除浪费 将质量融入流程 加强学习 延迟承诺 快速交付 尊重和权力下放 整体优化

将这些原则应用于软件产品交付并不是*终目标。 不是说“我们想要精益”，而是使用精益原则来指导决策并选择技术来改进整个系统。 例如，通过TDD（Test-）的实践，在构建初期对软件的完整性进行测试，从而支持构建过程中确保完整性的精益原则。

计划

在计划驱动的开发过程中，如果项目按照计划进行，那么项目就是成功的。 所以在软件开发中，依赖的是需求的稳定性，即明确的、确定的需求。 你可能会说，有稳定的需求太奢侈了，基本上大多数软件项目都无法做到这一点。

在计划驱动的方法中，如果在设计阶段改变需求，成本会更低。 在整个构建过程开始后适应需求的变化将是非常昂贵的。 因此，大部分精力都投入到了规划阶段。 软件开发确实与此不同，因为不能保证会有好的设计来使构建过程可预测。

“如果两者都可以的话，水上和水上都很容易。” -V.

敏捷方法试图打破对需求稳定性的依赖，给出一个适应变化的过程。 这是通过适应性规划和进化设计来实现的。

适应性规划意味着在整个项目周期中都会发生变化，并频繁地重新规划和调整。

进化设计可以通过实施自测试代码、持续集成、重构和简化设计来实现。

所以，一种是价值驱动（敏捷驱动开发）软件开发，另一种是计划驱动（计划驱动开发）。 这并不是说计划驱动的方法没有价值，而是在敏捷驱动的开发中，我们使价值更加可见并更频繁地讨论。

敏捷驱动和计划驱动的方法都依赖于环境条件，这是它们的缺点。 如果不跟踪环境状况问题，可能会导致项目失败。 这里的挑战是如何平衡这两种方法并学习彼此的优势。

计划与敏捷

计划驱动开发和敏捷驱动开发之间有两个根本区别。 首先，在计划驱动的模型中，软件产品的增量是在项目后期交付的。 但在敏捷驱动的模型中，一次只能交付较小的增量，并且交付的频率非常高。 第二个区别是顺序性和并行性之间的区别。 在计划驱动的开发中，一个流程在下一个流程开始之前成功结束。 在敏捷驱动的开发中，活动是并行的，因为规划过程是持续进行的。

尼尔·福特的“计划你的工作，然后实施你的计划”

在计划驱动方法中表现良好的管理团队在敏捷驱动方法中同样能胜任。

如果管理团队缺乏计划驱动方法的能力，那么敏捷方法也是如此。

敏捷

敏捷软件开发的原则和价值观是形成一种方法，帮助团队打破传统流程周期的臃肿，更多地关注如何通过简单的技术实现目标。

那么，目标到底是什么？

那么，每个软件开发人员和开发团队的主要目标是为其雇主和客户提供尽可能高的价值。 项目失败是指未能交付价值。

敏捷开发的关键技术点在于，它将传统瀑布模型中的5个步骤压缩为一周的周期。 它通过在迭代周期中不断交付较小的软件增量来开发软件系统。 并且它允许开发人员在开发过程中进行软件测试和软件评审。 速度、低成本和灵活性是敏捷的本质。

“IT 行业的比率是”，副总裁 Phil 在 2011 年的一份报告中说道。

敏捷流程有很多种：Scrum、BDD（-）、TDD（Test-）、FDD（-）、ADP（）、XP（）等。 尽管如此，许多成功的敏捷团队通过不断调整这些流程，发展出了自己独特的敏捷方法。 其中*常见的就是将Scrum和XP结合起来，使用Scrum来管理多个团队，每个团队单独实践XP。

极限编程（XP）

因为我们需要 XP 并不是城里唯一的游戏。- Pete

极限编程强调团队合作，包括管理者、客户和开发人员。 它通过五种基本方法改进软件项目：沟通、简单、反馈、勇气和尊重。

根据维基百科的定义：“(XP) 是 a which is to 和 to。作为敏捷的一种类型，它“简而言之，which is to 和 where new can be”。

极限编程将一组简单而具体的实践融入到敏捷开发过程中。 极限编程也是开发软件的常用方法。 许多项目团队都采用了这种方法。 其中许多团队已经通过添加和修改流程实践来适应流程。

肯特·贝克的基本思想是：

那么，“推动团队发挥*大能力”到底意味着什么呢？ 这就是下图中所描述的吗？

或者

不，这些都不是极限编程的描述。 我们先来看看极限编程是什么意思。

极限编程包含了一系列符合敏捷价值观和原则的实践。 极限编程是一种独立的方法，而敏捷则代表一类方法。 所以敏捷方法有很多，极限编程只是其中之一。

话虽如此，没有其他方法像极限编程那样定义明确且广泛。 例如，Scrum方法大致相当于极限编程中的计划游戏实践，但引入了整体团队的概念。 尽管细节有所不同，但可以公平地说 Scrum 是极限编程的一个子集。 事实上，许多 Scrum 团队通过在流程中添加一些极限编程实践来增强整个流程，例如验收测试、结对编程、持续集成，尤其是测试驱动开发。

在所有敏捷方法中，极限编程是唯一一种为开发人员日常工作提供深入而严格的纪律的方法。 在这些规范中，测试驱动开发是*具革命性的。 下图是一些更好的极限编程实践。

Scrum

Scrum 是一种迭代增量式敏捷软件开发框架，用于管理软件项目、产品或应用程序的开发。 重点在于“它是一种灵活的、整体性的产品开发策略，开发团队作为一个工作单位，实现共同的目标”，与传统的“顺序开发方法”完全不同。

Scrum 中的角色

在产品的形成过程中，有三个核心角色：

产品拥有者

开发团队

Scrum 教练

Order() 是为产品维护的需求的有序列表。 它由产品特性、产品缺陷、非功能需求等组成。还包括成功交付工作软件所需的任何内容。 在 Scrum 中，无需在项目早期为所有需求创建冗长的文档。 产品订单几乎总是充足的。 而且，随着产品的持续增长和与客户的不断沟通，产品订单总是在变化。

冲刺顺序 ( ) 是一个列表，其中包含开发团队在下一个冲刺中将完成的所有工作。 团队需要从产品订单中为冲刺订单选择故事或功能，直到团队认为订单中的工作足以满足本次冲刺。 开发团队通过询问“我们能完成这个吗？”来向冲刺订单添加故事或功能。

从概念上讲，团队需要从*高优先级的产品订单开始工作，然后选择相关的较低或较高优先级的项目。 但在实际操作中，很难看到团队会一一选择项目。 例如，优先级*高的 5 个项目与优先级较低的 2 个项目直接相关。

敏捷软件开发调查

该调查于2012年8月9日至11月1日期间进行，由该公司赞助。 通过多种软件开发社区渠道，共有4,048人参与投票。 .Net 公司对数据进行分析并编译成报告。

谁了解敏捷？

敏捷为何失败

采用敏捷的障碍

采用敏捷的*常见陷阱

综上所述

优秀的敏捷团队会选择适合他们的管理和技术实践。 在尝试敏捷实践时，通常会有很多借口来解释为什么敏捷不起作用。 那些真正了解敏捷方法好处的人可能已经取得了成功。 而那些一直在寻找失败原因的人，要么真的找到了症结，要么彻底放弃了努力，要么干脆停止了练习。 将这种敏捷称为“假敏捷”。

为了支持这个结论，我找到了一句名言：

“因为我发现计划是，但是是。” - 大卫

当然，*好不要迷恋任何一种特定的方法，因为公司和项目的需求和条件经常发生变化，所以为了项目的成功，我们需要灵活地选择项目管理方法。 没有特定的方法总是*好的解决方案，所以关键是确定哪些方法适合我们的工作，并不断调整它们以满足个人需求。 这是“敏捷”的基础。

参考

炫佑科技专注互联网开发小程序开发-app开发-软件开发-网站制作等