阿里妹導讀：敏捷開發不僅靠流程和技巧，更需要企業文化的支撐。今天借“敏捷開發”的話題，與大家探討一個更深層的問題：工程師如何在控制性和創造性中找到平衡點？生產的嚴謹和創造的不嚴謹性怎么解決？
本文的作者是來自阿里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，或稱看板生產），但能做到豐田那樣的屈指可數。因為你可以學豐田的流水線和管理流程，但你學不到豐田的工程師文化！

無論如何，扁平化管理對于有長久工程師文化傳統的歐美工程師也是很大的挑戰，而對于中國工程師更是難上加難。對于那些下了決心要實施敏捷的組織來說，光靠那些老外的理論和經驗是遠遠不夠的，因為你將遇到那些老外從來不曾遇到的困難和問題。

殊途同歸，幾乎每個組織都在聲稱它多么地渴望變得敏捷靈活。但當真的面對敏捷型組織時，你真的準備好了么？

總結

以上是生活随笔為你收集整理的敏捷开发的根本矛盾是什么？从业十余年的工程师在思考的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。