阿里工程师思考：敏捷开发的根本矛盾是什么？

敏捷开发不仅靠流程和技巧，更需要企业文化的支撑。今天借“敏捷开发”的话题，与大家探讨一个更深层的问题：工程师如何在控制性和创造性中找到平衡点？生产的严谨和创造的不严谨性怎么解决？

本文的作者是来自阿里IoT事业部的济巅，毕业于浙江大学，在无线通信行业从事技术研发10多年，从2006年开始敏捷开发实践，目前从事无线物联网技术的研发。

失控

时光荏苒，转眼间从事程序员这份很有前途的工作已经十多年。

差不多10年前，在Bas Vodde的极力推广下，我当时所在的开发小组开始实施敏捷开发(Agile)模式。这大概也是中国最早的一个敏捷小组吧（后来Bas开了自己的敏捷培训机构，同事中有的转行也成了中国最早的一批Agile认证培训师）。经过了这么多年，回想一下，心里有了很多感触。现在总结一下，也许会对现在的敏捷开发有所启发。所有的文字都是绝对独家，在敏捷手册里你可找不到。 :-)

现在说起敏捷开发，往往会遇到两个极端：要么很好，要么很糟！这和当年软件企业推广ISO9000或者后来的CMM区别很大。

做ISO9000对企业来说就是做出一堆文档，装帧漂亮后，放进文件柜，锁好，然后……就没有然后了。所有工程师们对这些内容基本无感。ISO9000毕竟诞生于传统的机器生产工业时代，用这套老办法来衡量新兴的不断变化中的软件企业，实在有些别扭。

然后就有了CMM。CMM（Capability Maturity Model for Software）听着就大气了很多，“软件能力成熟度模型”，不是什么冰冷的“标准”，程序员们看着这个模型就受用很多。一家企业能评上CMM的高级别是件很荣耀的事情。一时间各企业纷纷大上快上CMM评级。但是在CMM实施过程中，很多一线程序员仍然无感。最大的区别就是锁在柜子里的由一堆工业标准文档变成了另一堆更有软件业特色的标准文档。而且在所有获得了CMM5级的顶尖企业中，某国的软件外包企业占了很大的比例，而一些无论从技术含量、创新能力或产品品质都属于全球顶尖的企业却只获得了更低的3或4的评级。这其实是很奇怪的事情！

其实，无论ISO9000还是CMM，它们的核心都在于“控制”。

管理者们希望通过各种流程、各种规则来控制软件开发过程中的信息、思想、行为，来获得对未来的产品的安全感。

但是软件世界早就在不知不觉中发生了巨变。最典型的例子就是Linux。

人们传统印象中，操作系统是最复杂的软件系统。要制作出这样的系统，一定是世界顶尖公司里的大量一流程序员在严密科学的流程管理制度下完成的。就如IBM和微软所做的那样。但Linux居然是由分布在全世界各地、成千上万名互相不认识的程序员来完成的！没有繁琐的流程、坚硬的规章制度、专职的直线经理、强硬的项目经理，在几乎一切的传统管理手段都缺位的情况下，软件行业的一个划时代的伟大产品却诞生了！而这是前所未有的事情。

十多年前，微软无疑是世界上的IT业霸主。记得1998年前后有一本在业界很有影响力的书叫做《Microsoft Secrets》，这本书从微软公司内部各个层面揭示了微软是如何运行的。当时给我印象最深刻的就是微软的Daily Build和Auto Testing系统。这是当时大多数软件公司想都不敢想的软件工业之理想境界，而拥有当时最复杂而庞大的Windows95与Office代码库的微软居然能够做到！要知道Windows95的代码量大概有1500万行左右，这完全超出了当时绝大多数软件企业的能力。

时过境迁，现在很多软件企业、第三方组织都已能够轻松建立起这种代码规模系统的自动集成系统，甚至更大的代码规模也不在话下。计算机软硬件技术及网络技术的发展，已经使小规模的开发组织获得了空前的快速迭代能力。

