CODING 敏捷實戰系列課第五講：敏捷中國史

敏捷軟件開發方法自 2001 年傳入中國以來，歷經十多年的發展變遷，目前已經成爲國內 IT 企業主流的研發管理方法。敏捷方法的傳播和發展歷程，是中國 IT 行業發展的剪影。CODING 特邀敏捷顧問、MBA，CSD 認證講師、XP工程派敏捷領熊節老師將在《敏捷中國史》課程中經過大量史實材料，用技術史的研究方法縱覽敏捷在中國的傳播、發展、演化，從一個側面呈現 IT 行業、業內領先企業和從業者的成長曆程，爲後來者留下理解這段歷史的脈絡。

你們好，今天我來爲各位同窗梳理一下敏捷進入中國的過程和發展。首先來看一下招商銀行的一項數據。過去講科技創新是一個很神祕的事情，不知道應該怎樣去創新從而獲得一個好項目，這個數據講的就是能夠經過大量的失敗、大量的試錯，從中發現有效的項目。我以爲招商銀行是這麼多年來在這個行業裏對敏捷理解最深入的一家企業，它真正作到了用敏捷的方式去改變整個經營和創新的思路。在 2018 年至 19 年這個節點上，一家中國的大型銀行能用這樣一個大相徑庭的思路去看問題，這是一個很是了不得的里程碑，標誌着敏捷在中國取得了很大的成績。那麼站在這個節點咱們回顧一下敏捷究竟是怎樣進入中國的。

最初敏捷在 2000 年左右進入中國時，就像播種同樣，一些技術雜誌把敏捷最初的思想播種到了行業裏。中國的正式出版物首次刊載與敏捷軟件開發相關的內容，是《程序員》雜誌 2001 年 12 月刊，當時我在程序員雜誌擔任技術編輯，恰好作了「代碼重構」的技術專題，能夠說是無意插柳，當時從我我的的角度來講只是以爲敏捷這個內容很是有意義，並無意識到以後會成爲這麼宏大的一個潮流。以後在 2002 年，我又作了「極限編程」技術專題，不知不覺跟敏捷結下了十幾年的緣分。

中國的軟件行業其實不是天然生長出來的，並非說經濟發展到必定程度就必定會有高科技行業天然發展，實際上中國的軟件 IT 行業是由政治、政策催生的。2000 年之後，全國軟件產業市場規模超過 1.3 萬億人民幣，連續十年的年均複合增加率都達到了 40% 以上，這是一個很是可觀的數據，而源頭就是 2000 年 6 月國務院頒發的《鼓勵軟件產業和集成電路產業發展的若干政策》（國發 18 號文），這項政策裏有很是多具體的鼓勵、補貼內容，整個扶持了中國軟件行業大發展。可是在這麼大的扶持之下，整個行業並無作好準備，沒有足夠的能力去消化如此大的需求，從而催生出了一系列問題，下圖就是 2000 年時一位廣東的官員調研獲得的狀況。當時廣東省的政府信息化項目中已經出現了這些軟件開發過程當中常見的問題，這反映出當時整個行業的能力，包括我的和企業的能力都是不足的。當時專家認爲出現這些問題是由於社會化大生產還沒有造成，固然這種觀念自己存在必定的問題，由於這是從工業製造業的角度引伸出來的。

說到行業總體能力不足，也就是說「應該具有哪些能力」，2000 年左右 CMM（能力成熟度模型）引進中國時對這個問題給出了一個比較好的答案，CMM 二級-可重複級就很好的定義了一個軟件開發團隊應該具有的基本能力：需求管理、項目管理、配置管理、質量保障。需求管理就是須要弄明白要作什麼；項目管理控制的是以適當的進度完成項目；配置管理解決的是軟件如何一步步達到最終狀態的問題；質量保障解決的是軟件可否符合要求的問題。這幾項就是軟件開發中最核心、最基本的能力。

