SCRUM‘敏捷’不敏捷！

Posted 2021-04-25 衷于栖

Scrum能高效并创造性地交付尽可能高价值的产品。Scrum是轻量级的、易于理解的、难以精通的。

基于“Scrum指南”，可以理解我们用它，就是为了高价值三个字，而现实却让人失望了。不仅仅让看重价值的人失望，还让制造价值的人失望。

事出有因，写这篇文章并不是简简单单的抨击Scrum，其实我一直都没有说这个理论架构本身有什么问题，仅仅是实践过程中所谓的敏捷变得让人有点难以忍受。Scrum标榜自己尽可能的交付高价值的产品，从字面意思理解，好像在告诉人们，这个框架会尽可能地让你的产品提高其自身价值。不知道我理解的有没有问题，但是产品的价值什么时候可以被一个框架左右了？而不是营销、创意、功能。Scrum框架所能做的不应该是简单的提高生产效率吗？或许生产力提高之后会影响产品的时间轴，从而让一些人抓住机会，让本应该属于产品的价值展示出来。但是这种提高价值的方式，我越来越觉得很像在淘宝买东西一样，买回来永远和卖家展示大相径庭。说到底宣传总会是把吸引眼球的东西先呈现出来，至于有没有欺骗成分，我觉得用户自己可以体会，这里就不多说了。如果说Scrum真的能提高生产率，也就罢了。我害怕的是这东西会像狂犬病一样，潜伏着…

Scrum指南里有一句（不管是老版本还是2017年版本的指南都会有这一句）:

Scrum是免费的，在本指南中提供。Scrum的角色、工件、事件和规则是不可改变的。虽然只实施部分Scrum是可能的，但这样就不是Scrum了。Scrum只以整体的形式存在，唯其如此才能作为其他技术、方法和实践的容器从而良好地运作。

“它是免费的，但是你用的话还得有人教。所以你就交个万八千的给我们，我们给你发个初级认证，以后你就可以把这个当饭碗去骗…不不不…教别人了。你看这是我们的认证体系，四个级别…”，所以不管它好不好，别以为它是免费的。这不由得让我想起了“禁止传销条例第二章第七条”所规定的传销行为，不过也不用紧张，仅仅是最后一句牟取非法利益这还有点分歧。

可能单纯的理解这句话的话，现在公司内执行的全都不是Scrum，甚至教练当初教的也不是Scrum。那我们在干什么呢？我还真的问过，有人说针对自己的公司适应调整…之后的话我也不记得了，按这样来说，这全都不是Scrum。那我还在这里说它干什么呢？所以我就单说说自己公司的Scrum吧。

刚来公司的时候，我所在的部门其实并没有实行敏捷。整个开发管理的很松散，但是由于大家都是年轻人，心气很高，相处也很愉快。那时候每天日报，我的日报主要内容就是早上到公司准备的一个待办事项列表，简单明了。一天的任务开发完了，日报也就完成了。并不像传统的软件行业，没有项目经理，没有专职测试，设计师是共享的，产品经理是业余的。开发功能一般需要程序员设计，与每一个环节的人交流解决问题，并对开发结果负责。基本上是扁平的管理模式，从CEO到开发人员中间只有一个人。这种松散的管理模式对于‘大企业’来说当然不行，于是2017年年底的时候，公司准备在在我所在的部门推行敏捷。一开始我并没有很抵触，因为最早也接触过极限编程、持续集成之类的敏捷方法，但是Scrum这种，说实话真的是第一次接触，因为不懂，所以先虚心求教吧。

一转眼已经到了现在（2018年第四个季度），怎么说呢，我的抵触情绪发生在看完‘Scrum指南’之后。那是后的思想还很简单，觉得这玩意就是个方法论，目的当然是指导增加效率了。但是我就没见过从诞生之日起，没有过改变一直被人信奉的理论，至少它得有个使用前提或者框框。还有就是刚开始公司内推敏捷课程的时候，我问过已经实行过一段时间的同事一些问题，但是都不了了之了。这种课程，不应该是介绍经验避免重蹈覆辙的么？可是那时候我听到的是比之前UPerform专业人员还幼稚的课堂，向上帝一样告诉人们该怎么活着，她们告诉我们该怎么样敏捷。

我大概在两三个小组进行过敏捷，看见了这些人的状态。让我更加相信所谓的Scrum其实只是个骗局而已。

