术语“敏捷方法论”是指鼓励在整个项目的软件开发生命周期中进行持续开发和测试的过程。与瀑布范式不同，在敏捷软件测试风格下，开发和测试操作是同时进行的。
将公司需求的愿景转化为软件解决方案的最简单和最成功的方法之一是使用敏捷软件开发方法。持续规划、学习、改进、团队协作、进化开发和早期交付都是用于定义敏捷软件开发方法的术语。它增加了面对变化的适应性。
突出了敏捷软件开发的四个基本价值。
个人和团体之间围绕流程和工具的互动
工作软件胜过详尽的文档。
与客户合作优先于合同谈判。
根据战略适应变化
这个敏捷项目管理教程将教你如何 -
什么是敏捷方法论，它是如何工作的？
瀑布模型与敏捷模型
Scrum
产品积压
Scrum方法论
Scrum 方法论流程：
极限编程(XP)是一种编程(XP)
极限编程阶段 -
晶体的方法论
开发动态软件 (DSDM) 的方法
面向特征的设计 (FDD)
使用精益原则进行软件开发
看板
灵活的指标
敏捷模型和瀑布模型是两种截然不同的软件开发方法。尽管它们在方法上有所不同，但这两种方法有时可能是有效的，这取决于需要和项目类型。
| 敏捷模型 | 瀑布模型 |
|---|---|
| Definition of Agile methodology: Agile approaches advocate for an incremental and iterative approach to software development. | 瀑布模型 - 软件开发从开始到结束按逻辑顺序进行。 |
| In software engineering, the Agile process is split down into discrete models that designers work on. | 设计过程不分为几个模型。 |
| Early and regular chances for the client to inspect the product and make decisions and adjustments to the project are provided. | 该产品仅在项目完成后对客户可见。 |
| The product is only visible to the client after the project. | 与瀑布范式相反，敏捷模型被认为是非结构化的。 |
| Because they are so plan-focused, waterfall models are more secure. | 小项目可以在短时间内完成。很难预测大型项目的开发时间。 |
| It is possible to estimate and finish a wide range of projects. | 可以在项目期间更正错误。 |
| The whole product is only tested at the end. If a requirement mistake is discovered or revisions are required, the project must be restarted from the beginning. | 开发方式为迭代式，项目在短迭代（2-4周）内完成。几乎没有什么计划。 |
| The development process is divided into phases, each of which is substantially larger than an iteration. Each phase concludes with a full summary of the next phase. | 软件开发优先于文档。 |
| Documentation is a high responsibility, and it may be used to teach employees and update software with the help of another team. | 每次迭代都有一个测试步骤。它可以在部署新功能或逻辑时实施回归测试。 |
| After a lengthy implementation period, all of the designed features are supplied all at once. | 开发人员和测试人员协作。 |
| Separate from the developers are the testers. | 每次冲刺后完成用户验收。 |
| User acceptance is completed after each sprint. | 项目的用户批准在结论中完成。 |
| It necessitates strong collaboration with developers, as well as joint analysis of needs and planning. | 开发人员不参与需求或计划阶段。通常，测试和编码之间存在时间间隔。 |
敏捷测试采用各种敏捷方法，如下所述 -
SCRUM 是一种敏捷开发方法，专注于基于团队的开发环境中的任务管理。Scrum 是由橄榄球比赛期间发生的动作形成的。Scrum 提倡在小团队中工作，并相信赋予开发团队权力（比如 7 到 9 名成员）。Agile 和 Scrum 有三份工作，他们的职责如下 -
Scrum大师
Master 负责组织团队，召开 sprint 会议，清除开发障碍。
产品所有者
产品负责人负责创建产品待办事项列表，确定其优先级，并确保在每次迭代时交付功能。
Scrum 小组
团队监督并安排他们的工作以完成冲刺或周期。
这是一个用于跟踪需求的存储库，包括每个版本必须满足的需求（用户故事）的数量。产品负责人应该对其进行跟踪并确定优先级，并且应该将其提供给 Scrum 团队。团队还可以请求包含、修改或删除新的需求。
以下是 Scrum 测试流程 -
Sprint 是 Scrum 的迭代。
产品待办列表是一个列表，其中包含创建最终产品所需的所有信息。
在每个 Sprint 期间，从产品待办列表中选出最重要的用户故事并翻译成 Sprint 待办列表。
该团队致力于已建立的冲刺积压工作。
团队仔细检查日常工作。
团队在冲刺之后提供产品功能。
当客户的需求或规格不断变化，或者当他们不确定系统的运行时，极限编程方法就派上用场了。它鼓励在较短的开发周期内多次“发布”产品，从而提高系统效率并提供一个检查点，可以快速合并任何客户需求。XP 以客户为中心创建软件。
故事用于收集业务需求。停车场是保存所有这些故事的地方。
发布基于称为迭代的较短周期，在此技术下涵盖 14 天的时间范围。每次迭代都涉及开发、单元测试和系统测试等步骤，每个阶段都会为程序添加或多或少的功能。
在敏捷 XP 方法中，六个阶段概述如下 -
利益相关者和赞助商识别
基础设施需求
信息收集和安全相关信息
服务水平协议 (SLA) 及其条款
在停车场讲故事
在停车场，优先考虑故事。
通过擦洗估计故事
Iteration SPAN是一个术语，用来描述一个人的次数(Time)
开发团队和 QA 团队都需要安排他们的资源。
任务被分解
对于每个作业，准备一个测试场景。
回归自动化框架
编码
单元级别的测试
执行手动测试场景。
生成缺陷报告
回归测试用例从手动转换为自动
第二次迭代回顾
在每次迭代结束时进行审查
小团体发行
回归测试
演示和评估
根据要求创建新故事。
根据每次迭代后收到的反馈改进流程
启动试点计划
训练
生产启动
保证服务水平协议
检查您的 SOA 方法。
生产协助
有两个故事板可用于每天监控工作，为方便起见，下面给出了它们。
纸板故事
这是将所有故事以便签的形式存储在板上的典型方法，以跟踪日常 XP 活动。最好切换到在线表格，因为此手动过程需要更多的工作和时间。
在线故事板
可以使用在线应用程序 Storyboard 保存故事。它可以被多个团队用于不同的目标。
水晶方法论的三个原则是基础。
创建开发团队、进行初步可行性研究、生成初始策略以及微调开发技术都是特许阶段的一部分。
循环交付- 在初级开发期间，有两个或多个交付周期来开发产品。
发布策略由团队更新和完善。
通过一个或多个程序测试集成周期，实现了一部分需求。
向实际消费者提供完全集成的产品。
检查项目策略和使用的开发技术
总结 - 此阶段包括部署到用户环境、部署后评估和反思等活动。
DSDM 是一种基于快速应用程序开发 (RAD) 软件开发方法的敏捷项目交付方法。DSDM 的关键特征是用户有义务积极参与，团队被赋予决策权。使用 DSDM，积极的重点转移到定期的产品交付上。DSDM 采用了多种策略。
时间拳击
MoSCoW 规则
原型制作
DSDM 项目有七个阶段。
项目前期
可行性研究
商业研究
功能模型的迭代
设计和施工的迭代
执行
项目后
该策略侧重于“开发和构建”功能。与其他敏捷软件工程方法不同，FDD 概述了必须为每个功能独立完成的高度精确和简短的工作阶段。域演练、设计检查、促进构建、代码检查和设计都是其中的一部分。FDD 根据以下标准创建产品。
领域对象的建模
基于特征的开发
组件和类的所有权
值得关注的球队
检查
配置管理
规则结构
显示了进展和结果。
“准时生产”的前提是精益软件开发过程的基础。其目标是在降低成本的同时加快软件开发。精益开发的过程可以分为七个部分。
减废
加强学习
推迟你的承诺（尽可能晚地决定）
准时交货
增加团队的自主性
提高诚信度
优化整个流程。
看板是一个日语术语，指的是一张卡片，其中包含在产品完成过程的每个步骤中完成产品所需的所有信息。这种框架或方法广泛用于软件测试，特别是在敏捷方法中。
下表突出显示了看板和 Scrum 之间的主要区别 -
| Scrum | 看板 |
|---|---|
| Tests must be split down in scrum method so that they may be performed in one sprint. | 不需要特定的物品尺寸。 |
| Prescribes a product backlog that is prioritized. | 不需要优先级。 |
| For each iteration, the Scrum team commits to a certain amount of work. | 承诺是一种选择。 |
| The use of a burndown chart is required. | 不需要特定的物品尺寸。 |
| A scrum board is reset after each sprint. | 看板是顽强的。它限制了可能处于工作流状态的事物的数量。 |
| It is not possible to add things to an ongoing iteration. | 它可以在容量允许的情况下添加对象。 |
| Indirectly, WIP is restricted. | WIP 非常受限制。 |
| Iterations with a set time limit are required. | 有时间限制的迭代是一种选择。 |
以下是一些可以收集以确保有效使用敏捷的指标 -
阻力系数
对冲刺目标没有贡献的工作时间
减少共享资源的数量和非贡献活动的数量，以提高阻力系数。
新估计值可能会增加阻力系数的百分比，如下所示： 新估计值 =（旧估计值 + 阻力系数）
速度
已转变为冲刺准备功能的待办事项（用户故事）的数量。
已引入的单元测试数量有所增加。
完成每日构建所需的时间
在先前版本或更早的迭代中发现的错误
生产缺陷泄漏
敏捷项目管理需要一个多功能的解决方案，它允许您使用看板和燃烧图来衡量进度，同时还允许您管理任务和交流信息。因此，我们提出了以下著名的敏捷工具 -
打
星期一.com
点击