Scrum

Scrum 是敏捷原则的一种实现，有三个角色、三个工件和少数几个事件。产品负责人决定构建什么以及按什么顺序构建。Scrum Master 清除阻碍并保护流程。开发人员负责构建。工件包括产品待办列表（所有可能被构建的内容，通常写成用户故事）、冲刺待办列表（本次冲刺承诺的内容）和增量（实际交付的内容）。事件包括冲刺规划、每日站会、冲刺评审和回顾会议。

Scrum 真正有帮助的地方：在那些难以保持专注和可见性的团队。固定的冲刺迫使团队做出真正的承诺，评审迫使团队进行真正的演示，回顾迫使团队审视自己的流程而不是忽视它。对于一个从未按节奏交付过的团队来说，Scrum 是一个有用的脚手架。

它沦为表演的地方：当事件存活下来但实质却消亡了。一个变成向经理汇报状态的站会。一个没有可运行软件可展示的评审。一个每两周都产出同样三条行动项却从不落实的回顾。许多「Scrum」团队执行着仪式，却得不到任何价值。如果你开了会却无法演示一个可运行的增量，那你拥有的不是 Scrum，而是一个开会的习惯。

那个开销陷阱，举个实际例子：一个五人团队照着书本采用 Scrum，最后每两周就要做一次冲刺规划、每日站会、待办列表梳理会、冲刺评审和回顾。在这个规模的团队上，那套仪式负荷一周能吃掉每人差不多大半天的时间，而它换来的规划精度是浪费的，因为一个五人团队本来就知道每个人在做什么。这个框架是为了协调那些已经失去这种可见性的团队而设计的；把整套都强加到一个从未失去它的团队身上，纯属交税。修法不是抛弃那些反馈回路（保留演示和回顾），而是砍掉那些在解决你并不存在的问题的协调仪式。

Wavect 的坦诚看法：Scrum 是一个不错的入门框架，却是一个糟糕的宗教。保留那些创造反馈的部分，舍弃那些制造负担的部分。大多数成熟团队在纪律内化之后，都会漂向更轻量的方式，往往更接近 Kanban。