敏捷软件开发

一、问题本质：为什么需要敏捷？

1. 软件开发的根本约束（第一性原理）

软件开发并非制造业，而是一个典型的复杂适应系统（Complex Adaptive System），其核心约束来自：

📌 结论：

“先完整设计、再稳定实现”在复杂软件系统中不成立

2. 敏捷的根本目标

敏捷并不是“更快”，而是：

在高度不确定的环境中，以最低的系统成本持续获得正确结果

这意味着三件事：

二、敏捷的价值观层（Why）

敏捷宣言的抽象理解

表层表述 本质含义（稳定认知）
个体和交互 系统性能受限于人类协作效率
可工作的软件 真实反馈只来自可运行系统
客户合作 外部认知必须持续注入系统
响应变化 在不确定系统中，适应优于预测

三、敏捷原则层（How）

原则的系统性分组（重构）

1. 反馈原则（缩短认知闭环）

👉 本质： 缩短“假设 → 验证 → 修正”的反馈回路

2. 变化成本控制原则（工程与设计）

👉 本质： 通过设计与工程纪律，降低系统演化成本

3. 人与组织原则（社会系统）

👉 本质： 优化人类协作系统，而非仅优化流程

四、方法论层（What）：不同方法解决不同核心矛盾

方法不是“最佳实践”，而是问题匹配工具

方法 核心矛盾 系统机制 适用场景
XP 变化导致代码崩溃 工程纪律 技术复杂度高
Scrum 需求不确定 时间盒反馈 产品探索期
Kanban 流程瓶颈与等待 流动控制 服务 / 运维

五、XP：以工程纪律对抗变化成本

XP 的本质

XP 不是开发流程，而是“变化友好型代码系统”的构建方法

核心机制

📌 关键认知：

没有工程纪律，就没有真正的敏捷

六、Scrum：经验主义控制系统

Scrum 的系统模型

Scrum ≠ 会议集合 Scrum = 短周期经验主义反馈控制系统

组件 系统角色
Sprint 控制周期
产品增量 可验证输出
Review 外部反馈
Retro 系统自优化

Scrum 的适用边界

七、Kanban：流动效率系统

Kanban 的本质

Kanban 是基于约束理论与排队论的工作流优化方法

核心原则

📌 看板不是目的，流动才是目的

八、敏捷设计：保持系统可演化

拙劣设计的系统性症状

症状 系统后果
僵化 变化成本指数级上升
脆弱 修改引发连锁破坏
晦涩 认知负担过高
过度设计 资源浪费

敏捷设计目标

在任何时间点，系统都应保持“最小可行复杂度”

九、敏捷 ≠ 无计划：不同时间尺度的计划观

时间范围 计划粒度
1–2 周 详细
1–3 月 粗略
更远 假设

📌 计划不是预测未来，而是为下一次决策提供约束

十、常见反模式（必须警惕）

十一、敏捷的演进视角（成熟度）

个人英雄
   ↓
团队协作
   ↓
仪式敏捷
   ↓
工程敏捷
   ↓
流动效率
   ↓
系统级优化

结语：敏捷的真正内涵

敏捷不是一种方法，而是一种面对不确定世界的系统性生存策略

它要求：

关联内容（自动生成）