真正的敏捷团队会说：敏捷开发，其实一点也不“敏捷”。

初读张爱玲的《红玫瑰和白玫瑰》是在初中，15岁少不更事只看得出作者对活在情欲里男女的奚落和讽刺。后来经历的多了，发觉生活的琐事无不应验了张爱玲的话，娶了白玫瑰，最终成了桌上的米饭粒；娶了红玫瑰，也逃不过化成蚊子血的无奈。

当我拿到敏捷的命题，脑海中浮现出的第一个念头便是如此。传统开发团队花一场2-3万的价格请敏捷教练做着培训，真正的敏捷团队则会摇摇头说：敏捷开发，其实一点也不“敏捷”。

敏捷开发不是开发方法

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

从这个配图，这个形式，你想到了什么？

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

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

SCRUM作为目前实践敏捷开发过程中，操作性较强、效果较为明显的开发方法，在国内外受到了普遍的推崇。所以在今后的系列文章中，我们将选择SCRUM作为敏捷开发的具体开发方法，进行介绍。毕竟，我们不能去围绕着一个虚无的概念和价值观去讨论和学习。

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

前几日，我的一个朋友向我咨询敏捷开发，言语中透露出对目前研发团队现状的担忧，希望敏捷开发能够改善团队中的种种问题，提升开发效率。像我这位朋友这样的情况，在国内的研发团队中绝不是个例。

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

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

原因如下：

• 更多的时间被花费在沟通上：敏捷开发强调沟通，沟通的频率和时长都会增加，以SCRUM为例：每一个迭代周期开始之前，都要对本次迭代的需求进行充分讨论，例如需求的规模、优先级等，对于新手团队，这个讨论极有可能是漫长低效的。
• 学习成本更高：敏捷开发团队的内部，并不做非常详细的职责划分。与之前的分层开发中各司其职的情况相比，对成员的综合素质要求更高，即所谓“全栈工程师”。（当然，实际执行的过程中会有所变通，不会真的要求每个人都是全栈工程师）但是相比之前，必然会带来更多的学习成本，间接导致开发效率的下降。
• 收集数据花费更多的精力：敏捷开发的成熟度越高，要求的数据越多，数据的收集会带来精力的消耗。假如工程师不能理解数据的意义，就会觉得自己在做无用功。

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

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

要判断敏捷开发是否合适，你得明白要用敏捷开发解决什么问题。很多企业想转型敏捷开发的原因是“开发人员的效率低下，这么多人还完不成老板要开发的功能和速度”。就像我前文提到的朋友说他们也是出于这个目，想提高开发人员的效率，更快地更多地开发出功能。

我当时就给这个朋友泼了凉水，因为敏捷开发不是用来解决所谓的“开发效率”问题的，提升开发效率可以从人的技能培养、流程优化、工具改进等方面来提升，而跟敏捷开发本身没太大关系。

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

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

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

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

• 拥抱变化。传统瀑布流开发方式，强调计划。而计划是死的，人是活的。计划执行过程中，有人休假、有人离开都会打破计划的执行，最终的结果就是delay。而敏捷开发的快速交付，可以拥抱这种变化。
• 快速响应。市场环境的变化，越来越要求产品、服务的响应及时。比如按照传统方式，规划半年一个版本，一旦需要调整需求，后面所有的计划都得改变，会为项目管理带来极大的挑战，变化的成本奇高，多数情况下会因为多数人的反对而不了了之。
• 快速将功能推向市场变现。前几年所有人口中的互联网思维都离不开八个字“小步快跑，快速迭代”，而这几个字的出处正是敏捷开发。我们不追求一次性推出大而全的产品，因为这让试错和调整的空间趋近于零。敏捷要做的，就是不停的推出产品，不停的调整。
• 在有限的资源条件下，做最值得做的事。因为Backlog的每一项都具有按唯一优先级顺序，都是已经排好序了，敏捷要求逐项完成用户故事，而不是全面开花。因为其评价结果是二值的，做完就是1，做不完就是0，没有75%一说，因为做完了才能交付，做完了才能投向市场变现。什么事最值得做，什么事就优先级最高，需要一个复杂的评定过程，在之后的文章我们会详细说明。

最后

写了这么多，想必各位看官已经对敏捷开发的概念有了一定的理解。在之后的文章里，我们将会带您全面地走进敏捷开发的世界，我们拒绝掉书袋，一切以实践和可操作性为主。敏捷开发究竟是蚊子血还是朱砂痣，待你真正理解之时自会有答案。

同时，如果您对敏捷有何疑惑或者是独到见解，我们也欢迎您在文章下方留言。

关于敏捷开发的问题将会邀请Worktile首席架构师徐子岩，在系列结束之时为大家一一回答，敬请期待。

#专栏作家#

袁林，人人都是产品经理专栏作家。分享SaaS运营和企业管理／协作／办公的相关知识

本文原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Pexels，基于 CC0 协议