自适应软件开发 - 快速指南

自适应软件开发 - 简介

什么是敏捷？

在文学术语中，“敏捷”一词是指能够快速轻松地行动的人，或者能够快速清晰地思考和行动的人。在商业中，“敏捷”用于描述规划和工作的方式，其中根据需要进行更改是工作的重要组成部分。业务“敏捷性”意味着公司始终能够应对市场变化。

在软件开发中，术语“敏捷”指的是“响应变化的能力——来自需求、技术和人员的变化”。

敏捷宣言

敏捷宣言由软件开发团队于 2001 年发布，强调了开发团队、适应不断变化的需求和客户参与的重要性。

敏捷宣言是 -

我们通过实践并帮助他人开发软件，从而发现更好的软件开发方法。通过这项工作，我们认识到了价值 -

个人以及流程和工具上的交互。
工作软件胜过全面的文档。
客户协作胜过合同谈判。
响应变化而不是遵循计划。

也就是说，虽然右侧的项目有价值，但我们更看重左侧的项目。

敏捷的特点

以下是敏捷的特点 -

敏捷软件开发中的敏捷性侧重于整个团队的文化，其中包括多学科、跨职能的团队，这些团队被授权和自组织。
它促进共同的责任和问责。
促进有效沟通和持续协作。
整个团队的方法避免了延误和等待时间。
频繁和持续的交付可确保快速反馈，从而使团队能够满足需求。
协作有助于在实施、缺陷修复和适应变更时及时结合不同的观点。
进步是持续的、可持续的和可预测的，强调透明度。

敏捷方法论

敏捷方法的早期实施包括 Rational Unified Process、Scrum、Crystal Clear、极限编程、自适应软件开发、功能驱动开发和动态系统开发方法 (DSDM)。2001 年敏捷宣言发布后，这些现在统称为敏捷方法。

在本教程中，我们将学习敏捷方法论 -自适应软件开发。

什么是自适应软件开发？

自适应软件开发是向自适应实践的迈进，将确定性实践留在复杂系统和复杂环境中。自适应软件开发侧重于协作和学习作为构建复杂系统的技术。它是从快速应用程序开发 (RAD) 和进化生命周期的最佳实践演变而来的。随后，自适应软件开发扩展到包括自适应管理方法，并用推测取代了规划。

Jim Highsmith 于 2000 年出版了一本关于自适应软件开发的书。用 Highsmith 的话说 -

“自适应软件开发就像进化模型一样是周期性的，阶段名称推测、协作、学习反映了日益复杂的系统的不可预测领域。适应性发展在两个关键方面比其进化遗产更进一步。首先，它明确地用涌现取代了决定论。其次，它不仅仅是生命周期的改变，而是管理风格的更深层次的改变。”

SDLC 模型 - 演变

软件开发生命周期 (SDLC) 模型是一个描述软件开发项目每个阶段执行的活动的框架。

在软件开发生命周期中，活动分五个阶段执行 -

需求收集- 收集要开发的软件的需求。这些要求将采用客户/用户可以理解的语言。建议使用领域特定术语。
分析- 从实现的角度分析收集的需求，并编写软件规范以涵盖功能需求和非功能需求。
设计- 此阶段涉及根据选择的开发技术确定软件架构和实现细节。
构建- 在此阶段，开发代码、单元测试、集成、集成测试并生成构建。
测试- 已构建软件的功能测试在此阶段完成。这还包括非功能性需求的测试。

有两种方法可以执行这些活动 -

规范性- SDLC 模型将为您提供按照框架定义的规定方式执行活动的方法。
自适应- SDLC 模型将为您提供执行活动的灵活性，并需要遵循某些规则。敏捷方法大多遵循这种方法，每种方法都有其规则。然而，遵循自适应或敏捷方法并不意味着软件的开发不遵循任何规则。这会导致混乱。

您需要明白，我们不能说某个特定的 SDLC 模型是好还是坏。它们每个都有自己的优点和缺点，因此适合特定的环境。

当您为您的项目选择 SDLC 模型时，您需要了解 -

您的组织背景
您的技术背景
你的团队组成
您的客户背景

例如，如果软件开发是可预测的，您可以使用规范方法。另一方面，如果软件开发是不可预测的，即需求不完全已知，或者开发团队事先没有接触过当前的领域或技术等，那么自适应方法是最好的选择。

