为什么敏捷开发在中国的发展越来越极端化

敏捷开发在业内流传已久，自其思想进入国内以来还会时不时传出一些新的概念，很多概念如今听起来可能已经背离了初衷，就像Bullet Id Inc. 的 CTO，James Williams 所说的一样，敏捷开发已经逐渐地异化了。

近些年来，由于一些特定的需求，越来越多的软件团队开始采用敏捷开发模式，但是在开发过程中却对其思想认识不足，例如，有些敏捷开发团队甚至不设管理人员，只有一个向产品经理汇报的 scrum master，职责不比秘书强到哪里去。产品经理继续向上汇报，直到市场或销售总监，这种开发简直就是胡闹不是嘛。

排除软件公司，在很多常规企业中，敏捷开发很多已经异化为无人管理、无人负责的开发流程：产品经理、销售、CEO拍脑袋加功能、改需求，然后开发团队就赶快“敏捷”去吧。需求调研？设计？反馈？代码评审？测试？统统不需要。说好听点这叫敏捷开发，说不好听点，这就是技术大杂烩，能做到哪一步算哪一步，完全忽略了敏捷开发的实质，唯一的好处可能是说出去好听罢了。

这个问题延伸到HR也问题重重，在如此的需求下，HR的招聘可能就没有那么大的压力了，对面试者的经验做下简单筛选，简历上在丢一点不明觉厉的英文缩写，经验里写个“敏捷开发”，就可以招进来了，你们不是要敏捷开发者嘛，这人很合适啊。

当然了，骨灰级玩家的方式更胜一筹：上网随便找个敏捷开发的海外外包团队不就得了嘛。管他说的是什么话，会不会看书能不能读报听不听广播匣子，报价低就成了嘛。那么怎么管理外包团队？当然是管不了嘛。不用规划、没有进度、不设期限，否则还得为这个团队配个真正的经理，当然这经理是肯定没有的。

每到会议，scrum master可能都要听到“进度完不成”这句老话，然后产品经理再插上一脚，丢点新需求进来，优先级不用说了，客户急等着要。最终结果当然是需求变得稀奇古怪，进度早就不存在了。

而实际上，敏捷开发并不是这样来的，迭代的核心在于软件的超前规划，如果没有软件开发经理，所有人都在盲人摸象，造出来的全是 垃圾 -- 时间超限、预算超支、充斥着各种拍脑袋的奇思妙想、根本不管需求是不是合乎逻辑。客户肯定各种抱怨，需要产品支持怎么办？那就从一线开发抽人去维护嘛，结果是最好的码农一天被工单打断八百次。

一线人员每天花 8 个小时擦屁股，虽然如果管理流程良好这些问题根本不会出现；开发时间如果不够，那就 996 或者 9127。码农就是用来加班的。

产品延期了怎么办？告诉 scrum master 们（这些人身上经常挂个敏捷专家的标签，哪怕四体不勤五谷不分），需求变啦。有点能力的程序员肯定气的直接拉勾领英走起了，HR再招一群新兵蛋子进来。项目历史？遗留问题？设计思路？早就丢了。正好，推倒重来吧，周而复始。

这种恶习会侵蚀软件开发流程，除非让真正有能力、有经验的软件管理人员领导开发。装作“敏捷”，哪怕是软件开发的基础设施也会毁于一旦。

很多时候，对于优秀开发者，他们离职不是因为公司如何，是因为管理者糟糕。 让人痛心疾首的是，很多公司放弃了井井有条的管理而选择了所谓的敏捷。

所以，管理不规范的企业，不建议以敏捷开发的名头进行企业的信息化建设，本身会做成四不像。以目前正在使用的力软敏捷开发框架来说，其母公司是专门进行软件开发的企业，自从进入敏捷开发以来，已经对产品进行了9年的升级，每一次升级都需要经过多次超前的规划和论证，一个专业的开发公司尚且如此，普通企业就更不用说了。想要根据所谓产品经理的建议，再弄几个程序员就搞出一个合格的敏捷产品，无异于异想天开。

而敏捷开发除了要具备完善的功能，还要有较高的灵活性，与其费力的做出一个未知的产品，不如老老实实按照规矩来，这样可能才是对企业是最有利方式。