工具的进化引发的人类协作方式的变化其实并不罕见，最典型的是武器与军队组织形态的变化。武器越来越精确、威力越来越大、射程越来越远，原来需要大规模地面部队付出很大代价才能完成的地面攻击任务，现在只需要较少数量机动灵活的地面部队依托各军种远程火力支援就能完成了。这时与敌人直接接触的一线部队规模虽然变小了，但他们能召集的火力其实是更大了。同时，每个士兵的能力要求也不同了。他不仅要懂怎么用自己手中的枪，还要懂步坦协同、炮兵战术、空地一体打击、远程侦察、电磁压制，甚至未来的个人战场网络系统。因为士兵本身也是武器系统的一部分。一流的武器落在三流的士兵手里也只是多了一根烧火棍。这种例子在现代战争中屡见不鲜，比如全美式现代化重装备的某国政府军屡次被一些灵活机动的游击队整建制地击溃。

现在的网络技术能越来越快速地把个体创造的信息连结到一起，最后这些信息以一种新的形态展现出来，成为新的产品。组织形式越能匹配这种趋势，组织就越能把组织内外的信息价值有效组合起来，形成自身的信息价值或产品价值。（从这个意义上讲，那些在线SAAS就是这个目的。如果那些开发SAAS的软件公司能够敢于把自身的组织运作完全基于SAAS，那么它离成功也就不远了！）

在产品开发团队中，使用什么模式能更有效完成这个信息连结？

无论是传统开发模式，还是敏捷开发模式，其目的是相同的：都是为了开发出好的产品和服务，但手段其实大不同：一个是用尽量控制的手段，而另一个是用尽量不控制的手段。这个就如传统教育和现代教育之间的区别：我们究竟是要把孩子人生中最重要的选择权交给孩子自己，还是竭尽全力代替孩子做一个看似最完美的选择？这个答案在中国这个转型中的传统大国中见仁见智。传统开发模式好，还是敏捷开发模式好？这个答案在现在这个互联网时代成型期，自然也是见仁见智的。

无论如何，“在代码中创造世界，在失控中享受自由”，也许就是程序员这个职业的乐趣所在。

扁平

2007年初第一次见到Jeff Sutherland本尊。他标志性的一头油亮亮的白发打理得整齐精神，加上紧身笔挺的西装领带，更像一个精干的华尔街精英，而不是程序员。但他确实是一名程序员：他不仅能码代码，还写了怎么码代码的书。

他还有一个身份：Scrum敏捷管理的创始人。

很多有名的洋程序员的职业经历和国内的程序员很不一样。Jeff就是这样。

Jeff之前是一名职业军人，但不是普通的大头兵。他毕业于the United States Military Academy（也就是西点军校），后成为美国空军RF-4C战斗侦察机部队指挥官中的精英，在越战中的执行过大量战斗任务。入行IT界还是11年军事生涯结束后去大学读博士的事了。所以在他Scrum方法体系中也能看出在世界顶尖空军部队服役的经历对他的影响。

残酷的战争使人们面临生死存亡的竞争，在这种压力下，人们会最大限度地摒弃一切多余的条条框框、改进组织制度，以提高自己的作战效能和存活的几率。

美军在20世纪60年代就建立了领先于全球的C4I系统。什么是C4I？C4I就是指挥、控制、通讯、电脑和情报的集成系统，通过计算机及网络通讯技术，对战斗人员和武器进行指挥和控制。这样的系统和组织方式实现了高效又灵活的信息流，比如，它不仅能够实现武装部队总司令（也就是美国总统）在1-3分钟内能够把命令下达到第一线的作战部队，而且一线的士兵也可以轻易获得整个战场的情报。同时，美军的组织结构和指挥系统也进行了改革，推行了“任务式命令”（“委托式指挥法”），最大限度地将作战决策权下放到各级作战单元，以最大发挥各级人员的主动性。甚至后来还用法律的形式确定了这种自主决策权，打破了海陆空各军种之间壁垒，大大减少了指挥的层次。因此，美国得以凭借不是很多的常备军力，却能在全球范围内快速有效地应对各种各样的威胁和挑战（BTW，对于中国军事现代化，大家经常把注意力只集中在新的武器上，其实军事组织的扁平化并不比制造歼20的发动机更简单，甚至更重要）。

整个美军的军事系统就是一个超大型的“企业集团”，里面有各种各样差异巨大的“事业群”，大的可分为空军、海军、陆军、海军陆战队，再分还可以分成各个高度专业的军种，它们的“业务”就是一起完成各种战斗任务、实现各种战术战略目标。“任务式命令”依托C4I系统实现了这个超大型团队的扁平化，从而最大化激发了各级团队成员的主动性和创造性。

