Scrum成为敏捷敌人的可能性

Allen Holub，算是敏捷圈子里颇有争议的网红，前几天发推：

“我一直绞尽脑汁想弄明白Scrum是如何提高敏捷性的，我不明白backlogs, sprints, 固定的角色和会议是如何让你变得更加灵活、快速、及时调整方向的。在我看来它们似乎没有增加任何价值。我到底错过了什么？”

一时间，几百条跟帖支持，各种吐槽Scrum问题。显然，最时髦的敏捷方法，其落地效果并不及预期，众多软件工程师也不买账。分享几条有代表性的吐槽。

“因为PO这个角色，我们更见不到用户了。”

“Scrum成了一种时尚，许多组织自称在做Scrum，其实咨询师前脚刚走，他们后脚就把Scrum指南扔到一边。”

“没看到Scrum的灵活之处，杂乱的backlogs真的没有什么价值。”

“没什么喜欢的，实际sprints就是一系列小瀑布，加了个敏捷的标签。”

“没有技术实践就没有敏捷，没有类似XP或mobprogramming的支持，Scrum不可能提升敏捷度。这种情况下，我真不知道为何要做Scrum？”

“Scrum只是一系列仪式（站立、回顾和sprint演示），迫使团队用不同的时间和固定的人员（回顾=内部，演示=外部）做审视。其实这些会议后团队做的事才决定了你的敏捷度。”（CMMI认证）

“阿门。我们最终抛弃了Scrum，因为在我们这，梳理backlogs和迭代规划是一场只有项目经理才能理解的游戏。”

去年写过一篇公众号“没有匹配开发过程支持的Scrum只是个花架子”，表达一些个人观察：
“很多人其实没有意识到Scrum不是一个真正的软件开发过程，它更像是一个软件开发过程的盒子。Scrum并没有定义任何核心的软件开发实践，但如果这个盒子里的东西还是原来瀑布环境下的工程开发过程或是因人而异的随机过程，那么Scrum几乎不可能成功。
Scrum不是实现敏捷转型的唯一方式，但如果选择它，那么必须设置与之匹配的开发过程。注意，我用的词是必须！可惜这个至关重要的路径被许多敏捷教练和敏捷组织忽略了，后果是什么不用说也知道。
 一些Scrum Master或敏捷教练不关注开发实践，仅仅求快以彰显“敏捷”效果，同时又要求开发人员毫无目的地参与到各种充斥仪式感的活动中，硬凑故事，却不考虑调整与之匹配的产品规划、需求、设计、开发、测试等文档和过程，结果是开发人员用在开发上的时间更少了。可以说开发人员是敏捷转型收益最少的群体，难怪Ron Jeffries（敏捷宣言作者之一）最近提出“开发人员应该放弃敏捷–Developers should abandon Agile”，去追求符合敏捷软件开发原则的有效实践。”（CMMI认证）
Scrum指南中有许多非常好的东西，有个框架可以帮助瀑布的组织起步, sprints一方面推动把任务变小（small batch size），同时又缩短了反馈环节。
但请大家注意，指南不是标准！！！差异性决定成败。如果三个角色，三个文档，五个会议成为团队必须执行的标准过程，那其实你已经把敏捷做成了标准，你敏在哪里？ 每个团队、每个软件项目都有各自的挑战，实现不断为用户交付价值的路不可能完全一样，还是李小龙那句话：汲取对你有用的，抛弃对你无价值的，加入你自身特有的。其实敏捷转型最重要的是建立形成敏捷思维、态度、文化，以解决问题和改进为目的，创造性的选择使用指南中有用的东西，但同时不受任何指南的约束。所谓取其道不取其人，务其实不务其名。针对不同项目、团队特点建立自己的敏捷模式、过程，贴不贴Scrum的标签真不重要。

三句应该记住的敏捷鸡汤

我对SCRUM最大的担忧是：它变成反敏捷的东西，成为敏捷的敌人。SCRUM定义了时间盒、开发节奏、反馈等，这些东西不反敏捷，但如果实践者把它们变成了团队必须遵循、无法逃避的规则和标准，那就违背了敏捷精神，成为反敏捷道具。同样，在CMMI也一样，一旦组织去凑CMMI，而不是用它作为一个有效工具解决自己的问题，那么它带来的一定只有负面价值，除非，你想也仅仅只想要一纸证书！

文章来源丛斌博士