浅谈敏捷:你的团队在正确实践敏捷吗?
引子
“今天加一下班把这个需求做了吧,老板催得很急。”--某时某厂某项目经理
敏捷,这个曾经作为灵活速度的代名词,在过去 20 年里逐渐发展成为 IT 界中被程序员们时常挂在嘴边的看似深奥的专业术语。敏捷开发(Agile Development)作为很多开发团队的项目管理框架首选,因为其简单、灵活,更重要的是它字面上暗示着 “快”。想一想无数码农为了赶进度而无偿加班吧。
敏捷 = 快速交付?
当你的开发团队遭遇项目延期、产品质量降低、士气低下以及客户关系恶化时,你的朋友或许会推荐你使用敏捷开发:“嘿,兄弟。我听说最近敏捷挺火的,你可以试一下。” 但是,当你在团队中推行敏捷一段时间后,你很可能会发现它并不好使:产品发布后依旧大量的bug、无穷无尽的加班、源源不断的最高优先级需求。在与老板的日常会议中,老板问你:“听说你们正在用敏捷来提升交付效率,很棒!所以我下周能看到之前给你提的重要功能吗?”
“敏捷就是快速交付”,这是很多敏捷实践者中最大的误区。其实,敏捷并不一定意味着快;相反,它还会引入更多额外工作,从而可能导致更慢的交付功能。对,你没看错。严格意义来说,敏捷会降低交付速度。例如,极限编程(XP,敏捷框架之一)要求为每一个功能编写单元测试,这会引入 1-2 倍的额外代码。





