上一次我们聊了一下关于敏捷的实践性问题，今天我们就来聊聊任何敏捷实践过程中一定会出现的问题，那就是“误区”。
敏捷误区怎么来
敏捷误区这事儿吧，年年说年年有、处处说处处有。用一句不太恰当的话来说就是——这玩意就跟蟑螂一样，你看见的在那，你看不见的，其实已经遍地都是。
形成这种局面的原因，一方面在于敏捷自身足够“精简”，留个大家各种遐想。在这种情况之下，“一万个人眼中有一万个哈姆雷特”的事情，在敏捷身上又重演了一次；另一方面也是最近这些年敏捷开始火起来之后（包括但不限于敏捷本身、Scrum Master、DevOps、SRE、SAFe、LeSS等不一而足），各种培训机构跟打了鸡血一样的宣传敏捷概念，努力营造“敏捷万能”、“敏捷牛逼”、“先有敏捷后有天”的氛围，也让国内部分行业，特别是IT行业从业者对敏捷有了有些不切实际的期待。而最后一个方面比较特殊：在敏捷推进的过程中，部分咨询师、敏捷教练因为实际情况做了一定的妥协，导致有一些“技术动作变形”（没有任何嘲讽，这是所有敏捷教练都会遇到的问题，甚至是很多中小型企业为了敏捷转型而必须要做的妥协），而这些技术动作变形如果不经过仔细分析，也会对很多后来者造成一些困扰。
而对于我们这种敏捷从业者来说，我们只能尽自己最大的努力来为学员、客户消除这种不切实际的幻想，用我们绵薄之力来将走偏的车轮再推回来一些。
常见敏捷误区
在开始之前需要申明，我能写下来的，都是我已经知道且与当事人沟通过的内容。这些误区也仅仅是我个人所认为的误区，可能不适用所有人，请悉知。
敏捷无敌
在这里没有任何打算和老前辈为敌，但这句话真的有点问题。
首先，敏捷不是在所有场景都适用的，比如建筑施工领域。一心想将敏捷打造成一个通用或者万能的方法，注定是徒劳的。否则四大IT咨询公司、IBM等高管岂不是早就集体高潮了，一招鲜能省去多少的培训成本！
其次，敏捷的适用场景是有限的，“需求不确定”、“可以增量交付”这种敏捷基本的要求还是需要具备的。这些在To B领域中，尤其是涉及到“合规性”的行业中，能满足这种需求的项目是有限的。所以针对这种领域，敏捷不一定能够带来翻天覆地的变化。当然，任何时候使用敏捷的工程实践，包括但不限于TDD、持续重构，对于项目本身都是有益的。
敏捷就是快
这个误区已经给说烂了。
虽然敏捷从字面上意思是有那么点的快的意思，但敏捷的精髓还是在于“准确交付客户真正需要的价值”。如果一味单纯求快，可能会适得其反。
敏捷项目质量不如传统项目管理
跟上条一样，从“快”进行了不恰当的延伸。一旦“快”这个误区被攻破了，那质量问题的误区也就烟消云散了。
敏捷就是小瀑布嘛
这条不能说完全错。因为当你将任务拆分到足够小的时候，工作的确是会以瀑布的形式进行开发。比如验收测试一定会要等到开发、测试完成后才能正常进行。
但是这种足够小的任务，并不能单独成为“可交付、对客户有价值的”需求，所以必须要若干个这种类型的工作才能满足这种条件。而这若干个需求之间，就不太可能呈现瀑布的形式了。
具体见下图。上半部分在单个足够小的任务时，是成立的。但是对于“有价值”的需求，就是下面的部分成立了：
瀑布 VS 敏捷
敏捷不需要计划、文档
拉出去打屁股。有这种疑问的，请回去将敏捷软件开发宣言给“熟读并背诵”。各位至圣先贤说的很明确了，“更重视”而不是“不要”右侧部分。
敏捷的范围、设计可以随时变
恭喜你，你已经掌握了“中华田园敏捷”的精髓，或者叫“BDD，Boss Driven Development”。
理论上，这种不能叫完全错误，只能说在部分场景下不适用。比如对于Scrum这种由明显迭代周期的敏捷框架，我们一般不建议随时改动，因为这种改动的成本除了一开始的计划成本之外，还会有较大团队士气的损耗，反而当所谓的“灵活”得不偿失。而对于Kanban、XP这种，由于该类框架更多是讲求“快速交付”，所以有可能出现“你还没有改我都开发完了上线”的可能性，因此相对来说影响会小很多。
敏捷只适用于IT行业
这个近年来少了一些。现在不少制造型企业开始讲求“敏捷制造Agile Manufacturing”，而我2019年末也在为某世界500强制造业公司导入敏捷，并且该公司从上而下开始推动敏捷，敏捷已经成了公司级别的战略因素。
当然，我们也不得不承认，由于制造业的特殊性，当前制造业的敏捷化转型，主要还是集中在设计、继承方面，而且也是大量依赖CAD技术来减少前期磨具的开发、提升集成的效率。一言蔽之，将传统硬件通过软件模拟的方式来进行开发，从而减少前期设计、返工的工作量。一旦进入生产设计阶段，在精益生产面前，大家都是弟弟。
敏捷会被DevOps 取代
提前说明，我个人是DevOps Master 持证者，也是DevOps Professional 的TTT讲师，同时也是EXIN Agile Scrum Master TTT讲师、PMI-ACP授权讲师，对敏捷、Scrum以及DevOps 的价值的认知也很明确。这里仅仅是想表达一下DevOps 与敏捷的关系，不存在孰优孰劣，请勿引战。
“敏捷会被DevOps 取代”，大概就是“五常大米将会被八宝粥”取代的变形。
如果认真去看DevOps 白皮书，你会发现DevOps大概可以看成“精益”、“敏捷”和ITIL的混合。而结合这篇文章我们可以将敏捷与精益一定程度上统一化。而随着最新的ITIL 4的问世（抱歉，只是粗读了一下ITIL 4 Foundation的内容）以及最新DevOps 的业内做法，我们可以将DevOps=敏捷/精益+ITIL +工程实践联系在一起。
其中ITIL 和工程实践是可以有相关标准和最佳实践（这里最佳实践不妥，但找不到其他词来形容），所以这部分工作是有迹可循。然后DevOps 就变成了敏捷+某些有迹可循的工作（绝大多数是工程实践）。
OK，DevOps 和敏捷站在了同一个起跑线。
当然，我没有任何对DevOps 不敬的意思，我对业内大牛，比如张乐老师、许峰老师是非常尊重，我也知道还有众多其他的DevOps 践行者在为DevOps 添砖加瓦，这都让DevOps 变得更加美好。但我们也必须直视一个现实问题——DevOps 并不是救世主，DevOps 也不是下一个敏捷，它仅仅是将敏捷的概念扩大到了交付层面，不然敏捷只关注于开发。而如果你认真读，你会发现在Ops这层，其实也并没有太多的深意被发掘，也还是围绕在敏捷的快速交付、快速迭代方面，只不过此处的交付不再是单独将代码交出来，而是部署上线，真正的“交付”。
换言之，如果你将DevOps 拆分成两块，Dev和Ops的话，你可以将任意一个部分都用敏捷框进去。而框进去的代价，就是我们需要增加更多的工程实践、让Flow 这个概念流传的更广，范围更大。
所以DevOps 在我眼中，它是敏捷的改良，而不是敏捷的替代者。
大规模敏捷
这条存疑，不算绝对的误解，记录在这里，欢迎高手打脸。
对我个人而言，我是不会说什么“大规模敏捷”的，我倾向于的说法是“我们用敏捷方式管理小团队”，然后“用不那么敏捷的方式（主要是对依赖的处理）来解决团队间的问题”。
这里不是蹭热度，随着去年一堆人对SAFe的群起而攻之，大规模敏捷好像走到了一个比较尴尬的境地。而对此，我只能说“该”。
如果你深入任何一项大规模敏捷框架，你都会发现，所谓大规模敏捷本身都会存在一个前提——需求可以被拆分成足够小、没有依赖的需求集合。只有在满足这个要求的前提下，大规模敏捷才可能成为现实。否则连用户故事的INVEST（详细解释看这里)）这一关都过不去。
在这里，最困难的一关是“I”，也就是独立性。如果需求之间没有独立性，结果必然是在团队内部或者团队外部产生依赖，从而一定程度上回归到过去瀑布的四种任务关系（开始-开始，开始-结束，结束-开始，结束-结束）方面去，这个过程中，敏捷自然会受到弱化，甚至会回退到瀑布状态。
注意，这里并不是说一定的瀑布不好，有时候这是一种妥协的表现，在工作中是合理且必要的。我想表达的是，既然说了“大规模敏捷”，那么就需要尽可能的符合敏捷的特性。我们在说到敏捷时，每个人都可以将INVEST背的滚瓜烂熟，奉为经典，那为何在大规模敏捷时，就有可能出现这种情况？
当然，你可以直接打脸——哼，我的团队就没有，我的大规模敏捷团队的需求，都是相互独立，没有关联性。
OK，既然功能都已经没有关联性了，那么为什么你要说这是一个“大规模敏捷”而不是“多个敏捷团队”呢？
再次强调，我没有诋毁任何敏捷框架，无论是LeSS还是SAFe或者S@S或者Nexus等等其他各种。我只是从敏捷本身对其进行论证后，得出这个结论，仅此而已。当然也希望各位扩展敏捷高手前来打脸。
尾声
写到这里也差不多该结束了。其实对敏捷的误解是无处不在的，如果我们日常仔细观察，从研发小伙伴、公司领导、高层，甚至我们的SM伙伴，都能看到很多。
误解不是问题，误解是我们持续前进的一个契机，这也是敏捷可以让我们持续改进、让我们更加美好的原因。
下一次我想聊点轻松的话题，聊一下现有敏捷培训的那些事儿吧。