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

什么是敏捷？

从文学角度来看，“敏捷”一词指的是能够快速轻松地行动的人，或者能够快速清晰地思考和行动的人。在商业领域，“敏捷”用于描述计划和开展工作的方式，在这种方式中，人们理解到根据需要进行更改是工作的重要组成部分。商业“敏捷性”意味着公司始终能够应对市场变化。

在软件开发中，“敏捷”一词被用来表示“能够应对变化——来自需求、技术和人员的变化”。

敏捷宣言

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

敏捷宣言是：

我们正在通过实践和帮助他人实践来发现更好的软件开发方法。通过这项工作，我们开始重视：

个体和互动高于流程和工具。
可工作的软件高于详尽的文档。
客户合作高于合同谈判。
响应变化高于遵循计划。

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

敏捷的特性

以下是敏捷的特性：

敏捷软件开发中的敏捷性关注于整个团队的文化，拥有赋能的、自组织的多学科、跨职能团队。
它促进共享责任和问责制。
促进有效的沟通和持续的协作。
全团队方法避免了延误和等待时间。
频繁和持续的交付确保了快速的反馈，反过来又使团队能够与需求保持一致。
协作有助于及时结合不同的视角来进行实施、缺陷修复和适应变化。
进度是持续的、可持续的和可预测的，强调透明度。

敏捷方法

敏捷方法的早期实现包括 Rational 统一过程、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 原型设计。每个周期都包含与瀑布模型相同的步骤序列。

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

象限 1 - 确定目标、备选方案和约束条件

目标——功能、性能、硬件/软件接口、关键成功因素等。
备选方案——构建、重用、购买、分包等。
约束条件——成本、进度、接口等。

象限 2 - 评估备选方案，识别和解决风险

根据确定的目标和约束条件研究备选方案。
识别风险，例如缺乏经验、新技术、时间紧迫等。
通过评估风险对项目的影响，确定所需的缓解和应急计划并实施这些计划来解决已识别的风险。始终需要监控风险。

象限 3 - 开发下一级产品

典型活动包括：

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

象限 4 - 规划下一阶段

典型活动包括：

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

螺旋模型——优点

螺旋方法的优点如下：

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

螺旋模型——缺点

螺旋方法的缺点如下：

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

何时使用螺旋模型？

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

创建原型是合适的。
风险评估很重要。
项目属于中高风险。
用户不确定他们的需求。
需求复杂。
产品线是新的。
预计在探索过程中会发生重大变化。
由于潜在的业务变化，长期项目承诺不明智。

SDLC - 敏捷方法

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

团队协作。
客户协作。
持续不断的沟通。
响应变化。
可运行产品的准备就绪。

出现了多种敏捷方法，促进了具有时间盒迭代的迭代和增量开发。尽管敏捷方法是自适应的，但不能绕过特定方法的规则，因此需要有条不紊地实施。

敏捷方法——优点

敏捷方法的优点如下：

尽早且频繁地发布。
适应不断变化的需求。
客户和开发人员之间的日常沟通。
围绕积极进取的个人构建项目。
自组织团队。
简洁性，专注于当前所需。
不为未来构建或使代码负担过重。
定期反思以调整行为以提高效率。

敏捷方法——缺点

螺旋方法的缺点如下：

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

何时使用敏捷方法？

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

应用程序对时间要求很高。
范围有限且不太正式（正在进行将敏捷方法扩展到更大项目的尝试，其中对一些敏捷方法进行了一定的扩展）。
组织采用有条不紊的方法。

自适应软件开发 - 演变

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

自适应软件开发 (ASD) 已经发展起来以解决这些问题。它侧重于将涌现作为管理层最重要的因素，以增强管理产品开发的能力。

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

瀑布模型的特点是线性化和可预测性，反馈很少。它可以看作是计划→构建→实施的序列。

螺旋模型等演化生命周期模型将确定性方法转向自适应方法，采用计划→构建→修改周期。

然而，从业者的思维方式仍然是确定性的，长期可预测性转向短期可预测性。RAD 等演化生命周期模型的实践被发现不太确定性。

自适应生命周期

自适应模型是从不同的角度构建的。虽然像演化模型一样是循环的，但阶段的名称反映了日益复杂的系统的不可预测性。

自适应开发在其演化遗产的基础上进一步发展，主要有两个方面：

它明确地用涌现代替了确定性。
它超越了生命周期的变化，对管理风格进行了更深层次的改变。

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

推测——推测取代了确定性的计划，产品规范的规划或项目管理任务的规划。
协作——协作代表在以下方面取得平衡：
- 以传统项目管理的意义进行管理，以及
- 创建和维护涌现所需的协作环境。

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

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

自适应软件开发 - 概念

本章将阐述自适应软件开发的各种概念。

复杂自适应系统 (CAS) 理论

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

