敏捷架构是什么
敏捷中的架构采用演进式思路：不追求一次把设计做完，而是通过探针验证关键假设、通过架构决策记录沉淀结论、通过持续集成与自动化测试保证系统随时可集成。架构关注点并没有消失，它从一次性的前期设计转为持续的决策与反馈循环。前提是工程基础具备：没有自动化回归能力就大规模重构，等于把风险直接推到交付节奏上。
基本信息
| 演进式设计 | 在迭代中持续调整结构，避免一次性大设计 |
|---|---|
| 架构决策记录 | 记录背景、备选方案、决策与后果，含未采纳方案的理由 |
| 持续集成 | 频繁合并主干，控制分支存活时间与集成痛感 |
| 自动化回归 | 核心路径自动化覆盖，支撑重构与频繁发布 |
| 技术债管理 | 显式登记并排序，与功能工作在同一待办中竞争 |
典型使用场景
- 技术选型争议无法在会上收敛，需要用小范围探针验证后再决策
- 跨团队共享组件，需要把接口约定与演进规则写成决策记录
- 重构需求长期被功能挤压，需要在待办中显式排序并预留容量
- 新成员上手慢，需要从决策记录中理解现有结构的来由
- 集成频繁失败，需要缩短分支存活时间并强化主干质量门禁
架构决策记录模板
架构决策记录模板
标题：用一句话概括决策，如「订单服务采用事件驱动而非同步调用」
背景：当前约束与驱动因素（性能、团队能力、合规、时间窗口）
选项：列出至少两个备选方案及其代价，含维持现状
结论：选择了什么、为什么，以及未选择方案被放弃的原因
后果：遗留风险、需要后续验证的点与复核条件实践与目标
| 实践 | 做法 | 目标 |
|---|---|---|
| 演进式设计 | 按迭代调整结构，避免前期冻结全部设计 | 让设计随认知更新 |
| 决策记录 | 背景、选项、结论与后果留档 | 约束不靠口口相传 |
| 持续集成 | 频繁合并主干并保持主干可发布 | 集成问题早暴露 |
| 自动化回归 | 核心路径自动化覆盖 | 重构不必靠人工回归兜底 |
架构决策记录的价值在事后：半年后有人问为什么这么设计时，记录能给出当时的约束与取舍，而不是靠当事人回忆。