CMM 雖然提出了整個行業「應該具有哪些能力」，卻一直沒有解決如何具有這些能力的問題。當時國內一線的工做者迫切想解決如何用有效的方式來工做的問題，因此開始在網絡上搜索國外同行們的經驗。林星是國內比較早關注敏捷的同行，他 2001 年的文章《需求分析-軟件和需求的實踐》就是關於咱們如今說的「用戶故事」，也是從極限編程中抽取出來的。石一楹也是國內最先引進重構相關內容的同行，當時他在 IBM 網站上寫了一系列質量很是高的文章，我本人對重構的瞭解就是從他這裏得來的，由於受到他的影響，我在《程序員》雜誌上作了相關介紹並在以後翻譯了馬丁·福勒的《重構》。《解析極限編程——擁抱變化》這本書是在 02 年引進的，北京當時有一個軟件工程組織叫 PKSpin，唐東銘是這個小組的成員，他給人民郵電出版社推薦了這本書並進行了翻譯。以後 03 年引進了《敏捷軟件開發》這本書，並由中興的工程師鄧輝進行了翻譯，同年 8 月我翻譯的《重構》也引進了國內，那時咱們認爲關於敏捷的理論體系已經基本搭建完成，接下來就是國內行業去接受、學習的過程，由於以前作敏捷都處於一個很是混沌的狀態，採用了敏捷實踐以後軟件開發過程當中應該怎麼作、怎樣作出一個好的軟件就很是清晰了，因此你們都以爲前景十分樂觀，應該在三五年左右能全面實現敏捷，能力會有一個明顯的提高，整個行業會有很好的成長。固然過後證實當時咱們過於樂觀，敏捷並無那麼快被普遍接納。

如今回頭看看敏捷是如未嘗試解決 CMM 提出的軟件開發四項能力的。敏捷歸根結底是一個關於怎樣管理需求的問題，是如何以一種迭代的、漸進的方式去交付軟件的問題，它與瀑布式軟件開發最根本的區別在於，當你認爲須要採用敏捷開發時，所交付的軟件不是六個月才交付一次，而是以更小的粒度去交付。敏捷的一系列內容都是從需求管理開始，它改變了咱們看待需求的方式，需求再也不是一個大頭，而是由不少小塊組成。接下來就是項目管理，當咱們但願需求以一種小顆粒的形式去逐漸交付時，接下來受影響的就是如何管理項目的問題，項目的整個生命週期都會改變，它再也不像之前同樣兩個月分析、兩個月設計、兩個月編碼，而是會徹底變成快速的短迭代，不斷生產出可用的軟件，因此咱們看待整個項目生命週期的方式會發生變化，會以迭代的週期來管理項目。接下來受衝擊的就是配置管理的方式，配置管理講的是軟件如何被修改的問題：誰在何時以什麼方式修改軟件、如何提交修改、如何把修改分享給整個團隊、如何把源代碼變成可用的軟件等等。由於咱們的目的是要快速、頻繁的交付可用的軟件，那麼配置管理必定會發生根本性的變化，會變成一種持續集成的方式，即天天、每一個小時都在不斷地集成可用的軟件。因而緊接着會影響質量保證的方式，由於團隊在不斷的生產軟件而且但願軟件是隨時可用的，因此不可能像之前同樣整個項目作幾回集中的人肉測試，必須加入大量自動化測試，確保天天、每一個小時測試都在運行，確保軟件始終處於一個良好健康的狀態。因此沒有大量的、可靠的、快速的測試用例，就必定是僞敏捷，這是一個很是容易判斷的標準。