在以下部分中，您将了解在整个行业的软件开发项目执行过程中演变的最流行的 SDLC 模型。您还将了解它们各自的优点和缺点以及它们适合的环境。

SDLC - 瀑布模型

瀑布模型是一种经典的SDLC模型，被广泛了解、理解和普遍使用。它由 Royce 于 1970 年引入，至今仍被业界各个组织作为软件开发的通用方法而沿用。

在瀑布模型中，每个生命周期阶段只有在较早的生命周期阶段完成后才能开始。因此，它是一个没有反馈回路的线性模型。

瀑布模型——优点

瀑布模型的优点是 -

易于理解，易于使用。
为缺乏经验的开发团队提供结构。
里程碑很好理解。
设定要求稳定性。
非常适合管理控制（规划、监控、报告）。
当质量比成本或进度更重要时，效果很好。

瀑布模型 – 缺点

瀑布模型的弱点或缺点是 -

理想化 - 与现实不太相符。
不切实际 - 无法在项目早期期望准确的需求。
不反映更常见的探索性开发的迭代性质。
做出改变既困难又昂贵。
软件仅在项目结束时交付。因此 -
- 延迟严重缺陷的发现。
- 交付过时需求的可能性。
大量的管理开销，对于小型团队和项目来说可能成本高昂。
每个阶段都需要经验丰富的资源——分析师、设计师、开发人员、测试人员。
测试仅在开发完成后开始，并且测试人员不参与任何早期阶段。
跨职能团队的专业知识不会共享，因为每个阶段都是在孤岛中执行的。

何时使用瀑布模型？

您可以使用瀑布模型，如果 -

要求是众所周知的。
产品定义稳定。
技术很好理解。
现有产品的新版本。
将现有产品移植到新平台。
具有结构化跨职能团队的大型组织。
组织内部以及与客户之间也建立了良好的沟通渠道。

进化原型模型

在使用演化原型模型的软件开发中，开发人员在需求阶段构建原型。然后最终用户评估原型并提供反馈。反馈可以是对原型或附加功能的更正。根据反馈，开发人员进一步完善原型。

因此，产品通过原型→反馈→细化原型循环进行演变，因此被称为进化原型。当用户对产品的功能和工作感到满意时，原型代码就会达到最终产品交付所需的标准。

进化原型模型——优点

进化原型模型的优势或优点是 -

客户/最终用户可以在查看原型时直观地了解系统需求。
开发人员向客户学习，因此对于领域或生产环境没有任何歧义。
允许灵活的设计和开发。
与原型的交互激发了对额外所需功能的认识。
可以轻松满足意外的需求和需求变化。
出现了稳定且明显的进步迹象。
交付准确且可维护的最终产品。

进化原型模型——弱点

进化原型模型的弱点或缺点如下 -

在代码修复开发中倾向于放弃结构化开发，尽管这不是模型所规定的。
该模型因其快速而肮脏的方法而名声不佳。
整体可维护性可能会被忽视。
客户可能会要求交付原型作为最终产品，而不给开发人员执行最后步骤（即最终产品标准化）的机会。
项目可以永远继续下去（范围不断扩大），但管理层可能不会意识到这一点。

何时使用进化原型模型？

您可以使用进化原型模型 -

当需求不稳定或需要澄清时
作为瀑布模型的需求澄清阶段
开发用户界面
对于短暂的示威
用于新的或原创的开发
为了实施新技术

SDLC - 迭代增量模型

在迭代增量模型中，首先构建整个系统的部分实现，使其处于可交付状态。添加了更多功能。修复先前交付的缺陷（如果有）并交付工作产品。重复该过程直到整个产品开发完成。这些过程的重复称为迭代。在每次迭代结束时，都会交付产品增量。

迭代增量模型——优点

迭代增量模型的优点或优势是 -

您可以首先制定优先需求。
初始产品交付速度更快。
客户尽早获得重要的功能。
降低初始交付成本。
每个版本都是一个产品增量，以便客户始终拥有可用的产品。
客户可以对每个产品增量提供反馈，从而避免开发结束时出现意外。
可以轻松适应需求变化。

迭代增量模型 – 缺点

迭代增量模型的缺点是 -

