对于某些类别的软件和某些类型的软件项目，敏捷软件工程是传统软件工程和敏捷软件工程之间可接受的折衷方案。敏捷程序可以在短时间内提供高质量的系统。它强调开发者和消费者之间持续沟通与合作的必要性。
为了有效执行具有较短上市时间和不断变化的公司需求等质量的离岸软件开发项目，我们使用敏捷软件开发过程模型。频繁交付客户的迭代软件开发是敏捷软件开发的基本策略，它可以立即解决离岸开发的主要问题之一：缺乏对项目进度的洞察力。
客户满意度、增量软件交付、小型项目团队（由软件工程师和利益相关者组成）、非正式方法和最少的软件工程工作产品都是敏捷软件工程概念的一部分。敏捷软件工程原则将功能软件增量的及时交付置于分析和设计之上。
在项目开发过程中，敏捷团队可能会适应变化。
敏捷开发承认项目计划需要具有适应性。
敏捷性培养了促进开发人员和消费者之间沟通的团队结构和思维方式。
客户和开发人员不再因敏捷而分开。
敏捷性强调了快速交付操作软件的价值，而忽视了中间工作项的相关性。
如果项目团队能够自由地简化活动并以消除非必要工作项的方式进行准备，则任何软件过程都可以从敏捷性中受益。
敏捷流程建立在三个基本假设之上 -
很难预见哪些客户的优先事项或需求会发生变化，哪些不会。
多种软件开发和设计任务相互交织（构造用于证明设计）
从规划的角度来看，分析、设计和测试并不像人们希望的那样可预测。
为了应对不确定性，必须逐步调整敏捷流程。增量适应需要基于短期内提供的软件增量（可执行原型）的评估的客户输入。
最高目标是通过按时并一致地交付有用的软件来满足客户。
应该欢迎法规的变化。即使在开发过程的后期，容忍变化也被视为为客户赢得竞争优势。
经常交付功能强大的软件，倾向于缩短交付时间（例如，每 2 或 3 周）
在项目期间，业务人员和开发人员必须每天进行协作。
围绕积极进取的人制定计划，为他们提供所需的氛围和支持，并信任他们完成任务。
在开发团队中，面对面的接触是最有效的知识传递技术。
工作软件是最重要的进步指标。
敏捷方法鼓励长期开发，因此开发人员和客户应该能够永远继续从事项目。
对卓越技术和智能设计的持续关注可提高敏捷性。
简单性（定义为最大化未完成的劳动量）至关重要。
自组织团队提供最好的架构、需求和设计。
团队考虑如何定期变得更加成功并适当地改变他们的行为。
敏捷开发团队的成员必须具备以下特征 -
权限
一个共同的目标
合作
决策能力
解决模棱两可问题的能力
相互尊重和信任
自组织
极限编程 (XP)
适应的软件开发 (ASD)
开发动态系统的方法 (DSDM)
Scrum
水晶
面向特征的设计 (FDD)
灵活的建模 (AM)
使用了面向对象的方法。
最重要的行为
组织（按客户价值创建和排序的用户故事）
概念化（简单设计优先，CRC卡和设计原型只是工作产品，鼓励使用重构）
编码的过程（侧重于单元测试来练习故事，强调使用结对编程来创建故事代码，持续集成，并利用冒烟测试）
检查（在编码之前创建的单元测试是使用自动化测试框架实现的，以鼓励使用回归测试、集成和验证测试，每天进行，验收测试侧重于客户可见的系统特性和功能）
当一组自治代理协同工作以解决超出任何参与者能力范围的问题时，就会发生自组织。
自组织团队、人际合作以及个人和团队学习都得到了强调。
适应性循环的特点
阶段 -
使命驱动
基于组件
迭代
限时
想象力（启动项目并进行适应性周期规划）
协作很重要（需要一个固定团队的团队合作，联合应用程序开发是首选的需求收集方法，创建了迷你规范）
自我教育（组件实施和测试，焦点小组提供反馈，正式技术审查，事后分析）
通过在安全环境中采用增量原型，为开发和管理满足紧迫期限的系统提供框架。
使用帕累托原则（80%的项目可以交付，20%需要交付整个项目）
每个增量仅具有足够的功能以允许您转到下一个。
时间框用于通过固定时间和资源来决定在每个增量中将提供多少功能。
遵循的原则
活跃用户的参与
拥有决策权的团队
对可交付成果的接受基于其对业务目的的适用性。
为了获得精确的业务解决方案，需要迭代和增量开发。
在整个开发过程中所做的所有修改都可以撤销。
在高层次上，需求是基线。
测试贯穿整个生命周期。
利益相关者以协作和合作的方式一起工作
在整个生命周期中发生的活动
可能性研究（确定要求和约束）
业务研究（建立提供业务价值所需的功能和信息要求）
功能模型的迭代（生成一组增量原型以向客户展示功能）
设计和构建的迭代（重新访问原型以确保它们为最终用户提供商业价值，可能与功能模型迭代同时发生）
付诸行动（最新迭代放置在操作环境中）
Scrum 原则 -
小型工作组被用来增加沟通，减少开销，并最大限度地扩大非正式的知识交流。
为了保证创造出最好的结果，这个过程必须适应技术和商业上的困难。
该过程产生可以检查、更改、测试、记录和扩展的定期增量。
开发工作和从事这项工作的人被划分为整洁、低耦合的部门。
随着产品的构建，测试和文档被执行。
允许您随时声明产品已完成。
开发活动由流程模式定义。
积压的工作（为客户提供商业价值的需求或功能的优先列表，可以随时添加项目）
Sprints 是一种涉及跑步的练习（实现其中一个 backlog 项目所需的工作单元，必须符合预定义的时间框，受影响的 backlog 项目被冻结）
Scrum 会议（每天 15 分钟的会议）涵盖以下主题： 自上次会议以来完成了什么？你遇到了哪些挑战？到下一次会议召开时，将完成什么？
演示（将软件增量交付给客户进行评估）
主要目标是提供功能性软件，次要目的是为下一个游戏进行设置，这是一种在资源受限的创新和交流游戏中优先考虑敏捷性的开发策略。
晶体的基本原理 -
面对面的交流总是更便宜、更快捷。
随着程序变得更加严格，团队变得负担过重并且难以应对项目工作的突发奇想。
随着项目越来越大，团队越来越大，流程越来越繁重。
随着项目变得越来越重要，过程的各个方面将需要变得更加正式。
随着反馈和沟通变得更加高效，对中间工作项的需求减少了。
流程、形式和文书工作都受到纪律、能力和理解的影响。
不在重要项目路径上的团队成员可能会花空闲时间开发产品或帮助那些在的人。
在 1 到 3 个月的时间内，采用增量开发技术。
反思研讨会在项目开始前、增量开发过程中以及增量交付之后举行。
晶体的方法论
清晰（小型、低关键性项目）
橙色（较大的、中等关键的项目）
Orange Web（典型的电子商务应用）
面向对象的软件工程过程模型在实践中
可在两周或更短时间内部署的客户价值功能
FDD的理念
强调团队成员之间的协作。
基于特征的解构和软件增量集成用于控制问题和项目复杂性。
利用口头、图形和文本方式交流技术信息
增量开发、设计和代码检查、SQA 审计、度量收集和模式使用都有助于提高软件质量（分析、设计、构建）
构成框架的动作
创建一个综合模型（包含一组描述要构建的应用程序的业务模型的类）
列出特征（从领域模型中提取的特征，特征被分类和优先排序，工作被分成两周的块）
制定逐个功能的计划（根据优先级、工作量、技术问题、进度依赖性评估功能）
基于特征的设计（选择与特征相关的类，编写类和方法序言，开发初步设计细节，将所有者分配给每个类，所有者负责维护自己工作包的设计文档）
逐个功能构建（类所有者将设计转换为源代码并执行单元测试，由首席程序员执行集成）
用于成功建模和记录软件系统的轻量级、基于实践的范例。
建模原则 -
一个有目标的模型
使用多种模型
只拿你需要的东西（只保留具有长期价值的模型）
内容的重要性大于表现的重要性。
您应该熟悉用于开发它们的模型和工具。
本地化您的适应。
收集需求并对分析建模
合作找出消费者想要做什么。
在创建需求模型之后，继续与客户进行协作分析建模。
建筑建模
初步架构源自分析模型。
建筑模型必须在环境方面准确且对开发人员友好。