布莱恩·阿瑟花了二十多年时间，试图让主流经济学家相信，他们根植于递减收益、均衡和确定性动力学等基本假设的观点，已经不足以理解现实。新的世界是递增收益、不稳定性和无法确定因果关系的世界。

这两个世界在行为、风格和文化上都大相径庭。它们需要：

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

复杂的软件开发

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

一个世界代表的是确定性开发，它源于植根于稳定性和可预测性基础（用阿瑟的话来说就是递减收益）的管理实践。
第二个世界代表的是那些从递减收益环境转向递增收益环境的行业，这些环境是不可预测的、非线性的和快速的。

为了解决第二个世界的问题，吉姆·海史密斯提出了一个框架——自适应软件开发，它与确定性软件开发不同。

自适应软件开发侧重于解决复杂系统的问题：

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

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

自适应软件开发 (ASD) 基于两个视角：

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

本章将阐述自适应软件开发的概念视角。

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

复杂自适应系统 (CAS) 理论包含许多概念。自适应软件开发基于其中的两个概念：

涌现
复杂性

涌现

在复杂的软件产品开发项目中，结果本质上是不可预测的。然而，成功的产品总是从这种环境中涌现出来。

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

当您观察一群鸟时，您会注意到：

每只鸟都试图
- 保持与环境中其他物体（包括其他鸟类）的最小距离。
- 与其邻近的鸟类匹配速度。
- 向其邻近鸟类的感知质心移动。
群体没有行为规则。唯一的规则是关于个体鸟类的行为。
然而，存在一种涌现行为，即鸟类的集群。当偏离轨道的鸟急于追赶时，鸟群会在障碍物周围分开，并在另一侧重新组合。

这表明自适应开发中最困难的思维模式转变的需求：从管理和组织个体自由的方式转变为创造性的新秩序从自发的自组织中不可预测地涌现出来的概念。

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

复杂性

在软件开发的背景下，复杂性是指：

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

自适应软件开发实践

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

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

质量

在复杂的环境中，“一次做对”的古老做法行不通，因为您无法预测一开始什么才是正确的。您需要目标是产生正确的价值。然而，在复杂的环境中，价值组成部分（如范围（特性、性能、缺陷级别）、时间表和资源）的组合和排列如此之多，以至于永远不会有最佳价值。因此，重点转向在竞争市场中交付最佳价值。

RAD 实践

RAD 实践通常涉及以下组合：

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

RAD 项目具有固有的自适应、涌现的特性。许多 IT 组织反对 RAD。然而，微软和其他公司已经使用与 RAD 相当的技术产生了令人难以置信的大型和复杂的软件，因为它对其基本的世界观提出了质疑。

RAD 实践和微软流程都是自适应开发的实际例子。为它们贴上标签（即自适应开发）并意识到越来越多的科学知识（即 CAS 理论）解释了它们为什么有效。这应为更广泛地使用这些实践提供基础。

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

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

吉姆·海史密斯于 2000 年出版了《自适应软件开发》。

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

ASD 生命周期阶段

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

推测 (Speculate)
协作 (Collaborate)
学习 (Learn)

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

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

推测 (Speculate)

术语“计划”过于确定性，表明对预期结果有相当高的确定性。对计划一致性的隐含和明确目标限制了管理者将项目引向创新方向的能力。

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

协作 (Collaborate)

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

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

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

学习 (Learn)

学习是生命周期中项目成功的关键部分。团队必须不断增强他们的知识，使用以下实践：

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

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

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

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

推测 - 协作 - 学习周期作为一个整体

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

我们从自适应框架中观察到以下几点。

如果没有学习就很难协作，如果没有协作就很难学习。
如果没有学习就很难推测，如果没有推测就很难学习。
如果没有协作就很难推测，如果没有推测就很难协作。

生命周期特征

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

以使命为中心
基于特性
迭代式
限时
风险驱动
容错性

本章将阐述自适应软件开发的这六个特征。

以使命为中心

对于许多项目而言，指导团队的总体使命表达得很好，尽管在项目开始时需求可能不确定。使命陈述充当指南，鼓励在开始时进行探索，但在项目过程中重点会很窄。使命提供边界而不是固定目的地。使命陈述以及由此产生的讨论为做出关键的项目权衡决策提供了方向和标准。

如果没有明确的使命和持续的使命改进实践，迭代生命周期将成为振荡生命周期，来回摆动，开发没有进展。

基于特性

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

当客户提供反馈时，特性可以在几个迭代中不断发展。

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

迭代式

自适应软件开发生命周期是迭代式的，侧重于频繁发布，以便获得反馈，吸取由此产生的经验教训，并为进一步开发设定正确的方向。

限时

在自适应软件开发生命周期中，迭代是限时的。但是，应该记住，自适应软件开发中的限时并不是指时间截止日期。它不应被用来让团队长时间工作，从而挑战协作环境或影响可交付成果的质量。

在自适应软件开发中，限时被认为是关注和强制必要时做出艰难权衡决策的方向。在变化率高的不确定环境中，需要周期性的强制函数（例如限时）来完成工作。

