Day23-03｜5.1.3 敏捷模型：在持续反馈中交付价值并控制架构风险

本文对应《系统架构设计师教程（第2版）》第5章“软件工程基础知识”5.1.3“敏捷模型”。敏捷模型强调以短周期、可运行增量、持续反馈和拥抱变化的方式开发软件。它不是“不要计划、不要设计、不要文档”，也不是把需求随意交给开发人员，而是在明确产品目标和质量底线的前提下，让团队快速验证假设、优先交付价值并及时调整方向。

一、学习目标与考试定位

完成本节后，应能够解释敏捷软件开发的基本思想和价值观，理解个体与互动、可工作的软件、客户合作、响应变化等原则；能够说明迭代、增量、用户故事、产品待办、冲刺、持续集成和完成定义之间的关系；能够分析敏捷项目中的架构前置、技术债务、质量保障和文档治理；能够在案例题中判断敏捷实践是否真正有效；能够在论文中描述敏捷与架构设计、项目管理和合规要求的结合。

软考高级案例常以“需求变化快、上线频繁、团队跨地域、质量问题多、架构逐渐失控”为背景。题目可能问如何改进迭代、如何处理技术债务、架构师在敏捷团队中的职责或如何兼顾敏捷与文档审计。高分答案需要体现：敏捷是以价值和反馈为中心的工程方法，质量、架构和治理必须进入每个迭代，而不是被推迟到项目末期。

二、敏捷思想的核心

敏捷方法认为，在复杂和不确定的环境中，需求、技术方案和优先级不可能在项目初期被完全预测。与其花很长时间编写一份很快过时的详细计划，不如通过短周期交付可工作的软件，让用户、业务和团队基于真实反馈调整方向。

敏捷通常强调四组价值取向：个体和互动高于过程和工具；可工作的软件高于面面俱到的文档；客户合作高于合同谈判；响应变化高于遵循计划。这些表述不是否定后者，而是说明在发生冲突时，前者更能帮助团队交付价值。文档、合同、计划和工具仍然必要，只是应服务于协作、决策和交付，而不是成为形式主义的终点。

敏捷的逻辑可以概括为：

小批量交付 → 获取真实反馈 → 调整待办和方案 → 持续验证质量 → 逐步形成可演化系统

三、迭代与增量的区别

迭代强调在多个周期中不断学习和完善同一系统，需求、设计、实现和测试都可能根据反馈调整。增量强调每次交付增加一部分可使用的业务能力。敏捷项目通常同时具备这两个特点：以迭代降低不确定性，以增量交付用户价值。

一个合格的增量必须具备“可完成、可验证、可集成、可使用”的特征，不能只是完成数据库表或半成品接口。若每个迭代都只交付代码片段，直到最后才集成，团队实际上仍然面临大爆炸式风险。架构师要推动垂直切片，让一个增量尽量贯穿界面、业务、数据、测试、部署和观测。

四、Scrum 常见角色、工件与事件

Scrum 是常见的敏捷框架。产品负责人负责最大化产品价值、维护产品待办并确定优先级；Scrum Master 负责促进团队理解和使用 Scrum、移除障碍并推动改进；开发团队负责在每个冲刺中构建可用增量。团队应具有跨职能能力，对交付结果共同负责。

常见工件包括产品待办、冲刺待办和产品增量。产品待办描述产品需要完成的工作，并按照价值、风险、依赖和紧迫性排序；冲刺待办是当前周期选择的工作及实现计划；增量是满足完成定义的可用成果。常见事件包括冲刺计划会、每日站会、冲刺评审和冲刺回顾。评审关注产品结果和反馈，回顾关注过程、协作和改进，二者不要混成一次状态汇报。

五、用户故事与验收标准

用户故事通常从用户角色、目标和价值描述需求，例如“作为仓库管理员，我希望在库存低于阈值时收到提醒，以便及时补货”。好的用户故事应具有独立、可协商、有价值、可估算、足够小和可测试等特点。用户故事不是完整规格说明，细节要通过业务、开发、测试和架构人员协作澄清。

