写在前面

敏捷这东西，是一个说起来容易，做好很难的经验型实践学科，加之敏捷起效果也不是分分钟的事情，难免需要一个长时间的观察。如果你问别人敏捷做的怎么样，一般会有人告诉你很好。但是当你问怎么个好的时候，又不能说出个子丑寅卯。在这里我虽然不能告诉你什么叫做得好，但是我可以罗列出（自认为的）几个“敏捷基本做不好”的信号。

本文内容相对主观，不太客观，欢迎拍砖。所有内容对事不对人，请勿对号入座。以下内容根据我的个人经验排序。

不懂项目管理

你没有看错，我把不懂项目管理放在了第一位。

虽说这些年各种弱化项目管理、强化产品管理的势头出现，但在实际工作中，完全无视项目管理三种约束的产品开发（姑且这么叫）还真的没怎么见过。如何在开发过程中应对这些约束，可以认为落到了项目管理的可以解决的问题域。

除此之外，只要你在推进产品开发，你总是免不了与干系人、风险管理、资源配置、沟通管理、采购管理（好吧，这个可选）打交道，如何处理这些知识领域的事儿，不懂项目管理的敏捷从业者，真的能搞定？如果搞不定，你跑的敏捷，很可能就是一个空架子。

毕竟，敏捷是一门实践科学，搞定事情最重要。项目管理，很可能是帮助你搞定事情所不可或缺的部分。

此处夹带私货：PMP 真的不是瀑布项目管理、PMP 真的不是瀑布项目管理、PMP 真的不是瀑布项目管理！如果可以，哪怕不考试我也建议大家去把 PMBOK 认真看看，有百益而无一害。

只知 Scrum 而不知其他

不可否认，各大机构在 Scrum 推广上功不可没，这也的确在一定程度上为敏捷提供了人才。但是在种种原因之下，部分从业者将敏捷与 Scrum 之间画上了等号，而对其他敏捷相关的内容毫不知情，也不知灵活变通。

遇到任何事情，无论是否合适，上去就用 Scrum 套，这种本身就是一种掉书袋的表现。更何况敏捷这种偏实践的学科，本就没有万应灵药。当你手上只有 Scrum 这一味药的时候，又怎能确保你开出的药方能够药到病除？或者你想要的是药到命除？

认为敏捷和 DevOps 是两件事

针对这两个事物，DevOps之父Patrick Debois和敏捷宣言联合作者Arie van Bennekum在 2021.11.10 的DevOpsDays大咖说直播间就已经表达过“两者是同一件事情”。但为何还有人认为这两者有高低贵贱之分呢？

从我的角度来看，大概有这么几个原因：

1.对敏捷本身理解不到位。敏捷真正的宪法是宣言，宣言只提供了价值观而没有类似于框架、落地方案之类的东西，导致大家对敏捷的具体认知，就会被 Scrum 之类框架所影响，认为敏捷的范畴就局限于开发部分（这条可以认为是“只知 Scrum 而不知其他”的延续）；

2.DevOps 真的太具象化了，加之 DevOps 又非常偏向Pipeline、自动化工具的使用，而忽略了 DevOps 背后的思想，从而导致对 DevOps 的认知就局限于“工具”、“实操”层面；

3.考证型理论派选手，无法“知行合一”，也无法从底层对这两者产生正确的认知，知识单纯局限在考试纲要的内容，结果自然不言而喻。

如果上述任何一个原因属实，敏捷做的能好到哪里去？

不读书或者从来没有阅读过敏捷经典书籍

这点我在上一篇文章中做过说明，这里再稍稍补充一下。

敏捷圈的知识更新没有那么频繁，很多二十年前的知识现在还能使用，所以经典书籍并不存在过时的情况。而一些新的书籍，不少都只是在经典的基础上，做了修补和增订，并不存在完全推翻的情况。

因此如果你从来没有阅读过敏捷经典书籍，很有可能会出现你对敏捷的理解在一开始就有偏差，纵然最后你积累了足够多的实战经验，很可能偏差的会更大，而形成China Garden敏捷。

至于不读书的人就不说了。他们能混到敏捷教练，在座各位都有责任

不重视工程实践

注意：本条仅适用于 IT 团队。

请注意，我并不认同“没有工程实践就不是敏捷”，我只能说只要你做敏捷，你终究会在某个点上要去处理团队工程实践问题，或早或晚。

根据约束理论，敏捷落地或者转型过程中，你要将注意力放在最大的约束上，而很多团队在早期，他们的约束都是在流程、工具、需求、沟通方式等方面，不会在一开始就落到了工程实践不足上（工程师心声：那可不，哪有这种好事！），所以很多时候导入 Scrum 或者其他框架的时候，在一开始能产生奇效。但这种层面的改善不可能永远进行下去，你终究需要工程实践来弥补研发侧的各种问题。如果此时你对工程实践束手无策，或者置若罔闻，那么团队的敏捷之旅基本上可以认为是到头了。

PS：即使不做，很多团队也可以优化到一个不错的水平，这里看取舍就好。

可以指点江山，不能亲操井臼

中国有句老话叫“大处着眼、小处着手”。这对敏捷来说也是如此——你需要从全局的角度看待敏捷导入的目的、预期效果、实施步骤，也就是站在所谓的“战略层面”做规划，同时也需要能将之落到实处，有能力在团队层面、部门层面进行全方位辅导，也就是所谓的躬身入局。只有这样你才能更好的获得一手信息，从而对你的战略层面进行及时的修正（没想到吧，适应性在此也能用得上），进而达到敏捷效果最大化。

古人说过“纸上得来终觉浅，绝知此事要躬行”。战略难么？真的不难！你去京东搜索一下“战略”，你会发现讲战略的书如过江之鲗，买一本都能告诉你各种方法论、思考点。但那些毕竟都是书上来的知识，实际中真的可用？你是不是满头问号？

而有趣的点也就在这里，不知是不是因为很多人穷其一生都没有机会实现战略落地，所以“讲战略”好像也就变成了一个很高端的事情，而且成本很低——毕竟你说的也不可能被采纳，还能在挥斥方遒间提升 B 格，大家听也高兴。好像是双赢，嗯，谈战略的赢了两次，都赢麻了。

但一个没有能力躬身入局者提供的战略，你真的敢用？

缺少英文阅读能力

私心认为这点可以排名再高一点，但奈何前面几个的权重太高。

迄今为止，英文依然是这世界上信息量最多的语种，而敏捷的很多内容还是会以英文第一时间发表出来，如果没有一定的英文阅读能力，你将失去第一时间获得信息的机会，也会落入只能从“二手知识中学习”的窘境，这对任何敏捷从业者来说，都是一种较大的打击。

你的看法

上述只是我个人的一些粗浅的看法，加之主观因素较多，所以难免有失偏颇。如果您有其他想法，欢迎留言告诉我哦~谢谢~