敏捷软件开发

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

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 月粗略
更远假设

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

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

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

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

结语：敏捷的真正内涵

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

它要求：

关联内容（自动生成）