信息技术实现了商品销售的扁平化、军事指挥的扁平化，它自然也会导致技术创新和产品研发的扁平化。Scrum的本质就是通过各种Scrum工具实现产品开发的扁平化管理，以最大限度的激发工程师的主动性和创造力。

有做项目管理的同学提出无法理解上一篇文章里提到的“尽量不控制”。这里举两个例子也许可以帮到有此类疑惑的同学。

Michael Jordan时代Chicago Bulls的传奇教练Phil Jackson一直有个习惯：他在赛场上很少去请求暂停，即便是球队落后的时候，他往往都是让球员自己去解决问题，除非是球队真的是出现了无法解决的问题。教练做的更多的是观察、协助、服务和启发的工作。

Steve Jobs虽然以极强的控制欲著称，但更被称为是个“好教练”，他“鼓励员工互相竞争”，“对于结果，他很苛刻，但总是非常公正”，“总是能让人受益匪浅”。苹果公司采用扁平的环状组织结构，员工的工作都“十分独立，只有很少的微观管理”。或者说，苹果的这种控制，更多的是拒绝平庸，而不是要控制工程师。

软件互联网产品开发风险有很多，根本上就是一个：“不确定性”。面对不确定性，更多地控制动作并不会使它变得更确定。也许正是因为这个优美的不确定性带来了更多的可能性和创造性，所以Donald Ervin Knuth和Eric S. Raymond会把Programming称之为艺术(Art)。面对“不确定性”，有时候管理者不妨“让子弹再飞一会”。

扁平化管理并不是敏捷开发的专利，但无论如何，扁平化并不容易实现，过程中会遇到各种各样的阻碍。有的阻碍来自组织能力，有的来自过去的成功经验，有的甚至来自文化习惯。（所以，有的时候组织没被拍扁，却被拍烂了。）

以前私下里曾和一位管理着一千多名跨国工程师团队的外籍VP聊起中国工程师和欧美工程师的差异，那个老外说不明白中国工程师为什么特别喜欢做管理岗位，技术职位做一阵子总想跳到管理岗位上。他反复问why，因为在他们国家完全不是这个样子……

在商业企业、特别是在以受过高等教育的年轻人为主体的IT企业中为什么会出现让外国资深研发管理者无法理解的现象呢？下面两个例子也许会提供一些线索。

案例一：以前在某公司曾同时带了几个开发团队。有一次其中一个team的一位中籍工程师私下找我做沟通，提出要个title，比如team leader、scrum master什么的，哪怕给个更小的头衔也行，甚至说不用给他涨年度工资、只要给个title都愿意。工作好多年了，因为没有一个“官衔”，他自己会被父母数落，遇到亲戚朋友同学问起来更会很丢脸！

案例二：在一次某公司开发部门中高层管理会议上，有的leader感叹：“我们这些做leader的很辛苦啊，下面有这么多工程师要养活！”其他很多leader们听罢也纷纷点头赞许。

……

外国工程师无法理解中国工程师的这些价值观和想法，反过来，中国工程师自然也难以轻易理解和接受工程师文化的价值观和方法论。

工程师文化广泛根植于欧美社会。在文艺复新时代，受卢梭等思想启蒙者的影响，上至王公贵族、下至平民百姓，大家都十分热衷于工具制作和技术创新。美国最有影响力的开国元勋和政治家Benjamin Franklin也是历史上著名的发明家。现在美国各地随处可见的巨大的五金工具商场，普通的美国家庭经常会拥有一套比我们的汽修店还要齐全的专业工具。这些都是和工程师文化一脉相承的。

但中国工程师对工程师文化既不熟悉，也不感冒。哪怕是那些自认很西化的中国人，无论他是否意识到，他的血液中也很难避免中国传统文化中的某个显性基因。

相对中国工程师，那些从小就热衷于自己动手进行工具和产品的持续改进创新的西方工程师显然更能适应敏捷。

管理离不开文化基础。扁平化的管理似乎更能与工程师文化相匹配。

扁平化的组织更能对事对结果负责、对总体目标负责。工程师文化，使上层和底层有很大的共性，上层听得懂下层在说什么，下层也听得懂上层在说什么。扁平的组织结构，使信息损失扭曲最小，上下层的信息都能互相听到。

