见过太多公司，打着“敏捷”的旗号，干着“加班”的事情，你的公司是否也是其中一员？今天就让我们花点时间，来扒掉伪敏捷的皮，也看看为何好好的敏捷，怎么就变成了加班。

敏捷的“快”与领导的“快”

我们在谈到敏捷的时候，一般会谈到“快”。

看到快，很多管理者瞬间高潮了——啊，快啊！我们要的就是快！

但这两种“快”是一个意思么？显然不是啊！

敏捷的快，讲究的是“快速交付真正有价值”的需求，所以这种快是一种相对价值交付层面的快，即原本你需要2个月才能搞懂用户需求，用了敏捷方法后，可以在1个月就开始交付有价值的东西给客户。

而诸位开始高潮的领导们的“快”是——今天下班提需求，明天上班就上线。

于是这两种不同的快，造成了双方（敏捷践行者 && 领导）的认知差距。

PS：从某些层面来说，领导的理解不能说是错的，毕竟“敏捷”也的确是有“身手矫健”的含义。

深入分析为何快不起来

稍稍深入分析一下，老板是真的不知道快速交付对客户有价值的东西么？肯定不是，甚至我认为对于老板而言，这个理念他恐怕是最能认真体会的。

既然如此，为何还有这么大的差异呢？

从过去的工作经验来看，发生这种情况的根本原因还是卡在了对敏捷落地的认知、人员相关能力不足、企业文化上，最终导致在实践的过程中动作变形。

对敏捷落地的认知

有一部分管理者认为，敏捷转型、落地，这本身就是Scrum Master 或者敏捷教练的工作，其他人员（包括但不限于研发、产品、运维、UI/UX等）不需要做任何事情。

这种想法就类似于“文盲换了一副眼镜就能读懂红楼梦”一样的荒谬。

敏捷落地，不仅仅是几个敏捷实践执行起来就行了，而是需要从理念和习惯上让团队接受，并且以此来改变团队的开发习惯，从过去的Big Bang形式的交付，转变成敏捷推崇的增量-迭代的形式交付。这才是敏捷落地的根本。

在这个过程中，我们需要改变团队的想法、做法，而这些都需要团队配合。这个过程本身就需要多角色、多角度配合，单纯SM能做的事情太有限。要知道，SM 能做的仅仅是教导、辅导团队在流程上面进行改进，而敏捷作为一个系统工程，单纯流程改变，是远远不够的。

相关人员能力跟不上

这点可以直接体现在流程的流畅度上。如果真的要说，大概可以从技术能力不足、产品能力以及管理能力不足三个方面。

技术能力不足，就不用说太多了。基本的TDD、CI都做不到的开发团队，你希望他能“快速响应”，基本上就是痴人说梦。在这种情况下，为了做到快速响应，唯一的选择，怕是只有“加班”了（某种意义上，也是快速响应，但这种快速无法长时间持续）。所以从某种意义上来说，研发人员算是受害者，也算是事件的原因，看你从哪个角度观察。

PS：这里有一个很有趣的现象。有时候研发不做工程实践是因为工期太急，没有时间进行工程实践。但是没有工程实践却又会进一步拉长工期。我将这种现象称之为“工程实践与交付悖论”，即想要省时间，结果还是浪费了时间。

而产品能力不足，更可以说是这件事情的核心因素。

国内互联网企业，有一些产品经理被我们戏称为“原型机器”，不是没有道理的。这些所谓的产品经理，每天干的事情就是去画图，从Axure 到墨刀，从Sketch到 Balmasiq，一个个用的那是风生水起，乍一看还真的有“原型在手，天下我有”的感觉。

但是，如果你把这些放一边，让他们去将产品的业务逻辑通过影响力地图进行分析一下的时候，你会发现他们的能力匮乏到让你惊讶，甚至没有办法理解一条完整的价值链。问他们为何如此设计，得到的回答是——业内都这么做，或者说老板想要，或者就是一句“我就是这么设计的”。

这还只是在单个产品经理层面，如果你要把这个级别拉高到产品总监的级别，你会有更让人背后发凉的感觉。

在这种产品水平之下，产品经理是没有能力将业务进行拆分，并确保拆分的部分可以分批次交付，更有甚者对MMF与MVP的功能都不能正确区分。因此，产品设计出来的结果，就必然成了需要大块交付，甚至一次交付的内容涉及到多条价值链。这最终导致了每次产品交付量都会有各种交叉，以至于“不是我们不想分批次交付”，而是“如果分批次交付，产品功能就不全”的情况时有出现。