需要有效的迭代规划。
需要高效的设计以确保包含所需的功能并为以后的更改做好准备。
需要尽早定义一个完整且功能齐全的系统，以允许定义增量。
需要明确定义的模块接口，因为有些模块接口的开发早于其他模块的开发。
整个系统的总成本并不低。

何时使用迭代增量模型？

迭代增量模型可以在以下情况下使用：

大多数要求都是预先已知的，但预计会随着时间的推移而发展。
要求优先。
需要快速交付基本功能。
项目有很长的开发进度。
一个项目拥有新技术。
该域对于团队来说是新的。

SDLC - 快速应用程序开发模型

快速应用程序开发（RAD）模型有以下阶段 -

需求规划阶段- 在需求规划阶段，需要举办研讨会以结构化的方式讨论业务问题。
用户描述阶段- 在用户描述阶段，使用自动化工具捕获用户信息。
构建阶段- 在构建阶段，在时间范围内使用生产力工具，例如代码生成器、屏幕生成器等，采用“执行直到完成”的方法。
切换阶段- 在切换阶段，执行系统安装、用户验收测试和用户培训。

快速应用程序开发模型 – 优势

快速应用程序开发模型的优点或优势如下 -

通过减少团队成员来缩短周期时间并提高生产率意味着降低成本。
客户在整个周期中的参与可以最大限度地降低无法实现客户满意度和业务价值的风险。
焦点以所见即所得模式 (WYSIWYG) 转移到代码。这清楚地表明正在构建的东西是正确的。
使用建模概念来捕获有关业务、数据和流程的信息。

快速应用程序开发模型 – 弱点

快速应用程序开发模型的缺点或优点如下 -

加速开发过程必须对用户做出快速响应。
永远无法结束的风险。
很难与遗留系统一起使用。
开发人员和客户必须致力于在较短的时间内快速开展活动。

何时使用快速应用程序开发模型？

快速应用程序开发模型可以在以下情况下使用：

用户可以参与整个生命周期。
项目可以是有时间限制的。
功能可以增量交付。

尽管快速应用程序开发模型的优势受到赞赏，但业界很少使用它。

SDLC - 螺旋模型

螺旋模型在瀑布模型中添加了风险分析和 RAD 原型。每个周期都涉及与瀑布模型相同的步骤序列。

螺旋模型有四个象限。让我们详细讨论它们。

第一象限 - 确定目标、替代方案和限制

目标- 功能、性能、硬件/软件接口、关键成功因素等。
替代方案- 构建、重复使用、购买、分包等。
限制- 成本、进度、接口等。

第二象限 - 评估替代方案，识别并解决风险

研究与已确定的目标和限制相关的替代方案。
识别缺乏经验、新技术、时间紧迫等风险。
解决已识别的风险，评估其对项目的影响，确定所需的缓解和应急计划并实施它们。风险始终需要监控。

象限 3 - 开发下一代产品

典型的活动包括 -

创建设计
审查设计
开发代码
检查代码
测试品

第四象限 - 计划下一阶段

典型的活动包括 -

制定项目计划
制定配置管理计划
制定测试计划
制定安装计划

螺旋模型——优势

螺旋法的优点或优点是 -

提供风险的早期指示，而不涉及太多成本。
由于快速原型设计工具，用户可以尽早查看系统。
首先开发关键的高风险功能。
设计不必是完美的。
用户可以密切参与所有生命周期步骤。
来自用户的早期且频繁的反馈。
经常评估累计成本。

螺旋模型 – 缺点

螺旋法的缺点或弱点是 -

可能很难定义目标、可验证的里程碑来表明已准备好进行下一次迭代。
花在规划、重新设定目标、进行风险分析和原型设计上的时间可能是一种开销。
对于小型或低风险项目来说，评估风险所花费的时间可能太大。
对于新团队成员来说，螺旋模型很难理解。
需要风险评估专业知识。
螺旋可能会无限期地持续下去。
在非开发阶段活动期间必须重新分配开发人员。

何时使用螺旋模型？

螺旋模型可以在以下情况下使用：

创建原型是适当的。
风险评估很重要。
项目具有中度至高风险。
用户不确定自己的需求。
要求很复杂。
产品线是新的。
勘探期间预计会发生重大变化。
由于潜在的业务变化，长期项目承诺是不明智的。

SDLC-敏捷方法

敏捷方法基于敏捷宣言，本质上是适应性的。敏捷方法确保 -