……

一般来说，大家都认同“人才是IT企业的核心竞争力”。同时，很多组织也经常抱怨自己没有好的人才。这里举个例子来看看敏捷模式怎么帮助组织解决这个问题。

曾有一个比较大的开发项目，由超过两百名跨国软件工程师团队一同完成。按照当时的敏捷流程，产品构架设计每一次更新都会发给所有的工程师做review，以让所有工程师了解产品全局的需求和构架设计。有一次的关键构架设计书发出后，一位普通工程师指出了其中一个重要的构架漏洞，而当时所有的技术专家对这个漏洞都无法提出快速有效的解决方案。眼看milestone就要被推迟，最后还是这位并不在该领域工作的普通工程师通过自己的研究给出了解决方案。

Eric Schmidt在《How Google Works》中强调：“ When it comes to communications, default to open. Maximize the velocity and volume of information flow.”（谈到沟通，最基本的就是开放。这样使得信息流动的速度和数量最大化。）

但在扁平化的敏捷组织中，由于信息的充分流动，有才华的工程师可以有更多的机会给产品直接带来价值，也更容易因为自我实现而被“激励”。其实优秀的工程师就在那里，他们需要的只是一个没有信息围栏的舞台！

现在的世界已经是扁平的世界，充满不确定性！拥抱变化，就是要拥抱不确定性！任何一个管理者都不会认为一个热衷于迷幻剂、不会码程序的文青会成为全球IT界的大神，任何一个管理者也不会认为“一群找不到工作的年轻人”能创立世界上最大的电商企业。今天做游戏软件的公司，明天会去做手机；今天做支付系统的公司，明天会去造汽车、甚至星际火箭。信息围栏除了最终围住了自己的手脚和竞争力、其实什么也围不住。

计算机领域中有个古老而简单有效的算法叫冒泡排序（Bubble Sort）。Bubble Sort能够把一个失序的系统重新排序，同时并不需要把整个系统全部推倒重新排序，而只需要系统中的每个对象和自己身边的对象做个比较，根据比较结果来交换位置，这样只需要很少的几轮交换，最后整个系统就象气泡在水中自然而然地上浮那样自然而然地实现了排序。扁平化的工程师文化就象这个Bubble Sort一样，能够把整个组织中各个成员的创新和价值最快地呈现出来。

所以，不管是不是使用敏捷模式，信息的通畅高效流动都是工程师团队在充满不确定性的IT世界幸存的关键之一。管理是作为价值的连结者和传递者而服务于信息流动、服务于创造力。

某大侠曾说过：“员工的离职原因很多，只有两点最真实: 1、钱，没给到位; 2、心，委屈了。 这些归根到底就一条：干得不爽。”在BAT刚刚创立、都还没有成长为高富帅的时代，市面上软件工程师的薪水并不高。那时很多年轻人拒绝事业编制或公务员的职业机会而入了IT行业，其中重要原因之一就是被IT业“开放平等”的职场文化所吸引。所以我也一直很欣赏阿里的“花名”文化，它和外企中直呼英文姓名的传统有异曲同工之处，都是推崇一种“平等开放”的工作氛围，也有利于在研发部门建立起工程师文化。还有坚持实话实说的“阿里味”、横跨各个技术领域的ATA论坛（阿里内部技术交流社区）等等，都有利于信息的流动和组织的扁平化。这些都是管理服务于信息流动、服务于创造力的例子。

没有敏捷开发，也可能开发出好的产品。应用了敏捷开发，也未必能开发出好的产品。这就像很多企业都在学丰田的精益生产（Lean Production，或称看板生产），但能做到丰田那样的屈指可数。因为你可以学丰田的流水线和管理流程，但你学不到丰田的工程师文化！

无论如何，扁平化管理对于有长久工程师文化传统的欧美工程师也是很大的挑战，而对于中国工程师更是难上加难。对于那些下了决心要实施敏捷的组织来说，光靠那些老外的理论和经验是远远不够的，因为你将遇到那些老外从来不曾遇到的困难和问题。

殊途同归，几乎每个组织都在声称它多么地渴望变得敏捷灵活。但当真的面对敏捷型组织时，你真的准备好了么？