靈活軟體開發方法自 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 年左右草根社群開始逐漸彙集力量，連續開展了兩年“靈活中國”開發者大會并建立了線上社群。
直到 07、08 年環境逐漸有了一些轉變。第一個方面，我個人認為中國的網際網路行業大發展，與美國一些網絡企業被排除出中國是有很大關系的，這裡不談争議，就當時的情況來說，國内的網際網路企業比如 BAT，都還處于比較早期的階段，如果這些巨頭沒有被排除出去，國内很可能不會有那麼大的市場空間，是以至少從國内網際網路行業的發展來說是創造了一個機遇。另一方面跟移動網際網路的高速發展也密切相關，華為作為一家裝置制造商在當時也開始感受到來自同行，比如諾基亞的壓力，發覺以流程為中心很難應對不以公司為導向的市場環境，于是在 04 年開始研究靈活，并在 2007 年下半年全面展開研究，08 年初開始全面進入試點階段。而諾基亞當時在杭州的研發中心開展了一個試點項目，就是引入了 Scrum，嘗試靈活的做法，這個試點項目培養出了許多後來對中國靈活社群産生巨大影響的人物，比如呂毅、徐毅、申健等等。是以之前提到的中國的極限程式設計這一分支，很大程度上是從民間生長起來的；而 Scrum 這一分支，基本上是從諾基亞這一項目傳承下來的。還有一方面就是通信企業和網際網路企業的大發展，開始有靈活的訴求。06 年左右騰訊的研發規模開始膨脹，開發模式急需規範和标準化，在 IPD（內建産品開發）-CMM 和靈活間搖擺不定，後來騰訊的研發管理部開始與 ThoughtWorks 公司接觸，在參加了一次 3 天的靈活入門教育訓練後，決定沿着靈活這條路向前走。曆史充滿了偶然性，在一些重要的節點上，其實并不清楚關鍵的決策者到底是受到了什麼影響，最後把騰訊帶到了靈活的方向上。而阿裡也緊跟其後，大概在 08、09 年左右開始試點靈活，并且證明了技術的根基對于靈活的實施非常重要。我調研過釘釘這個團隊在當時是如何實施靈活的，他們團隊當時取得了比較好的效果，一個很重要的原因就是自行開發自動化測試，這就又回到前面講的觀點，判斷一個團隊到底是不是有效的靈活，就是看有沒有大量的、可靠的、快速的自動化測試。釘釘團隊成功實施靈活很大程度上得益于極強的技術能力，我認為這種能力在行業裡是一個重要分水嶺，有很多企業想學習靈活，但最後都止步于沒有過硬的技術能力，想要進行自動化測試、持續內建、重構都沒有能力。一些能力不足的項目組長或者 QA（Quality Assurance）不知道如何操作，這時出現的 Scrum 聯盟提供了一個學習考證機會，通過學習 3355 等課程獲得 Scrum Master 認證，這些内容給他們的焦慮找到了一個非常好的出口，但其實靈活的真僞最終還是要歸結到基礎的技術能力上。
時間來到 2015 年前後，靈活在國内開始進入收獲的季節。2016 年度中國軟體開發者白皮書中統計有 64% 的團隊使用了靈活管理工具，當然這裡不是指已經有 64% 的團隊開始實踐靈活，隻是可以了解為有六成的團隊認為宣稱自己使用了靈活管理工具是一件有面子的事情。阿裡雲栖社群在 2017 年釋出的資料中，45.6% 的團隊在規模流程模式上采用了 Scrum 靈活開發，同理也可以了解為有更多人認為 Scrum 靈活開發是好的。這種資料描述的是一種觀念，表達了當時的行業從業者怎樣看待這些理念，反應的是一種認可。
15 年之後在靈活的基礎上又有了很多發展，當然國際和國内要分開來看。在美國、澳洲發展的脈絡是開始思考軟體架構怎樣可以更适合小團隊（微服務設計），怎樣讓軟體的生命周期更加完善（DevOps），怎樣将靈活的快速回報機制向上延伸到業務（精益、持續傳遞）等等。而在中國則出現了一些變體，因為國内行業不具備這些能力，在最開始沒有打好基礎，08、09 年一些企業實施的靈活其實是在“補課”，雖然有一些成效但遠遠沒有到位，變成了中國特色靈活。由于沒有到位，隻好換個名目再立項，搖身一變成微服務，再過一年變成 DevOps，之後又叫精益，結果實際上每年做的都是同樣的事情，還在做最基本的使用者故事、持續內建、自動化測試等等内容。一個行業在剛開始發展時，因為規模還不大，全面提升行業能力比較容易，這樣也利于以後的發展，但是中國軟體業在剛開始起步的時候沒有做到這一點，規模卻越來越大，同行全憑本能在工作，沒有套路和方法，一些大型企業和項目全部陷在泥潭裡，人人都在加班又解決不了問題，那麼既然解決不了問題，就解決提問題的人，于是 Scrum Master 應運而生。正常邏輯應該是代碼寫的不好就提升自身能力寫好代碼，Scrum Master 就是引導團隊成員，給成員賦能，雖然能力依然沒有提升，不過至少起到了心理安慰的作用，在泥潭中也要和自己友好相處嘛。
雖然前面說的有點喪，但這麼多年來靈活對中國的軟體行業也有很大的貢獻，比如對辦公環境就有明顯的影響。03 年左右我們的辦公環境其實是非常糟糕的，都是廉價的隔闆和座椅以及很小的空間，而現在可以看到越來越多的企業采用了開放式的辦公環境，更加人性化，同僚間會有更多的交流機會，這是正向的影響。
另一方面就要說到加班的問題。我采訪過很多人，大多都認為跟 18 年前相比現在加班更嚴重，雖然從資料上來看加班的小時數并不算多，但實際上壓力比以前更大。一個原因是有更多的通訊工具去控制大家的工作時間，比如說釘釘、騰訊會議、企業微信等；另一個原因我認為跟靈活有很大關系，就是對任務更細的拆分、更細粒度的有效把控加大了勞動強度，這其實是一個不好的方向，違背了靈活價值觀。
最後說點題外話，去年可口可樂有一個項目也想用靈活這種疊代的、快速回報的方式去研發新的飲料，是以靈活以後一定會延展至其他行業領域，同時它的邊界也會越來越寬，内涵變得越來越稀薄，可能最後會模糊靈活的定義，現在已經逐漸有這種趨勢，人人都在說靈活。我依然堅定地認為狹義的靈活軟體開發有明确的邊界，至少需要擁有大量的、可靠的、快速的自動化測試套件才是真的靈活。
點選觀看完整錄播視訊