验收标准把故事转化为可验证的行为、边界和质量要求。除了功能结果，还要写权限、异常、性能、审计、兼容、数据一致性和可恢复性。例如库存提醒不仅要说明“发送通知”，还要说明重复通知如何处理、消息失败如何重试、不同角色看到什么、延迟目标是多少、消息是否可追踪。

架构师要关注故事中的隐含质量属性。一个看似简单的“导出报表”可能意味着大数据量、异步任务、权限隔离和下载审计；“支持多租户”意味着数据隔离、配置隔离、密钥隔离和租户级限流。若只按功能点估算，架构风险往往会在迭代中后期集中爆发。

六、敏捷中的架构设计

敏捷不等于拒绝前期架构。对于跨迭代共享的核心边界、数据模型、接口契约、安全机制、部署拓扑和质量属性，应在必要程度上提前设计和验证；对于尚不确定的细节，则通过原型、技术故事和架构实验逐步决策。

可以采用“足够前置、持续演化”的架构方式。先建立最小可行架构，明确不可违反的约束和关键决策，再在迭代中依据反馈调整。架构决策记录应简明说明背景、备选方案、选择理由、影响、风险和验证方法。不要为了追求完整而提前设计所有未来功能，也不要以敏捷为借口推迟核心数据和安全边界。

架构工作应进入产品待办，例如性能基线、数据迁移试验、服务拆分、日志规范、灾备演练、依赖升级和技术债务偿还。它们不是“有空再做”的隐形工作，而应具有优先级、估算、验收和责任人。

七、持续集成、自动化测试和完成定义

持续集成要求团队频繁将代码合并到共享主线，并通过自动化构建、单元测试、静态分析、依赖检查和集成测试尽早发现问题。持续交付进一步要求软件处于可发布状态，是否正式发布由业务策略决定。自动化不是越多越好，关键是覆盖高风险、重复性强和适合自动验证的活动。

完成定义（Definition of Done）应明确一个工作项或增量达到完成所需的条件，包括代码完成、评审通过、测试通过、缺陷处理、文档更新、数据库变更、监控配置、安全检查、部署验证和可回滚。没有完成定义，团队容易把“代码写完”误认为“工作完成”，导致缺陷和运维工作被堆积到最后。

八、敏捷项目中的技术债务

为了快速交付，团队可能暂时采用简单方案、跳过重构或降低自动化程度，这些选择形成技术债务。技术债务并非所有临时方案都错误，关键在于是否显式记录、评估利息、安排偿还和设置期限。未记录的债务会变成隐性风险，随着迭代增加导致修改成本、缺陷率和发布风险上升。

技术债务可分为代码、架构、测试、数据、配置、文档和运维债务。治理方式包括在待办中建立债务项、设置容量比例、在重构时补充测试、限制新增重复代码、定期进行架构健康检查、使用质量指标和在重大变更前偿还高息债务。不能只在项目快结束时安排“集中重构周”，那时系统和业务压力通常已经不允许大幅修改。

九、敏捷与合规、合同和大型组织

敏捷项目也需要计划、文档、审计和合同，只是采用滚动规划、轻量文档和可追踪证据。高合规项目可以保留阶段性基线、独立评审和正式签字，同时在阶段内部用短迭代开发。每次迭代保留需求、设计、代码、测试、发布和变更的关联证据，既支持快速反馈，也满足审计追溯。

大型组织需要处理跨团队依赖、共享平台、版本兼容和架构一致性。可建立架构看板、跨团队同步、接口契约、集成环境、发布火车和架构治理规则。治理应提供约束和服务，不能变成审批瓶颈。架构团队可以提供参考实现、公共组件、自动化检查和决策模板，帮助团队在不牺牲自治的情况下保持系统整体性。

十、案例分析：敏捷开发导致架构失控