团队协作。
客户协作。
持续不断的沟通。
对变化的响应。
工作产品的准备情况。

几种敏捷方法应运而生，通过限时迭代促进迭代和增量开发。尽管敏捷方法具有适应性，但无法绕过特定方法的规则，因此需要严格的实施。

敏捷方法——优点

敏捷方法的优点或优势是 -

早期且频繁的发布。
适应不断变化的需求。
客户和开发人员之间的日常沟通。
围绕积极主动的个人建立的项目。
自组织团队。
简单，专注于立即需要的东西。
无需为未来构建或使代码负担过重。
定期反思调整Behave，提高成效。

敏捷方法 – 弱点

螺旋法的缺点或弱点是 -

客户可用性可能无法实现。
团队应该有经验来遵循该方法的规则。
需要适当的规划来快速决定需要在迭代中交付的功能。
团队应具备估算能力和谈判能力。
团队应具备有效的沟通能力。
新团队可能无法自行组织。
需要在规定的时间范围内进行开发和交付的纪律。
设计需要保持简单且可维护，因此需要有效的设计技能。

何时使用敏捷方法？

敏捷方法可以在以下情况下使用：

申请对时间要求严格。
范围有限且不太正式（正在将敏捷方法扩展到更大的项目，并对某些敏捷方法进行某些扩展）。
组织采用严格的方法。

自适应软件开发 - 进化

早期的SDLC模型更注重稳定性、可预测性和收益递减的实践。互联网平台等行业一直在转向增加回报环境、不可预测、非线性和快速的方法。

自适应软件开发 (ASD) 的发展就是为了解决这些问题。它从管理层的角度将涌现作为最重要的因素，以增强管理产品开发的能力。

用 Jim Highsmith 的话来说，“自适应软件开发框架基于多年的传统软件开发方法经验、快速应用程序开发 (RAD) 技术的咨询、实践和撰写以及与高科技软件公司合作管理其产品开发的经验。做法”。

瀑布模型的特点是线性和可预测性，反馈微弱。它可以被视为计划→构建→实施的序列。

进化生命周期模型（例如螺旋模型）将确定性方法转变为适应性方法，即计划→构建→修订周期。

然而，从业者的心态仍然是确定性的，长期可预测性转向短期可预测性。人们发现，诸如 RAD 之类的进化生命周期模型的实践不太具有确定性。

自适应生命周期

自适应模型是从不同的角度构建的。尽管像进化模型一样具有周期性，但阶段的名称反映了日益复杂的系统的不可预测性。

适应性发展在两个关键方面比其进化遗产更进一步 -

它明确地用涌现取代了决定论。
它超越了生命周期的变化，而是管理方式的更深层次的变化。

自适应软件开发生命周期的三个阶段是 -

推测- 推测取代了确定性词规划、产品规格规划或项目管理任务规划。
协作- 协作代表在两者之间取得平衡
- 以传统项目管理的方式进行管理，以及
- 创建和维护涌现所需的协作环境。

协作活动构建产品，跟上环境变化的步伐。

学习- 学习的目标是开发人员和客户都使用每个开发周期的结果来了解下一个开发周期的方向。

自适应软件开发 - 概念

在本章中，我们将了解自适应软件开发的各种概念。

复杂自适应系统（CAS）理论

圣达菲研究所的布莱恩·阿瑟 (Brian Arthur) 和他的同事利用复杂自适应系统 (CAS) 理论彻底改变了对物理学、生物学、进化论和经济学的理解。

布莱恩·阿瑟 (Brian Arthur) 二十多年来一直试图说服主流经济学家，他们的观点以收益递减、均衡和确定性动态的基本假设为主导，已不足以理解现实。新世界是一个回报递增、不稳定且无法确定因果关系的世界。

这两个世界在Behave、风格和文化上有所不同。他们呼吁 -

不同的管理技术
不同的策略
不同的理解

复杂的软件开发

随着软件应用范围的爆炸式增长，即使是软件开发组织也面临着上述类似的矛盾。

同一个世界以确定性发展为代表，它源自植根于稳定性和可预测性基础的管理实践（用亚瑟的话说，这意味着回报递减）
第二世界的代表是工业从回报递减环境转向递增回报环境，这些环境是不可预测的、非线性的和快速的。

为了解决第二世界的问题，Jig Highsmith 提供了一个框架，即自适应软件开发，它不同于确定性软件开发。