第一个组，每天的站会就是一个形式而已，勤快点的程序员会在站会之前就了解其他人做了什么，不勤快的站会讲了什么大概都不太清楚。敏捷教练也不好意思去说什么，结果就是每天早上或者下午都会有15到20分钟的时间，大家一起‘旷工’。迭代会持续时间一定是要超出预期时间的，最重要的是大家还要为即将要做的事情估算一个无关痛痒的时间，‘反正都是这个迭代要做的事情’，甚至是‘反正都是要推到下个迭代才开始的事情’。分配任务的时候唠唠家常算是人之常情了，大家也不忌讳反正时间有的是呢。DemoDay，那应该就是程序员的末日了。因为没有测试，没有代码审查，基本上就是赶着时间开发完。到了神圣的DemoDay，Bug应该属于家常便饭了，说辞嘛，人无完人啦。回顾会的时候，有时候阐述了问题也说明了解决方式，然后就没有然后了，下个迭代继续走老路。

说到底，第一个组也好，其他组也好。那时候都是在尝试进入这样一个流程。满怀期待的等着自己效率的增加。正由于形式太重了，忘记了产品开发的本质。需要集中解决的问题总是被人遗忘在角落里。那个时候气氛还好，并没有现在那么无聊，或许也是因为刚刚起步吧。

第二个组，每天站会15分钟，同样需要阐述自己需要做的事情，同样大家象征性的说一下今天的事情，改变是需要有人协作的时候，会提出来并且讨论。这样也会导致原本十几分钟的会议，有时候要开到一个小时。迭代会时间就更长了，而且迭代周期从原来的两周压缩到了一周，每次DemoDay、回顾会、迭代会会连在一起开，整整一天就过去了。我读过相关内容，迭代会往往会与回顾会叉开一段时间。而这一组，为了追求效率就去掉了这个过程。

公司部门对敏捷做出了自己的适应，反正按照解释，现在的Scrum已经不是当初那个Scrum了。而且Scrum中定义了的每个人的品质（承诺、勇气、专注、开放、敬重），我是一点也没看见。现在管理层还在问所有参与敏捷人，怎么提高你们的效率呢？我甚至觉得可笑。更可悲的是，作为人参与工作也好，家庭也好，最重要的提升自己的手段–交流，也变得很不符合潮流。人们每天不苟言笑，活得严肃，关于工作的交流多了，互相之间的关怀少了。

我个人觉得，个人发展、认同感才是每个上班族更加关心的事情。而自从实行敏捷之后，这方面的关怀就变得杯水车薪了。每个人就只是工作而已，并不知道自己以后会怎么样，甚至工作内容都左右不了。更加荒诞的是，工作效率本来很高的人，每个迭代会比工作效率低的人多做数不清的工作，但是基本工资确实一样的。本来软件开发这个行业工作效率就难以衡量，工作以小组为单位，就更难衡量个人之间的差异了。

结局是：产品隐藏结构越来越糟糕，因为程序员和产品没有架构能力，工作评估工作完成的不好，工作量不是太多就是太少，制度化内容并没有强制性，没有约束力。产品和程序员直接沟通障碍。产品有几个人同时更新时，导致部署的时候问题很多，没有充分利用网络，自动化技术，也没有人响应这些内容。本来就不完善的公司管理制度，在没有完善学习好的时候投身敏捷，注定是一场持久战。本来可以更好，却没有人关注更重要的点。工作效率真的提高了么，还是只是工作量增加了。

敏捷就是一个半成品，一群优秀的人用敏捷的方式能提高效率，其实就是给旺盛的生产力加上束缚，让他规则有序。毕竟，能力和可控是反着来的。 而自我定位不准确的时候，就像现在，人性本就不堪一击，能力又不行，就直接导致整个垮掉。敏捷如果是一套理论，那就必然经历争执，逃避就是禁不住推敲；敏捷如果是一套规则，那就需要完整的去遵守，失败了不要推卸责任。90年代起家的Scrum，经历了10年在美国兴起，经历了20年才在中国兴起。有理由让我相信现在的中国软件开发管理市场就像是十年前的美国，没有规则，这才给了Scrum机会。

创始人 Ken Schwaber 本人说：

Scrum is not a silver-bullet. It does not bring success. Intelligent, hard working people can use Scrum to overcome waterfall habits and build the best possible products, but the effort is great and those that succeed will be in the minority. I predicted five years ago that only 25% of all organizations that embraced Scrum would fully benefit, and I see now reason to change my projections.

意思差不多就是：成功的人怎么样都能成功，失败的人总会失败。