敏捷开发正在成为一种宗教，这是一个不争的事实。越来越多的人对敏捷开发狂热，但是却并不了解敏捷的真正内涵。这种现象导致了许多人肆意改造敏捷的内核，从而使得敏捷开发变得失去了原本的意义。
敏捷开发是一种敏捷软件开发方法，它强调的是快速响应变化和持续交付价值。敏捷开发的核心是团队合作、快速反馈和持续改进。然而，现在很多人并不了解敏捷的真正内涵，他们只是听说过敏捷开发，就开始狂热地追求敏捷。
这种狂热的追求导致了许多人肆意改造敏捷的内核。他们口中的敏捷开发,意思就是要开发言出法随,开发承担一切,包括软件的交付运维,业务的梳理等等,一切规范和流程都可以省去。
更糟糕的是，有些人甚至开始将敏捷开发变成了一种宗教。他们认为敏捷开发是唯一的真理，只要喊敏捷开发的口号就能成功。他们开始强制团队成员遵循敏捷开发的规则，忽略了团队成员的个性和创造力，将开发人员都当做工具人使用。不知道多少项目和公司前仆后继的投入到敏捷，但是不断失败，敏捷教练会以各种话术，让公司和项目继续坚持，毕竟敏捷就是要不断试错嘛。
他们狂热的追求和肆意改造敏捷的内核，使得敏捷开发失去了原本的意义。甚至常常只说一句话，都不容许开发人员质疑，或者开发人员想要明确需求的诉求。
这里引述一个阐述敏捷时常举得例子：
如果用敏捷的方式盖房子
在讲瀑布模型的时候，我拿盖房子举了个例子，如果改成用敏捷开发的模式盖房子，则会是这样子的：
客户想要盖一栋房子（初步的想法）。
产品经理和客户进行了初步的沟通，把用户的需求写成了一个个用户故事（用简单的用户故事代替繁重的需求文档），例如：
作为一个上班族，我想要一个卧室，以便于休息；
作为一个家庭主妇，我想要一个厨房，以便于做饭。
施工人员根据用户故事和客户进一步沟通（客户合作高于合同谈判），然后对用户故事进行设计和实现；
每个用户故事开发时，还要给一个测试机器人编写测试脚本，让机器人可以自动测试（大量采用自动化测试），并且做好的用户故事可以随时被测试验收（随时发布，持续集成）；
每个 Sprint 四个星期时间（时间盒子，迭代时间固定）；
第一个 Sprint 搭了个草棚，一张床就是卧室，厕所就挖了一个坑，厨房还来不及搭建（每个 Sprint 会选择高优先级的用户故事），屋顶还在漏水（每个 Sprint 会定期发布，客户可以随时看到可用版本，即使还不完整）；
第二个 Sprint 有了简易厨房，同时修复了屋顶漏水的毛病（每个 Sprint 不仅完成用户故事，还会修复 Bug）；
第三个 Sprint 升级成了小木屋，但是忘记加上窗户（敏捷推崇自动化测试，但可能会测试不完备）；
第四个 Sprint 升级成了砖瓦房，窗户也开好了，客户可以入住。但是这时候客户发现一家三口的话，完全不够用，需要扩建到 3 个卧室。于是决定下个迭代改成 3 个卧室（咱们还是讨论情感 房子 票子 比较好 ）；
第五个 Sprint，升级成了 3 个卧室，升级过程中把厨房下水道弄坏了（迭代过程中可能会导致质量不稳定）；
第六个 Sprint，修复了下水道的问题，房子也装修好了（迭代中不断完善）；
客户验收使用（上线）。
用敏捷开发的方式，不再像瀑布模型那样有严格的阶段划分，会在迭代中不断完善；不再写很多文档，而是和客户一起紧密合作；不再抵制需求变更，而是即时响应变更；不再等到测试阶段才发布，而是随时发布，客户随时可以看到东西。
看起来很美好是吗？但是似乎没有人关心这里面存在的问题！你每一次搭建和改造房屋的成本谁来承担？！有住过豆腐渣工程造的房子的人都应该清楚，房顶漏水了不是那么容易修复！等你房屋建好了，发现窗户没有，这时候发现人家要坐北朝南，窗户也要朝南，而你承重墙在南面！！！你房屋建好了，发现没有预留下水管道燃气管道，还要再砸开，重新埋设！！！谁教你这么做的！！！
我们需要重新审视敏捷开发的真正内涵。敏捷开发不仅仅是一种流程，更是一种价值观和文化。我们需要强调团队合作、快速反馈和持续改进，而不是机械地遵循流程，但也要讲究科学的方式方法。我们尊重团队成员的个性和创造力，但是在此之前你也要熟悉标准的作业流程，发现其中的痛点！
总之，敏捷开发正在成为一种宗教，这是一个不争的事实。我们需要重新审视敏捷开发的真正内涵，强调团队合作、快速反馈和持续改进，尊重团队成员的个性和创造力，才能真正实现敏捷开发的价值。
网友评论