自适应软件开发侧重于解决复杂系统 -

开发生命周期的自适应软件开发。
适应性管理技术需要与传统项目管理实践不同的思维方式。

在本教程中，您可以了解这两种实现。

自适应软件开发（ASD）基于两个角度 -

基于复杂自适应系统 (CAS) 理论的概念视角，如本章第一部分所示。
基于实际的视角
- 拥有多年确定性软件开发方法的经验。
- 有关快速应用程序开发 (RAD) 技术的咨询、实践和写作；并与高科技软件公司合作管理其产品开发。

在本章中，您将了解自适应软件开发的概念视角。

复杂自适应系统 (CAS) 概念

复杂自适应系统（CAS）理论有很多概念。自适应软件开发基于其中两个概念 -

紧急情况
复杂

紧急情况

在复杂的软件产品开发项目中，结果本质上是不可预测的。然而，成功的产品总是在这样的环境中诞生。

正如复杂自适应系统 (CAS) 理论所示，这可以通过涌现来实现。可以通过一个简单的例子来理解，鸟类的集群Behave。

当你观察一群鸟时，你会注意到 -

每只鸟都试图
- 与环境中的其他物体（包括其他鸟类）保持最小距离。
- 将速度与其附近的鸟类相匹配。
- 向附近鸟类的感知中心移动。
该团体没有Behave规则。唯一的规则是关于个体鸟类的Behave。
然而，存在一种突发Behave，即鸟类聚集。当迷失的鸟儿奋力追赶时，鸟群就会绕过障碍物，在另一边重新集结。

这表明了适应性发展中最困难的心智模式变化的要求——从管理和组织个人自由的方式到自发自组织不可预测地出现创造性新秩序的观念。

除了发展之外，从管理角度来看，涌现也是最重要的概念。

复杂

在软件开发环境中，复杂性是指 -

团队中的个人，例如开发人员、客户、供应商、竞争对手和股东，以及他们的数量和速度。
规模和技术复杂性。

自适应软件开发实践

自适应软件开发为软件管理实践提供了不同的视角。在下面的部分中，您可以了解两个重要的实践 - 质量和 RAD，它们都会对收集需求产生影响。

您可以在本教程的“自适应软件开发实践”一章中找到所有实践的详细信息。

质量

在复杂的环境中，“第一次就把事情做好”的古老做法行不通，因为你无法在一开始就预测什么是正确的。您需要有一个目标来产生正确的价值。然而，在复杂的环境中，范围（功能、性能、缺陷级别）、进度和资源等价值要素的组合和排列是如此巨大，以至于永远不可能有一个最佳值。因此，重点是转向在竞争激烈的市场中提供最佳价值。

RAD 实践

RAD 实践通常涉及以下内容的组合 -

进化生命周期
客户焦点小组、JAD 会议、技术审查
限时项目管理
持续软件工程
设有作战室的专门团队

RAD 项目具有固有的适应性、突发性特征。许多 IT 组织反对 RAD。然而，微软和其他公司使用与 RAD 相当的技术生产了极其庞大和复杂的软件，因为这引发了对其基本世界观的质疑。

RAD 实践和 Microsoft 流程都是自适应开发实际应用的示例。给它们贴上标签（即适应性发展）并意识到科学知识体系（即 CAS 理论）的不断增长可以解释它们为何有效。这应该为更广泛地使用这些实践提供基础。

自适应软件开发 - 生命周期

自适应软件开发是从 RAD 实践发展而来的。这些实践中还添加了团队方面的内容。从新西兰到加拿大的公司，针对各种项目和产品类型，都使用了自适应软件开发。

Jim Highsmith 于 2000 年出版了《自适应软件开发》。

自适应软件开发实践提供了适应变化的能力，并且能够适应动荡的环境，产品在几乎不需要规划和学习的情况下不断发展。

ASD 生命周期的各个阶段

自适应软件开发与进化模型一样是循环的，其阶段名称反映了复杂系统中的不可预测性。自适应开发生命周期的阶段是 -

推测
合作
学习

这三个阶段反映了自适应软件开发的动态本质。适应性发展明确地用涌现取代了决定论。它不仅仅是生命周期的改变，而是管理风格的更深层次的改变。自适应软件开发具有动态的推测-协作-学习生命周期。

