上次，我们从两个披萨饼说起。披萨虽好，但也不宜多吃，所以，今天来聊聊“堵嘴布”的故事。
看完下文，你至少应该知道以下三个问题的答案。
- 为什么要堵婆婆的嘴？
- ScrumBut是什么，它为什么会让敏捷Scrum失效？
- 正确的Scrum实施模式是什么？
故事从Scrum的创始人，也是签署敏捷宣言的17位大牛之一的Ken Schwaber的一句话说起。
Ken Schwaber曾经说过“我估计，在使用Scrum的组织中，75%的组织无法成功获得他们所斯望的收益”。
这是为什么呢？Scrum不好吗？
很多人在接触Scrum之后，会认为Scrum太理想化。他们说，我们在用Scrum，但是：
• 每天站会开销太大，所以我们一周一次。
• 回顾会议太浪费时间，所以我们不做。
• 我们一个月也做不完啥，所以６个星期是一个迭代。
• 经理给我们临时任务，我们无法完成DoD。
以上理由，摘自http://www.scrum.org/scrumbut，原文如下
为此，他们不会去使用全部的Scrum框架。取而代之的，他们会根据自己的实际情况，对Scrum框架做出他们认为合适的裁剪。
我们把这种现象或行为称之为“ScrumBut”。
“ScrumBut”有问题吗？
Scrum的创始人Ken Schwaber有一段演讲，对此有个精彩的比喻，他说使用Scrum就像是和你的婆婆一起生活，她会不断指出你的缺点，让你改进。如果有一天你烦了，用东西堵上她的嘴，那就是ScrumBut。但这并不意味着你婆婆说的是不对的。
Scrum是一个帮助发现问题和解决问题的框架，这个框架如果少了一块，就不能如期帮助你透明地发现问题并解决问题。也就是你屈服于当前存在的问题，而不是去面对它，解决它。
而且，Scrum的实践者，大多也都会认同“ScrumBut”的这种严重后果。
但事实上，因为有很多历史遗留问题，确实很难解决，所以绝大多数人又确实在用“ScrumBut”。即他们会根据自己的实际情况，对Scrum框架做出自认为合适的裁剪。这样的后果，就是Ken Schwaber预料到的“75%的组织无法成功获得他们所斯望的收益”。
那么，怎么识别“ScrumBut”呢？
《持续交付》翻译者乔梁先生一次演讲中，曾经说过“开发后期发现的缺陷仍旧较多；项目进度仍旧存在很大的不确定性。很不幸，你已经进入 ScrumBUT model”。
“ScrumBut”到底是什么？scrum.org给出了定义，如下：
翻译过来，大概意思是说，ScrumButs是团队不能充分利用Scrum来解决他们的问题并获得使用Scrum进行产品开发的全部收益的原因。每个Scrum角色、规则和时间盒的设计都是为了获得期望的收益和解决可预见的重复问题。ScrumButs意味着Scrum暴露了导致问题的功能障碍，但是很难修复。ScrumBut保留了这个问题，同时修改了Scrum，使其不可见，这样功能障碍就不再是团队的眼中钉了。
在我曾经参与翻译的《敏捷Scrum基础》（Agile Scrum Foundation）一书中，也有一个章节专门讲解“ScrumBut”。
该书提及到，关于敏捷有很多误解，例如，大多数人认为他们只需将预测的范围划分为更小的片段，在叫作冲刺的时间段内开发它们，就可以称为Scrum了，这是错误的。敏捷是自适应的，而不是采用一组特定的术语。
但是，我们怎样才能做到自适应呢？这涉及很多要求，这就是为什么使用一个结构精良的框架总是最好的选择，而不是“重新发明轮”。
每个框架都有一套规则，以及调整改进的空间。Scrum调整的空间相对来说极低，因为它真的非常轻量级。在Scrum中，一切几乎都是强制性的，你不能省略任何方面。但是有些人就是那样做！比如，他们说：
- 我们使用Scrum，但我们不遵守冲刺时间盒。
- 我们使用Scrum，但我们在冲刺计划中设定冲刺的周期。
- 我们使用Scrum，但我们不允许产品待办列表改变。
- 我们使用Scrum，但我们认为没有必要做冲刺回顾。
所有这些情况都称为“ScrumBut”，这不是Scrum。
“ScrumBut”不是Scrum。因为当你仅遵循 95%的Scrum 规则时，你别指望能获得95%的收益，也许只有10%到20%的收益。
看完上文，对于上面开始的第一个问题，为什么Ken Schwaber会说 “我估计，在使用Scrum的组织中，75%的组织无法成功获得他们所斯望的收益”，真相大白了吧。
2020-1-24
您如果有好的故事，或者愿意分享的人和事，请联系我。
更多趣味故事和知识，请关注公众号：王道质量
