关于敏捷的慢思考（3）

上一次我们聊了一下关于敏捷的实践性问题，今天我们就来聊聊任何敏捷实践过程中一定会出现的问题，那就是“误区”。

在开始之前需要申明，我能写下来的，都是我已经知道且与当事人沟通过的内容。这些误区也仅仅是我个人所认为的误区，可能不适用所有人，请悉知。

在这里没有任何打算和老前辈为敌，但这句话真的有点问题。

首先，敏捷不是在所有场景都适用的，比如建筑施工领域。一心想将敏捷打造成一个通用或者万能的方法，注定是徒劳的。否则四大IT咨询公司、IBM等高管岂不是早就集体高潮了，一招鲜能省去多少的培训成本！

其次，敏捷的适用场景是有限的，“需求不确定”、“可以增量交付”这种敏捷基本的要求还是需要具备的。这些在To B领域中，尤其是涉及到“合规性”的行业中，能满足这种需求的项目是有限的。所以针对这种领域，敏捷不一定能够带来翻天覆地的变化。当然，任何时候使用敏捷的工程实践，包括但不限于TDD、持续重构，对于项目本身都是有益的。

这个误区已经给说烂了。

虽然敏捷从字面上意思是有那么点的快的意思，但敏捷的精髓还是在于“准确交付客户真正需要的价值”。如果一味单纯求快，可能会适得其反。

跟上条一样，从“快”进行了不恰当的延伸。一旦“快”这个误区被攻破了，那质量问题的误区也就烟消云散了。

这条不能说完全错。因为当你将任务拆分到足够小的时候，工作的确是会以瀑布的形式进行开发。比如验收测试一定会要等到开发、测试完成后才能正常进行。

但是这种足够小的任务，并不能单独成为“可交付、对客户有价值的”需求，所以必须要若干个这种类型的工作才能满足这种条件。而这若干个需求之间，就不太可能呈现瀑布的形式了。

具体见下图。上半部分在单个足够小的任务时，是成立的。但是对于“有价值”的需求，就是下面的部分成立了：

瀑布 VS 敏捷

拉出去打屁股。有这种疑问的，请回去将敏捷软件开发宣言给“熟读并背诵”。各位至圣先贤说的很明确了，“更重视”而不是“不要”右侧部分。

恭喜你，你已经掌握了“中华田园敏捷”的精髓，或者叫“BDD，Boss Driven Development”。

理论上，这种不能叫完全错误，只能说在部分场景下不适用。比如对于Scrum这种由明显迭代周期的敏捷框架，我们一般不建议随时改动，因为这种改动的成本除了一开始的计划成本之外，还会有较大团队士气的损耗，反而当所谓的“灵活”得不偿失。而对于Kanban、XP这种，由于该类框架更多是讲求“快速交付”，所以有可能出现“你还没有改我多开发完了上线”的可能性，因此相对来说影响会小很多。

这个近年来少了一些。现在不少制造型企业开始讲求“敏捷制造Agile Manufacturing”，而我2019年末也在某世界500强制造业公司为其导入敏捷，并且该公司从上而下开始推动敏捷，敏捷已经成了公司级别的战略因素。

当然，我们也不得不承认，由于制造业的特殊性，当前制造业的敏捷化转型，主要还是集中在设计、继承方面，而且也是大量依赖CAD技术来减少前期磨具的开发、提升集成的效率。一言蔽之，将传统硬件通过软件模拟的方式来进行开发，从而减少前期设计、返工的工作量。一旦进入生产设计阶段，在精益生产面前，大家都是弟弟。

写到这里也差不多该结束了。其实对敏捷的误解是无处不在的，如果我们日常仔细观察，从研发小伙伴、公司领导、高层，甚至我们的SM伙伴，都能看到很多。

误解不是问题，误解是我们持续前进的一个契机，这也是敏捷可以让我们持续改进、让我们更加美好的原因。

下一次我想聊点轻松的话题，聊一下现有敏捷培训的那些事儿吧。