自适应软件开发生命周期注重结果，而不是任务，结果被识别为应用程序功能。

推测

计划这个术语过于确定性，表明对期望结果具有相当高的确定性。遵守计划的隐性和显性目标限制了经理引导项目朝创新方向发展的能力。

在自适应软件开发中，术语计划被术语推测所取代。在猜测的同时，团队并没有放弃计划，而是承认复杂问题中存在不确定性的现实。推测鼓励探索和实验。鼓励短周期的迭代。

合作

复杂的应用程序不是构建出来的，而是不断发展的。复杂的应用程序需要收集、分析大量信息并将其应用于解决问题。动荡的环境具有很高的信息流动率。因此，复杂的应用程序需要收集、分析大量信息并将其应用于解决问题。这导致了只能通过团队协作来处理的多样化知识需求。

协作需要共同努力产生结果、分享知识或做出决策的能力。

在项目管理的背景下，协作描绘了传统管理技术的管理与创建和维护涌现所需的协作环境之间的平衡。

学习

生命周期的学习部分对于项目的成功至关重要。团队必须不断增强他们的知识，使用诸如以下的实践：

技术评论
项目回顾
客户焦点小组

每次迭代后都应进行评审。开发人员和客户都会检查他们的假设，并使用每个开发周期的结果来了解下一个开发周期的方向。团队学习 -

关于产品变更
关于产品开发方式的基本假设发生了更根本的变化

迭代必须简短，以便团队可以从小错误而不是大错误中学习。

推测 - 协作 - 学习循环作为一个整体

正如您从上面给出的推测-协作-学习周期中观察到的那样，很明显这三个阶段是非线性的并且是重叠的。

我们从自适应框架中观察到以下内容。

没有学习就很难协作，没有协作就很难学习。
不学习就很难推测，不推测就很难学习。
没有合作就很难推测，没有推测就很难进行合作。

生命周期特征

自适应软件开发生命周期有六个基本特征 -

专注于使命
基于特征
迭代
限时的
风险驱动
变化容忍度

在本章中，您将了解自适应软件开发的这六个特征。

专注于使命

对于许多项目来说，指导团队的总体使命都得到了很好的阐述，尽管在项目开始时需求可能是不确定的。使命宣言作为指南，鼓励在开始时进行探索，但在项目过程中关注的范围较窄。使命提供的是边界，而不是固定的目的地。使命陈述和产生这些陈述的讨论为做出关键项目权衡决策提供了方向和标准。

如果没有明确的使命和持续的任务细化实践，迭代生命周期就会变成振荡生命周期，来回摆动，而开发没有任何进展。

基于特征

自适应软件开发生命周期基于应用程序功能而不是任务。特性是在迭代过程中根据客户优先级开发的功能。

当客户提供反馈时，功能可以经过多次迭代而发展。

实施后向客户提供直接结果的应用程序功能是主要的。面向客户的文档（例如用户手册）也被视为一项功能。其他文档（例如数据模型）即使定义为可交付成果也始终是次要的。

迭代

自适应软件开发生命周期是迭代的，重点是频繁发布，以便获得反馈、吸收所得知识并为进一步开发设定正确的方向。

限时的

在自适应软件开发生命周期中，迭代是有时间限制的。然而，人们应该记住，自适应软件开发中的时间限制与时间期限无关。它不应该被用来让团队长时间工作以挑战协作环境或损害可交付成果的质量。

在自适应软件开发中，时间盒被认为是在需要时集中精力并强制做出艰难权衡决策的方向。在变化率较高的不确定环境中，需要有一个周期性的强制功能（例如时间盒）来完成工作。

风险驱动

在自适应软件开发中，迭代是通过识别和评估关键风险来驱动的。

变化容忍

自适应软件开发是变化容忍的，将变化视为整合竞争优势的能力，而不是开发的问题。

自适应软件开发 - 实践

自适应软件开发实践是由持续适应的信念驱动的，生命周期以接受持续变化为常态。

自适应软件开发生命周期致力于 -

持续学习
改变方向
重新评估
展望不确定的未来
开发人员、管理层和客户之间的密切合作

自适应SDLC

自适应软件开发将 RAD 与软件工程最佳实践相结合，例如 -

计划启动。
自适应循环规划。
并行组件工程。
质量审查。
最终质量检查和发布。

自适应软件开发实践可以说明如下 -