其實中國軟件業當時並無作好準備去迎接敏捷。一方面，在「18 號文」的政策引導下，政企信息化佔據了很大市場比重，而這類項目預算週期長、用戶話語權低，快速迭代式交付既不可能、也沒必要要。另外一方面，被政府補貼快速加溫的 CMM 認證市場亂象叢生，諮詢、評估、政策補貼造成完整利益輸送鏈，對於業界軟件工程能力的提高效果並不明顯。2006 年馬丁·福勒在中國軟博會作了一個演講，說到給某投資銀行作的項目，經過迭代式開發，兩個月時已經有部分功能可讓用戶使用，並且爲客戶帶來了真正的經濟效益，整個項目全部的投資在這一部分功能上線後的幾個星期就收回來了。這個觀念在當時的中國軟件行業裏是很是陌生的，一些學院派的軟件工程專家認爲中國軟件業的現狀大概落後於美國 20 年，這個觀點我認同，可是他們認爲補齊差距的辦法是軟件學院的教育應該更正規化，學習正統的軟件工程，所謂學習「正楷」，也就是研究 CMM。這個觀念過後證實是一個徹底錯誤的選擇。同時一些民間的草根社區也在積極活動推行敏捷，雖然不受主流待見。06 年左右草根社區開始逐漸聚集力量，連續開展了兩年「敏捷中國」開發者大會並創建了線上社區。

直到 0七、08 年環境逐漸有了一些轉變。第一個方面，我我的認爲中國的互聯網行業大發展，與美國一些網絡企業被排除出中國是有很大關係的，這裏不談爭議，就當時的狀況來講，國內的互聯網企業好比 BAT，都還處於比較早期的階段，若是這些巨頭沒有被排除出去，國內極可能不會有那麼大的市場空間，因此至少從國內互聯網行業的發展來講是創造了一個機遇。另外一方面跟移動互聯網的高速發展也密切相關，華爲做爲一家設備製造商在當時也開始感覺到來自同行，好比諾基亞的壓力，發覺以流程爲中心很難應對不以公司爲導向的市場環境，因而在 04 年開始研究敏捷，並在 2007 年下半年全面展開研究，08 年初開始全面進入試點階段。而諾基亞當時在杭州的研發中心開展了一個試點項目，就是引入了 Scrum，嘗試敏捷的作法，這個試點項目培養出了許多後來對中國敏捷社區產生巨大影響的人物，好比呂毅、徐毅、申健等等。因此以前提到的中國的極限編程這一分支，很大程度上是從民間生長起來的；而 Scrum 這一分支，基本上是從諾基亞這一項目傳承下來的。還有一方面就是通訊企業和互聯網企業的大發展，開始有敏捷的訴求。06 年左右騰訊的研發規模開始膨脹，開發模式急需規範和標準化，在 IPD（集成產品開發）-CMM 和敏捷間搖擺不定，後來騰訊的研發管理部開始與 ThoughtWorks 公司接觸，在參加了一次 3 天的敏捷入門培訓後，決定沿着敏捷這條路向前走。歷史充滿了偶然性，在一些重要的節點上，其實並不清楚關鍵的決策者究竟是受到了什麼影響，最後把騰訊帶到了敏捷的方向上。而阿里也緊跟其後，大概在 0八、09 年左右開始試點敏捷，而且證實了技術的根基對於敏捷的實施很是重要。我調研過釘釘這個團隊在當時是如何實施敏捷的，他們團隊當時取得了比較好的效果，一個很重要的緣由就是自行開發自動化測試，這就又回到前面講的觀點，判斷一個團隊究竟是不是有效的敏捷，就是看有沒有大量的、可靠的、快速的自動化測試。釘釘團隊成功實施敏捷很大程度上得益於極強的技術能力，我認爲這種能力在行業裏是一個重要分水嶺，有不少企業想學習敏捷，但最後都止步於沒有過硬的技術能力，想要進行自動化測試、持續集成、重構都沒有能力。一些能力不足的項目組長或者 QA（Quality Assurance）不知道如何操做，這時出現的 Scrum 聯盟提供了一個學習考證機會，經過學習 3355 等課程得到 Scrum Master 認證，這些內容給他們的焦慮找到了一個很是好的出口，但其實敏捷的真僞最終仍是要歸結到基礎的技術能力上。

