响应变化高于遵循计划
传统的软件开发是瀑布式的，它提倡设定计划，遵循计划，按部就班的实施，其中一部分的重要产出就是大量完备的文档。
但是敏捷宣言中明确的指出：工作的软件高于详尽的文档！这并不是说，敏捷中文档不重要，但在敏捷中有哪些文档呢？只记录结果文档。
这又是问什么呢？这就要与敏捷宣言中的另一句话：响应变化高于遵循计划，一起结合着看！
进行过敏捷的团队都了解用户故事，用户故事是在迭代计划中团队承诺的 feature，并会对用户故事进行故事拆分和工时评估。并且，Scrum 迭代规定 Sprint 冲刺中不要打断或更改团队冲刺的故事。
但是，大多数团队在进行中很快就变成是小迭代中的小瀑布！团队在计划会议中被要求完成多少个故事，大多数情况缺少前期调研和整理，任务拆分不是按照过程拆分（调研、设计、开发、测试），就是纵向拆分（页面开发、逻辑层开发、接口开发）等。基本感觉就是要完成这些故事，了解个大基本，很多细节还要到迭代中进行梳理和整理。
这时，如果你面临的第一个问题就是，如何保证在迭代内完成承诺的用户故事？
如果你是这样做的：为了保证完成，开始制定计划时间表和里程碑，为了在开始在迭代前梳理清楚需求，要求有 PRD，并在迭代中规定不要轻易改变迭代内容等，那么，你就真的将敏捷变成了小瀑布了。也许你会说，故事拆分就是为了定义边界，让我们知道在迭代中做什么故事。还有燃尽图，就是要按照计划的速度进行开发。
This chapter requires login to view full content. You are viewing a preview.
Login to View Full ContentCourse Curriculum
1
建立敏捷基础 —— 让流程“跑起来”（2013–2014）
以敏捷宣言为起点，通过站会、Planning、Review 和 Retro 建立基本节奏；引入看板实现需求可视化，制定上线准备项等规则。结合 JCSM 培训、“棒球大联盟”游戏及影响地图实践，完成从认知到初步落地的跨越。
2
提升团队效能 —— 让协作“顺起来”（2015–2016）
聚焦跨职能协同与迭代质量，运用用户故事地图对齐目标，优化燃尽图使用，强化“响应变化”能力。通过披萨游戏、PMI/TiD 外部交流等方式激发团队共创，推动开发、产品、测试形成高效交付闭环。
3
穿越震荡周期 —— 让系统“稳下来”（2017–2018）
面对交付压力与团队变动，通过深度 Retro 重构看板规则，加强代码质量与 CI 实践。借助 OpenSpace 会议和外部转型交流，在混乱中重建协作秩序，锻造出更具韧性的敏捷运作机制。
4
驱动持续进化 —— 让组织“强起来”（2019）
技术 Leader 主导流程规范，明确 DoR/DoD，标准化演示与回顾机制。强调“看板整洁不能太放肆”，将规则转化为对 Scrum Master 的赋能，推动团队从执行敏捷走向自主持续改进。
Speaker
Songran Zhang
@Aliyun | Qwen Chat
Songran Zhang is senior systems architect at Aliyun, a speaker, and an author. Over the past 15 years, he's mastered architectures from cloud-native systems to AI-powered LLM platforms, building deep technical expertise across large-scale, high-availability systems.