如上所述，自适应软件开发实践分为三个阶段：

推测- 启动和规划
- 计划启动
- 为整个项目建立时间范围
- 确定迭代次数并为每次迭代分配一个时间框
- 为每次迭代制定一个主题或目标
- 为每次迭代分配特征
协作- 并发功能开发
- 分布式团队的协作
- 较小项目的协作
- 大型项目的协作
学习- 质量审查
- 从客户角度看结果质量
- 从技术角度看结果质量
- 交付团队的运作和团队成员正在利用的实践
- 项目状况

推测 - 启动和规划

在自适应软件开发中，推测阶段有两项活动 -

引发
规划

Speculate 有五种可以在启动和规划阶段重复执行的实践。他们是 -

计划启动
为整个项目建立时间范围
确定迭代次数并为每次迭代分配一个时间框
为每次迭代制定一个主题或目标
为每次迭代分配特征

计划启动

项目启动涉及 -

设定项目的使命和目标
了解约束
建立项目组织
确定并概述要求
进行初始规模和范围估计
识别关键项目风险

项目启动数据应在初步 JAD 会议中收集，将速度作为主要方面。对于中小型项目，启动可以集中两到五天的时间完成，对于大型项目，启动可以在两到三周的时间内完成。

在 JAD 会话期间，会收集足够详细的需求来识别功能并建立对象、数据或其他架构模型的概述。

为整个项目建立时间范围

应根据项目启动工作产生的范围、功能集要求、估计和资源可用性来确定整个项目的时间范围。

如您所知，推测并不放弃估计，而只是意味着接受估计可能会出错。

迭代和时间盒

根据总体项目范围和不确定性程度决定迭代次数和单个迭代长度。

对于中小型应用程序 -

迭代周期通常为四到八周。
有些项目在两周迭代后效果最好。
有些项目可能需要八周以上的时间。

根据适合您的时间选择时间。一旦决定了迭代次数和每次迭代的长度，就为每次迭代分配一个时间表。

制定主题或目标

团队成员应该为每次迭代制定一个主题或目标。这与 Scrum 中的 Sprint 目标类似。每次迭代都应提供一组可以演示产品功能的功能，使产品对客户可见，以便进行审查和反馈。

在迭代中，构建应该最好每天提供工作功能，从而实现集成过程并使产品对开发团队可见。测试应该是功能开发中持续的、不可或缺的一部分。不应推迟到项目结束时。

分配特征

开发人员和客户应共同为每次迭代分配功能。此功能分配的最重要标准是每次迭代都必须向客户提供一组具有大量功能的可见功能。

在将特征分配给迭代期间 -

开发团队应该提出功能估计、风险和依赖性，并将其提供给客户。
客户应使用开发团队提供的信息来决定功能优先级。

因此，迭代规划是基于功能的，并由开发人员和客户作为团队完成。经验表明，与项目经理基于任务的计划相比，这种类型的计划可以更好地理解项目。此外，基于特征的规划反映了每个项目的独特性。

协作 ─ 并发功能开发

在协作阶段，重点是开发。协作阶段有两项活动 -

开发团队协作并交付工作软件。
项目经理促进协作和并行开发活动。

协作是一种共享创造的Behave，涉及开发团队、客户和经理。信任和尊重促进共享创造。

团队应该合作 -

技术问题
业务需求
快速决策

以下是与自适应软件开发中的协作阶段相关的实践 -

分布式团队的协作
较小项目的协作
大型项目的协作

分布式团队的协作

在涉及分布式团队的项目中，应考虑以下因素 -

不同的联盟伙伴
广泛的知识
人们互动的方式
他们管理相互依赖性的方式

小型项目的协作

在较小的项目中，当团队成员在物理上近距离工作时，应鼓励通过非正式的走廊聊天和白板涂鸦进行协作，因为这被发现是有效的。

大型项目的协作

较大的项目需要额外的实践、协作工具和项目经理交互，并且应根据上下文进行安排。

学习 - 质量审核

自适应软件开发鼓励“实验和学习”的概念。

从错误和实验中学习需要团队成员尽早共享部分完成的代码和工件，以便 -

查找错误
向他们学习
在小问题变成大问题之前发现它们，减少返工

在每次开发迭代结束时，有四个一般类别的东西需要学习 -

