首页 互联网正文

敏捷开发在国内存在的问题

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

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

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

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

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

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

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

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

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

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

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

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

评论