時間來到 2015 年先後，敏捷在國內開始進入收穫的季節。2016 年度中國軟件開發者白皮書中統計有 64% 的團隊使用了敏捷管理工具，固然這裏不是指已經有 64% 的團隊開始實踐敏捷，只是能夠理解爲有六成的團隊認爲宣稱本身使用了敏捷管理工具是一件有面子的事情。阿里雲棲社區在 2017 年發佈的數據中，45.6% 的團隊在規模流程模式上採用了 Scrum 敏捷開發，同理也能夠理解爲有更多人認爲 Scrum 敏捷開發是好的。這種數據描述的是一種觀念，表達了當時的行業從業者怎樣看待這些理念，反應的是一種承認。

15 年以後在敏捷的基礎上又有了不少發展，固然國際和國內要分開來看。在美國、澳洲發展的脈絡是開始思考軟件架構怎樣能夠更適合小團隊（微服務設計），怎樣讓軟件的生命週期更加完善（DevOps），怎樣將敏捷的快速反饋機制向上延伸到業務（精益、持續交付）等等。而在中國則出現了一些變體，由於國內行業不具有這些能力，在最開始沒有打好基礎，0八、09 年一些企業實施的敏捷實際上是在「補課」，雖然有一些成效但遠遠沒有到位，變成了中國特點敏捷。因爲沒有到位，只好換個名目再立項，搖身一變成微服務，再過一年變成 DevOps，以後又叫精益，結果實際上每一年作的都是一樣的事情，還在作最基本的用戶故事、持續集成、自動化測試等等內容。一個行業在剛開始發展時，由於規模還不大，全面提高行業能力比較容易，這樣也利於之後的發展，可是中國軟件業在剛開始起步的時候沒有作到這一點，規模卻愈來愈大，同行全憑本能在工做，沒有套路和方法，一些大型企業和項目所有陷在泥潭裏，人人都在加班又解決不了問題，那麼既然解決不了問題，就解決提問題的人，因而 Scrum Master 應運而生。正常邏輯應該是代碼寫的很差就提高自身能力寫好代碼，Scrum Master 就是引導團隊成員，給成員賦能，雖然能力依然沒有提高，不過至少起到了心理安慰的做用，在泥潭中也要和本身友好相處嘛。

雖然前面說的有點喪，但這麼多年來敏捷對中國的軟件行業也有很大的貢獻，好比對辦公環境就有明顯的影響。03 年左右咱們的辦公環境實際上是很是糟糕的，都是廉價的隔板和座椅以及很小的空間，而如今能夠看到愈來愈多的企業採用了開放式的辦公環境，更加人性化，同事間會有更多的交流機會，這是正向的影響。

另外一方面就要說到加班的問題。我採訪過不少人，大多都認爲跟 18 年前相比如今加班更嚴重，雖然從數據上來看加班的小時數並不算多，但實際上壓力比之前更大。一個緣由是有更多的通信工具去控制你們的工做時間，好比說釘釘、騰訊會議、企業微信等；另外一個緣由我認爲跟敏捷有很大關係，就是對任務更細的拆分、更細粒度的有效把控加大了勞動強度，這實際上是一個很差的方向，違背了敏捷價值觀。

最後說點題外話，去年可口可樂有一個項目也想用敏捷這種迭代的、快速反饋的方式去研發新的飲料，因此敏捷之後必定會延展至其餘行業領域，同時它的邊界也會愈來愈寬，內涵變得愈來愈稀薄，可能最後會模糊敏捷的定義，如今已經逐漸有這種趨勢，人人都在說敏捷。我依然堅決地認爲狹義的敏捷軟件開發有明確的邊界，至少須要擁有大量的、可靠的、快速的自動化測試套件纔是真的敏捷。

點擊觀看完整錄播視頻