某电商团队每两周发布一次，业务需求响应很快，但一年后出现重复客户模型、接口命名不一致、线上日志缺失和数据库难以拆分的问题。团队认为“敏捷就是优先交付，不应浪费时间做架构治理”，架构师也只在项目初期画过一张总体图。

问题在于把敏捷误解为局部速度，而忽略了持续交付的质量和演化成本。改造第一步是识别影响多个团队的领域边界、共享数据和核心质量属性；第二步建立轻量架构决策记录、接口规范、数据所有权和版本策略；第三步把日志、监控、自动化测试、重构和数据迁移列入产品待办；第四步通过架构跑道或技术增量提前验证高风险能力；第五步在每次评审和回顾中观察重复实现、变更失败率、缺陷逃逸和依赖耦合；第六步对高息技术债务安排渐进式偿还，而不是停止全部业务进行一次大重构。

改造后的验收应包括业务交付和技术指标：核心功能按期上线，接口契约通过检查，自动化测试覆盖关键路径，日志和链路追踪可用，发布可回滚，重大架构决策有记录，重复模型和跨边界调用逐步减少。这样才能证明敏捷速度和架构健康同时得到改善。

十一、课后练习

练习一：单项选择

关于敏捷模型，下列说法正确的是（ ）。

A. 敏捷不需要需求分析和架构设计；B. 敏捷以短周期、可工作的增量和持续反馈应对变化；C. 每次迭代只要代码完成就算完成；D. 敏捷项目不需要任何文档。

答案：B。敏捷强调价值和反馈，但需求、架构、测试、文档和治理仍需以适当形式持续开展。

练习二：简答题

请说明架构师如何在敏捷项目中避免“只重功能、不重架构”。

参考答案：识别跨迭代共享的核心边界、数据模型、安全和质量属性，进行必要的架构前置设计和风险验证；将架构实验、性能、安全、监控、迁移和重构纳入产品待办；建立轻量架构决策记录、接口契约和完成定义；通过持续集成、自动化测试、架构检查和运行指标持续验证；记录技术债务、评估其利息并安排渐进偿还；在评审和回顾中检查架构健康和质量结果。

练习三：案例分析

某团队采用两周迭代，但每次都把未完成的集成测试和部署工作推迟到项目末期，导致最后集中暴露大量缺陷。请分析原因并提出改进措施。

参考答案：团队把“功能编码完成”当成完成，增量没有真正集成、测试和可部署，短迭代只变成了短周期编码。应重新定义完成标准，把代码评审、单元和集成测试、数据库变更、部署验证、监控、文档和回滚纳入每个增量；采用持续集成和自动化测试，尽早合并主线；将用户故事进行垂直切片，避免一次开发一个完整层次；对环境和测试数据进行自动化管理；每次评审展示可运行结果，每次回顾分析缺陷逃逸和集成延迟，并逐步偿还测试和环境技术债务。

十二、论文素材

论文可写：面对需求变化快和业务持续交付的要求，我采用以价值和反馈为中心的迭代增量方法。通过产品待办管理功能、架构风险和技术债务，优先验证数据一致性、性能、安全和第三方集成等高风险事项；建立最小可行架构和轻量决策记录，在迭代中持续演化；以用户故事、验收标准和完成定义确保每个增量真正可用，并通过持续集成、自动化测试、灰度发布、监控和回滚提高交付质量。对于合规和审计要求，保留需求、设计、代码、测试和发布的追踪证据，在快速响应变化的同时保持架构和过程可控。

十三、今日复盘

敏捷模型用短周期、可工作的增量和持续反馈应对不确定性，核心是交付价值而不是取消工程活动。迭代负责学习和完善，增量负责交付能力；架构、质量、测试、文档、合规和技术债务必须进入每个迭代；架构师应采用足够前置、持续演化的方式维护系统整体性。下一篇进入 5.1.4 统一过程模型（RUP）。