选 Scrum 还是看板？一套实用的判断方法
到 2021 年年中，许多团队已经在餐桌和闲置卧室里办公了整整一年，其中不少团队借助某种敏捷框架，在其他一切都摇摇欲坠时维持交付的稳定。我们最常听到的问题很简单：我们该用 Scrum 还是看板？诚实的回答是，它们并非对手。Scrum 是一套框架，有明确的角色、事件和固定时长的 Sprint；看板则是一种方法，用来可视化并限制在制品，让工作得以流动。要选得好，先要理解眼前的工作，而不是急着选边站。
做得好是什么样子
优秀的团队会选择与工作形态相匹配的方式。一个朝着目标推进、能够在一两周内承诺一批聚焦工作的产品团队，往往在 Scrum 下表现出色：Sprint 营造出稳定的节奏，Sprint 评审为干系人提供定期的检查点，回顾会议则促成诚实的改进。一个处理源源不断、难以预测的请求的团队——支持、运维、事件响应——通常更适合看板，在那里在制品限制可防止过载，周期时间成为真正重要的指标。
选择 Scrum，是因为团队能在整个 Sprint 内稳住 Sprint 目标，而不是因为管理层喜欢这个词
选择看板时设有明确的在制品限制和工作项流转规则，而不只是一块贴满便利贴的板
无论哪种方式都有清晰的完成定义，让“完成”对每个人含义一致
用指标来学习——Scrum 看速度趋势，看板看周期时间和吞吐量——而不是用来给人排名
做得差是什么样子
失败的落地往往有一个共同的破绽：团队照搬了仪式，却跳过了它的目的。我们见过这样的“Scrum”团队，待办清单几乎隔天就在 Sprint 中途变更，这恰恰摧毁了 Sprint 本应保护的专注。我们也见过这样的“看板”，“进行中”一栏堆着四十张卡片却毫无限制，那不过是一张涂了三种颜色的待办清单。两种情形下，人们都怪罪框架，而真正的问题是没有人改变决策的方式。
形式主义的 Scrum。 每日站会沦为向某位经理汇报状态的会议，Sprint 目标缺席，Sprint 变成倒计时而非承诺。
没有边界的看板。 板子把工作可视化了，却不设任何在制品限制，于是什么都开工、却几乎完不成；因为没有约束，流动永远无法改善。
框架的表演。 团队一丝不苟地走完每个事件，却把回顾会议当作可有可无，于是同样的问题一个 Sprint 接一个 Sprint 地重演。
一个好用的判断：如果你的工作以难以预测的方式爆发式涌入、优先级每小时都在变，那么 Sprint 的节奏会与你作对，而看板的持续流动会更友好。如果你的团队需要一个共同目标和受保护的时间去达成它，Scrum 的结构就值回票价。许多成熟的团队最终会把两者融合——既举行 Scrum 事件，又对工作流施加在制品限制——但他们是先精通其一，才赢得这种融合的资格。
无论你是第一次组建交付团队，还是要理顺一套不再奏效的框架，XNM 的项目群与项目交付咨询 都能帮助你选择并运行最契合自身工作的方式。