方法

Agile

一族软件开发实践,重视短迭代、频繁的客户反馈,以及根据交付结果回头调整计划。

最近审阅: 2026-05-24 审阅人Kevin Riedl wiki ↗

Agile 比多数人意识到的更老(宣言出自 2001 年),落地得也比多数团队愿意承认的更糟。最初的想法很简单:计划做得比你能预测的更远,就是浪费工作,所以短计划、发布、学习、再计划。其他一切(Scrum、Kanban、SAFe、Sprint、Retro、Story Point)都是叠在上面的实施细节。

对一支声称「在做 Agile」的团队,最有用的问题是:上一次因为上周发布的东西而改变计划,是什么时候?如果答案是从来没有,那这支团队是在用两周一块的瀑布。

区别,举个实际例子:两支团队都跑两周 Sprint。A 队做演示,看到一个路线图上没人预测的功能才是用户真正点击的那个,于是把下个 Sprint 围绕它重排。B 队做演示,把反馈记进一份文档,然后按他们一月份写下的计划继续,因为计划就是计划。A 队是 Agile 的。B 队有 Agile 的仪式和一个瀑布的脑子。仪式是一样的;只有「是否愿意根据证据行动」不同,而那就是全部胜负所在。

诚实的取舍与创始人错误:Agile 不是跳过计划的许可证,它也不免费。它用长周期的可预测性换快速学习,而当范围、监管或一份接口契约真的不能变时(认证医疗器械、航电、某些硬件),这恰恰是错的。即便在那里,原始原则在团队内部依然适用;面向外部的流程只是看起来更像瀑布。Wavect 在原始意义上是 Agile 的:我们在短周期里工作、频繁演示、靠 CI/CD 让发布变便宜,并且愿意把结果证明是错的工作扔掉。我们对认证产业版的 Agile 抱怀疑态度,那种把会议节奏本身当成目标、把 TDD 套件写来给人看而不是为了信心的做法。

// FAQ

常见问题

保留仪式、丢掉学习。每日站会、计划会议、Story Point 全做了,但从不根据上 Sprint 的结果回头调整计划。这叫两周块的瀑布,不叫 Agile。判定标准只有一个:上次因为学到东西而改了计划是什么时候。
Scrum 适合需求有节奏、能切两周块的产品团队。Kanban 适合中断驱动的工作(支持、运维、Bug 修复)。SAFe 适合需要在多个团队间协调路线图的大组织,小团队上 SAFe 等于把自己埋在流程里。框架是工具,不是目标。
不冲突,前提是你愿意让范围在框架内浮动。Wavect 在 SoW 里固定「交付目标」与「价格上限」,但允许实现路径在 Sprint 之间调整。把每个功能的字节级细节都写死的固定价格,才是与 Agile 真正冲突的形态。