风险驱动

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

容错性

自适应软件开发具有容错性，它将变更视为整合竞争优势的能力，而不是开发的问题。

自适应软件开发 - 实践

自适应软件开发实践源于对持续适应的信念，其生命周期能够接受持续变更作为常态。

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

持续学习
变更导向
重新评估
洞察不确定的未来
开发人员、管理人员和客户之间的密切合作

自适应SDLC

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

项目启动。
自适应周期规划。
并发组件工程。
质量审查。
最终QA和发布。

自适应软件开发实践可以如下所示：

如上所示，自适应软件开发实践分布在以下三个阶段：

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

推测 - 启动和规划

在自适应软件开发中，“推测”阶段有两个活动：

启动
规划

“推测”有五个实践，可以在启动和规划阶段重复执行。它们是：

项目启动
为整个项目建立时间框
确定迭代次数并为每个迭代分配时间框
为每个迭代制定主题或目标
为每个迭代分配功能

项目启动

项目启动包括：

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

项目启动数据应在一个初步的JAD会议中收集，其中速度是主要方面。对于中小型项目，启动可以在集中进行的2到5天内完成，而对于大型项目则需要2到3周的时间。

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

为整个项目建立时间框

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

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

迭代和时间框

根据项目的整体范围和不确定性程度，确定迭代次数和各个迭代的长度。

对于中小型应用程序：

迭代通常为4到8周。
一些项目最适合两周的迭代。
一些项目可能需要超过8周。

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

制定主题或目标

团队成员应为每个迭代制定一个主题或目标。这类似于Scrum中的Sprint目标。每个迭代都应交付一组可以演示产品功能的功能，使客户能够看到产品以进行审查和反馈。

在迭代中，构建应最好每天交付可运行的功能，从而实现集成过程并使开发团队能够看到产品。测试应该是功能开发中持续且不可或缺的一部分，不应推迟到项目结束。

分配功能

开发人员和客户应共同为每个迭代分配功能。此功能分配的最重要标准是每个迭代都必须向客户交付一组具有相当功能的可见功能。

在将功能分配给迭代期间：

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

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

协作 - 并发功能开发

在“协作”阶段，重点是开发。“协作”阶段有两个活动：

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

协作是共享创建的行为，它包含开发团队、客户和经理。共享创建由信任和尊重促进。

团队应在以下方面进行协作：

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

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

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

分布式团队的协作

在涉及分布式团队的项目中，应考虑以下事项：

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

小型项目的协作

在小型项目中，当团队成员在物理上靠近时，应鼓励非正式的走廊聊天和白板涂鸦式的协作，因为这被认为是有效的。

大型项目的协作

大型项目需要额外的实践、协作工具以及项目经理的互动，并应根据具体情况进行安排。

学习 - 质量审查

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

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

查找错误
从中学习
通过在小问题变成大问题之前找到它们来减少返工

在每个开发迭代结束时，有四类需要学习的内容：

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

从客户角度来看结果质量

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

客户焦点小组会议是有组织的会议，类似于JAD会议，但它们不是为了生成需求或定义项目计划，而是为了审查应用程序本身。客户会对迭代产生的可运行软件提供反馈。

从技术角度来看结果质量

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

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

迭代结束后的回顾有助于定期进行团队绩效自我审查，例如：

确定哪些方面不起作用。
团队需要做更多的事情。
团队需要做更少的事情。

项目状态

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

项目状态审查应包括：

项目进展到哪里了？
项目进展与计划相比如何？
项目应该进展到哪里？

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

自适应软件开发 - 管理

下图显示了传统软件管理的流程图。

传统的软件管理的特点是“命令控制”。

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

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

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

自适应管理

自适应管理在资源管理人员与利益相关者和科学家一起作为团队工作，并具有以下目标的环境中已被证明是成功的：

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

自适应管理的原则在于，许多资源管理活动都是实验，因为其结果无法事先可靠地预测。这些实验随后被用作未来改进的学习机会。

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

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

自适应管理有助于改变做出的决策，因为它明确指出：

这些决策是暂定的。
管理层的决策并不总是正确的。
预计会进行修改。

有两种类型的自适应管理方法：

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

被动自适应管理

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

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

这种方法有助于学习和有效管理。但是，它在增强科学和管理能力方面的能力有限，无法应对超出所选行动方案的情况。

主动自适应管理

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

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

领导力合作管理

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

在软件开发中，领导者通常承担这些责任。我们需要领导者而不是指挥官。领导者是合作者，与团队一起工作。协作领导是自适应开发中最受欢迎的做法。

领导者具备以下素质：

掌握并确定方向。
影响相关人员并提供指导。
与团队合作、促进团队合作并进行宏观管理。
提供方向。
创造能够让有才华的人进行创新、创造和做出有效决策的环境。
理解他们偶尔需要指挥，但这并非他们的主要风格。

打印页面