敏捷开发诞生的标志，是2001年2月，由Martin Fowler，Jim Highsmith等17位软件开发专家起草的敏捷宣言发表，敏捷联盟成立。
但是，敏捷开发，可能一点都不“敏捷”。
敏捷开发，因为顶着“敏捷”两个字，常被作为解决开发效率问题的灵药。
其实这应该是一个翻译的问题。敏捷开发中的敏捷，更多是“灵活”“灵敏”之意。
指的是对“变化”更加敏捷地响应，而不是针对开发效率。
客观上说，当团队由传统瀑布流转向敏捷开发的怀抱之时，你们的开发效率可能会被降低。
原因如下：
1、更多的时间被花费在沟通上：敏捷开发强调沟通，沟通的频率和时长都会增加，以SCRUM为例：每一个迭代周期开始之前，都要对本次迭代的需求进行充分讨论，例如需求的规模、优先级等，对于新手团队，这个讨论极有可能是漫长低效的。
2、学习成本更高：敏捷开发团队的内部，并不做非常详细的职责划分。与之前的分层开发中各司其职的情况相比，对成员的综合素质要求更高，即所谓“全栈工程师”。（当然，实际执行的过程中会有所变通，不会真的要求每个人都是全栈工程师）但是相比之前，必然会带来更多的学习成本，间接导致开发效率的下降。
3、收集数据花费更多的精力：敏捷开发的成熟度越高，要求的数据越多，数据的收集会带来精力的消耗。假如工程师不能理解数据的意义，就会觉得自己在做无用功。
要判断敏捷开发是否合适，你得明白要用敏捷开发解决什么问题。很多企业想转型敏捷开发的原因是“开发人员的效率低下，这么多人还完不成老板要开发的功能和速度”。
恐怕泼了凉水很多人也想不明白，因为敏捷开发不是用来解决所谓的“开发效率”问题的，提升开发效率可以从人的技能培养、流程优化、工具改进等方面来提升，而跟敏捷开发本身没太大关系。
开发团队向敏捷转型，本质上属于管理转型的一部分。它不是提升团队的工作效率，而是将整个研发体系，转变成能够更好响应市场快速变化的模式。它解决的是企业效益最大化的问题。绝不可从开发人员完成功能数量和速度的层面来评价。
网友评论