敏捷开发真的“敏捷”?

初读张爱玲的《红玫瑰和白玫瑰》是在初中,15岁少不更事只看得出作者对活在情欲里男女的奚落和讽刺。后来经历的多了,发觉生活的琐事无不应验了张爱玲的话,娶了白玫瑰,最终成了桌上的米饭粒;娶了红玫瑰,也逃不过化成蚊子血的无奈。
碰到敏捷开发这个词的时候,脑海中浮现出的第一个念头便是如此。传统开发团队花一场2-3万的价格请敏捷教练做着培训,真正的敏捷团队则会摇摇头说:敏捷开发,其实一点也不“敏捷”。

敏捷开发不是开发方法

敏捷开发诞生的标志,是2001年2月,由Martin Fowler,Jim Highsmith等17位软件开发专家起草的敏捷宣言发表,敏捷联盟成立。

640.png

从这个配图,这个形式,你想到了什么?

640.jpg

20世纪90年代,软件开发过程日益变重,开发效率降低,响应速度变慢;21世纪,为了应对快速变化的需求,缩短交付周期,“敏捷开发”应运而生。

敏捷开发,从本质上来说是一种思想,和共产主义宣言一样——我们认同同样的价值观,也决心将这样的价值观发扬光大。而价值观本身,是不具备可操作性的。所以, 敏捷开发常会和XP、SCRUM等名词一同出现,前者是指导思想和原则,后者则是实打实的开发流程和方法。

SCRUM作为目前实践敏捷开发过程中,操作性较强、效果较为明显的开发方法,在国内外受到了普遍的推崇。

敏捷开发,可能一点都不“敏捷”

前几日,我向一位项目管理的大佬(参与英雄联盟手游项目)求教敏捷开发的问题,言语中透露出学习的渴望,希望敏捷开发能够改善团队中的种种问题,提升开发效率,大佬听后倒吸一口气,在国内的研发团队中绝不是个例。

【敏捷开发】因为顶着“敏捷”两个字,常被作为解决开发效率问题的灵药,其实这应该是一个翻译的问题。敏捷开发中的敏捷,更多是“灵活”“灵敏”之意。指的是对“变化”更加敏捷地响应,而不是针对开发效率。

客观上说,当团队由传统瀑布流转向敏捷开发的怀抱之时,你们的开发效率可能会被降低。

原因如下:

  • 更多的时间被花费在沟通上:敏捷开发强调沟通,沟通的频率和时长都会增加,以SCRUM为例:每一个迭代周期开始之前,都要对本次迭代的需求进行充分讨论,例如需求的规模、优先级等,对于新手团队,这个讨论极有可能是漫长低效的。

  • 学习成本更高:敏捷开发团队的内部,并不做非常详细的职责划分。与之前的分层开发中各司其职的情况相比,对成员的综合素质要求更高,即所谓“全栈工程师”。(当然,实际执行的过程中会有所变通,不会真的要求每个人都是全栈工程师)但是相比之前,必然会带来更多的学习成本,间接导致开发效率的下降。

  • 收集数据花费更多的精力:敏捷开发的成熟度越高,要求的数据越多,数据的收集会带来精力的消耗。假如工程师不能理解数据的意义,就会觉得自己在做无用功。

那我们还有必要去尝试敏捷开发吗?

方法本身是没有对和错的,红玫瑰白玫瑰各有各的绽放。万种风情的佳人不见得能天长地久,时间久了怕只剩下“中年女人的艳俗”。男人阴影里没有任何光泽的白玫瑰,也能在和裁缝的关系里绽放光彩。

要判断敏捷开发是否合适,你得明白要用敏捷开发解决什么问题。很多企业想转型敏捷开发的原因是“开发人员的效率低下,这么多人还完不成老板要开发的功能和速度”。就像我向大佬提出的问题一样,想提高开发人员的效率,更快地更多地开发出功能。

恐怕泼了凉水很多人也想不明白,因为敏捷开发不是用来解决所谓的“开发效率”问题的,提升开发效率可以从人的技能培养、流程优化、工具改进等方面来提升,而跟敏捷开发本身没太大关系。

开发团队向敏捷转型,本质上属于管理转型的一部分。它不是提升团队的工作效率,而是将整个研发体系,转变成能够更好响应市场快速变化的模式。它解决的是企业效益最大化的问题。绝不可从开发人员完成功能数量和速度的层面来评价。

下面我们来看一个敏捷培训中常常出现的翻铜板游戏,这会帮助你理解敏捷开发:https://v.qq.com/iframe/player.html?vid=f0318pmtfnf&tiny=0&auto=0

敏捷开发并不能提升每个人的开发效率(翻铜板的速度),但是快速交付能够避免一定的资源浪费,这能带来一定程度的变快。而最大的区别,还是在于这种开发方式对于变化的响应能力。

一个敏捷团队,相比于传统软件开发团队,最大的区别在于:

  • 拥抱变化。传统瀑布流开发方式,强调计划。而计划是死的,人是活的。计划执行过程中,有人休假、有人离开都会打破计划的执行,最终的结果就是delay。而敏捷开发的快速交付,可以拥抱这种变化。

  • 快速响应。市场环境的变化,越来越要求产品、服务的响应及时。比如按照传统方式,规划半年一个版本,一旦需要调整需求,后面所有的计划都得改变,会为项目管理带来极大的挑战,变化的成本奇高,多数情况下会因为多数人的反对而不了了之。

  • 快速将功能推向市场变现。前几年所有人口中的互联网思维都离不开八个字“小步快跑,快速迭代”,而这几个字的出处正是敏捷开发。我们不追求一次性推出大而全的产品,因为这让试错和调整的空间趋近于零。敏捷要做的,就是不停的推出产品,不停的调整。

  • 在有限的资源条件下,做最值得做的事。因为Backlog的每一项都具有按唯一优先级顺序,都是已经排好序了,敏捷要求逐项完成用户故事,而不是全面开花。因为其评价结果是二值的,做完就是1,做不完就是0,没有75%一说,因为做完了才能交付,做完了才能投向市场变现。什么事最值得做,什么事就优先级最高,需要一个复杂的评定过程,在之后的文章我们会详细说明。

最后

真正的敏捷团队会说:敏捷开发,其实一点也不“敏捷”,比如“齐悟”团队就不会说自己是敏捷开发团队。

你可能感兴趣的:(敏捷开发真的“敏捷”?)