从客户角度看结果质量
从技术角度看结果质量
交付团队和实践团队的运作
项目状况

从客户角度看结果质量

在自适应软件开发项目中，获得客户的反馈是首要任务。建议的做法是建立客户焦点小组。这些会议旨在探索应用程序的工作模型并记录客户变更请求。

客户焦点小组会议是促进会议，类似于 jad 会议，但它们不是生成需求或定义项目计划，而是旨在审查应用程序本身。客户对迭代产生的工作软件提供反馈。

从技术角度看结果质量

在自适应软件开发项目中，应重视技术工件的定期审查。代码审查应该持续进行。其他技术工件（例如技术架构）的审核可以每周或在迭代结束时进行。

在自适应软件开发项目中，团队应该定期监控自己的绩效。回顾鼓励团队作为一个团队一起了解自己和他们的工作。

迭代结束回顾有助于定期团队绩效自我审查，例如 -

确定什么不起作用。
团队需要做更多的事情。
团队需要做的事情更少。

项目现状

项目状态审查有助于规划进一步的工作。在自适应软件开发项目中，确定项目状态是基于功能的方法，每次迭代的结束都以已完成的功能为标志，从而产生可工作的软件。

项目状态审查应包括 -

项目在哪里？
项目与计划的区别在哪里？
项目应该在哪里？

由于自适应软件开发项目中的计划是推测性的，因此问题 3 比上面的问题 2 更重要。也就是说，项目团队和客户需要不断地问自己：“到目前为止我们学到了什么？它是否改变了我们对未来发展方向的看法？”

自适应软件开发 - 管理

传统软件管理的流程图如下所示。

传统软件管理的特点是命令控制这一术语。

许多组织都秉承优化、效率、可预测性、控制、严谨和流程改进的传统。然而，新兴的信息时代经济需要适应性、速度、协作、即兴创作、灵活性、创新和灵活性。

哈佛商业评论和管理书籍提出了授权、参与式管理、学习型组织、以人为本的管理等术语，但这些术语都没有被运用到现代组织的管理中。

在自适应软件开发的背景下，差距看起来更大，有必要考虑在其他领域已被证明成功的自适应管理技术。

适应性管理

事实证明，在资源管理者与利益相关者和科学家作为一个团队合作的环境中，适应性管理是成功的，其目标如下：

了解托管系统如何响应人类干预。
未来改进资源政策和实践。

适应性管理背后的原则是，许多资源管理活动都是实验性的，因为它们的结果无法事先可靠地预测。然后将这些实验用作未来改进的学习机会。

适应性管理旨在提高面对新信息以及在利益相关者目标和偏好不同的情况下及时响应的能力。它鼓励利益相关者在调查和更好地理解环境不确定性的同时，约束争议并以有序的方式进行讨论。

适应性管理帮助利益相关者、管理者和其他决策者认识到知识的局限性以及根据不完美信息采取行动的必要性。

适应性管理通过明确以下内容来帮助改变决策：

这些决定是临时的。
管理层的决策不一定总是正确的。
预计会有修改。

有两种类型的适应性管理方法 -

被动适应性管理。
主动适应性管理。

被动适应性管理

适应性管理旨在增强科学知识，从而减少不确定性。

在被动适应性管理中，根据现有信息和理解，选择一个首选的行动方案。监控管理行动的结果，并根据结果调整后续决策。

这种方法有助于学习和有效的管理。然而，在超出所选行动方针的情况下，其提高科学和管理能力的能力有限。

主动适应性管理

主动适应性管理方法在采取管理行动之前审查信息。

然后开发一系列竞争性的、生态系统的替代系统模型和相关响应（例如人口变化；娱乐用途），而不是单一模型。根据对这些替代模型的评估来选择管理选项。

领导力-协作管理

自适应管理最适合自适应软件开发。该方法需要资源管理者，即能够与人合作、允许人为干预并创造友好环境的管理者。

在软件开发中，领导者经常承担这些责任。我们比指挥官更需要领导者。领导者是合作者，与团队并肩工作。协作领导是适应性发展中最受欢迎的实践。

领导者具有以下品质 -

把握并确定方向。
影响相关人员并提供指导。
协作、促进和宏观管理团队。
提供方向。
创造让人才能够发挥创新、创造力并做出有效决策的环境。
要明白，他们偶尔需要发号施令，但这不是他们的主要风格。