用一个比喻来说就是，敏捷需要的是步枪，通过单次发射（发布）以及发射后的客户反馈来快速调整方向，最终在多次发射后，最终满足用户真实需求。如果产品业务能力不足，就会导致无法使用步枪（无法单次发布小需求），转而使用霰弹枪（一次性发布若干没有关联的需求），并希望可以在这些需求中蒙中几个客户需求。

至于管理能力不足，本质上并不是敏捷才有的，因为这种管理无能并不会因为不使用敏捷而消失。

这种管理能力不足主要体现在对研发工作的理解。

研发本质是一种创造性工作，而且这种创造性工作一定是非线性工作。即无法通过长时间加班、对员工施加高压就能解决的问题，更不是一个1+1=2的简单计算。除此之外就是所谓的“外行指导内行”，即领导是万能的，什么都需要指点一下。这点在产品研发层面是行不通。研发或者产品被打断后，需要花费更长的时间重新集中精力，这种浪费是很可怕的。当然，比这个更可怕的是，很多管理者不仅觉得这不是问题，反而还会沾沾自喜自己又“帮助了”团队进步。

其他的一些低级管理错误，凡是能打击到团队积极性、认同感的做法，都可以在管理能力不足场景下出现，这里就不再赘述了。

上述三种能力不足，对团队的影响由小到大，解决的难度也是由小到大，请各位自行对照。

企业文化

企业文化比较好理解，用一个极端的简化模型来说就是问责模型。

如果企业文化对“做错事”这种现象的态度是深恶痛绝，那么在这种企业中就会有很多评审步骤。这些企业寄希望于预先的多次评审来减少最终对市场的误判。

这种做法不能说有问题，但是这种做法强依赖于评审者对市场的认知与感觉。也就是这位评审者是“产品是否正确”的保证，而且常规情况下，部门或者小组最大的负责人，一般都会成为这么一个角色，不论他是否真的专业。这点也和前面所说到的“问责文化”是比较贴合的。

先不谈这个产品最终交付是否正确，但是评审者的岗位，就会非常明显的在整体研发流程中增加一道门（Gate），而这道门是不能逾越的，这就很大程度上导致工作的流动（Flow）受到影响，进而影响开发节奏、交付速度；若再加上中途需求的变化、增加一般也不会根据时间盒来进行的话，整个产品、研发、交付流程彻底崩坏，最后不论是回到门径还是瀑布，都会让敏捷落地无法进行。

扒掉伪敏捷的皮

都已经谈到了这里，下面还是让我们来扒掉伪敏捷的皮吧。

我相信大多数使用敏捷的团队、组织的管理者，都是希望敏捷可以为他们带来一些变化，否则他们也不会承担着风险来引入一项新的事物。但是很多情况下，这些引入敏捷的人，由于对敏捷的认知的缺失，单纯认为敏捷就是快，而不是将敏捷视为一个需要全体成员共同努力才能实现的东西。如果这是引入敏捷的第一步，那么敏捷落地，从开始到失败，也就是肉眼可见的了。

从我们上面的分析来看，影响团队、组织进行敏捷落地的三个方面——对敏捷落地的认知不足、人员能力不足、企业文化——但凡出现一种，都会让真正敏捷分崩离析。

对敏捷落地认知不足，你会无法得到支持，甚至这些支持你是永远无法获得的，你直接陷入孤军作战的境地；人员能力不足，导致你短时间内无法让团队产生变化，最终走上被干掉的道路（见这里）；企业文化缺陷，敏捷生存的基础土壤不足。

这些都会让你无法做到领导所需要的“快”。然后，请告诉我你能做的事情是什么？亲自写代码？亲自写需求？

其实们还有一些能做的，比如导入Scrum流程，比如导入Kanban，再比如使用一些自动化工具（这里我是真的不愿意将自动化工具说成DevOps 工具，工具和DevOps 中间至少差了10个Scrum）。这些工具和实践都一定程度上让你看起来好像更敏捷一些，但你总觉得哪里不对——每次迭代计划都会变、每次看板都不更新、每次评审都没有人来、每次回顾都成了茶话会。长此以往，你会开始怀疑自己能力，甚至开始怀疑敏捷是否真的有效，再然后就要走向“从入职到开除”的康庄大道。这一点都不意外，毕竟对一个伪敏捷来说，你还要求怎样呢？

所以，你重新想一下，你还能做什么？

别傻了，你能做的，怕是只能压迫研发加班了。通过增加工作时长，来满足领导对于“快”的诉求。有Bug怎么办？不要紧，我们加班修改；客户有要求怎么办？不要紧，我们加班完成；老板又想到一个需求怎么办？没关系，我们996；如果Blablabla？不要紧，我们加班！

你看，没错吧，加班才是伪敏捷的最终归宿。

至于研发累不累，产品爽不爽？管他呢，谁让他不是老板呢。