ThoughtWorks的敏捷開發 洞見

ThoughtWorks的敏捷開發方法一直是一種神秘存在。在敏捷開發還沒有主流化的年代，為了讓外界理解ThoughtWorks全球團隊怎麼做敏捷，我們商定了一個「60% Scrum + 40% XP」的經典答案。當然其實ThoughtWorks的敏捷開發既不是Scrum，也不是XP。

造成這個狀態的原因，一方面是行業特點 —— 軟體開發還是一個充滿不確定性的手工業，方法套路當然不可避免因人而異；另一方面作為一個提倡端到端軟體交付的組織，敏捷開發本身並不能解決我們所有的問題。基於這兩點，大家都不是特別願意去總結ThoughtWorks的敏捷方法，換言之「標準化」就不在我們的基因里。

標準化的初衷

ThoughtWorks快20年的敏捷開發實戰經驗不總結給更廣大的社區，於我自己感覺是一種不負責任。對內ThoughtWorks中國已經從我加入時，北京東西宮每天流竄兩趟招呼到所有人，變成了全國六地1,200多人的數字化服務公司。每年還是很多人為著敏捷慕名而來加入ThoughtWorks，而我能給新員工分享一點敏捷開發實踐的機會可能一年一次都難了。

留在ThoughtWorks的一個重要原因就是差異永遠大於共識，這樣的環境里想總結點啥，沒實戰經驗保底肯定是會被鄙視的。作為一個開發加入，在近十年的ThoughtWorks生涯里，我做過敏捷開發里除了測試以外的所有角色，如果把諮詢的部分經驗算成敏捷教練，和最近在努力的UX方向，應該是給了我足夠全面的視角來審視ThoughtWorks的敏捷開發。在中國區持續最長時間的離岸敏捷交付團隊近4年的經歷，和敏捷諮詢8年的經歷也應該讓我有一定經驗支撐來談這個話題。

標準化的範圍

即使有上面的經驗，也只能聚焦在「開發」，而不是「ThoughtWorks敏捷」。針對市場探索和產品創新的方法仍然存在根本性認知上的不同，數字化時代的不確定性又讓此刻去更大範圍標準化的想法不切實際。但我認為敏捷開發 —— 即從開發團隊啟動交付到持續迭代運行 —— 已經為我們應對市場不確定性，構建高響應力組織，提供了基石，讓我們能夠在數字化時代將整個軟體開發逐漸改進為真正的價值和成效驅動，而不僅僅是快速交付了一堆不知道有用沒用的特性。

在下面的總結過程中有兩個「技術處理」希望大家理解。

第一，軟體開發手工業的屬性造成了不同的團隊成熟度顯然是不同的，總結的ThoughtWorks敏捷開發實踐並非所有團隊都能夠做到，但我強調的一點是所有團隊都共識這些實踐是有價值的，可能出於某種外部約束做不了，比如部門牆造成業務人員無法參與。

第二，盡量不引入ThoughtWorks自己的「黑話」，跟Scrum、Kanban和XP這些經典框架相似的實踐，保持命名一致，畢竟標準化的作用之一是對外推廣。

ThoughtWorks敏捷開發核心原則

鋪墊很長，希望儘可能在討論範圍上保持客觀，現在讓我們一起來看看ThoughtWorks敏捷開發模式。

為了幫助大家理解，我嘗試從軟體開發實踐和管理體系兩個維度去解釋。先列舉一下核心實踐，然後從軟體開發的幾條管理主線幫助大家串聯一下這台看似鬆散，實則精密的機器。這裡要再次提醒大家我們討論的範圍僅僅是開發段，所列實踐也不會特別關注團隊文化建設。

在展開具體實踐前，首先要明確ThoughtWorks敏捷開發的核心原則：價值驅動、技術卓越。

這兩個核心原則甚至上升到了價值觀的層面，於是我們認為好的客戶一定能夠「耐心」跟團隊辯論價值，而讓團隊「聽我的」業務人員基本只能維持在一個商務上的甲方。如果開發團隊某晚上努力把Angular換成React，管理者（甚至客戶）也被要求在強調風險管理的基礎上，肯定團隊為技術卓越追求付出的努力。

這對管理人員來說近乎是殘忍的，這也是為什麼ThoughtWorks在2010年左右經歷了一批外聘PM的離職。雖然現在我們創造出了很大PM的管理空間，但值得警惕的是如果沒有那些「惱人」的價值問題，和技術上的一點偏執，ThoughtWorks敏捷開發模式很可能就不存在了。

ThoughtWorks敏捷開發核心實踐

在核心原則下，ThoughtWorks不同團隊實踐非常多，想要找到萬變不離其中的骨幹其實挺困難的。記得當年一家保險公司CIO帶隊來參觀，看完早站會後直言不諱沒有看懂一個50人的團隊在幹啥，只看到不同人群在自由組合。於是我花了一個早晨只為解釋一小時過程背後的「隱次序」。

（一個現場團隊的早站會）

（這是一個離岸團隊的現場）

既然是核心實踐，就從一個最小集開始，如果減掉我就認為不再是ThoughtWorks的敏捷開發模式。當然由於ThoughtWorks開發團隊更多做的是互聯網軟體的開發，這個實踐集並不一定適用於類似嵌入式設備和合規系統的軟體開發。以下是我認為的集合，歡迎大家一起來研討！

1. 基於統一迭代節奏的全功能團隊

這個實踐還要強調「統一迭代節奏」，要求團隊各個角色同步協作，而不是每個角色自己迭代。我看見過太多的偽全功能團隊，一個迭代開發完的Story由QA下一個迭代測試。

（全功能團隊跨職能協作示意，一個典型團隊包含了BA、Dev、QA和UX）

2. 基於Story的需求及範圍實時管理

Story是開發團隊的最小工作單元，由於價值驅動的原則，Story INVEST原則是各個角色廣泛認可的。如果哪個角色（包含業務）看不懂一個Story，那麼大家會認為Story本身有問題。

ThoughtWorks敏捷開發不對Story進行更技術的Task拆分，這樣做保證了大家都關注Story承載的業務價值，當然這需要技術能力上的「全棧」文化支持，即大家以能夠同時做多個技術棧為榮。

（開發人員貼在顯示器前彩色的Tasking小紙條）

雖然有整體項目的Backlog，但Story一般是迭代澄清，為了保證統一迭代，BA一般只會提前一個迭代梳理下一個迭代（類似Scrum中的Sprint）的需求。非常成熟的ThoughtWorks開發團隊在這個過程中能夠讓客戶或業務負責人持續迭代參與Story澄清，並能夠持續調整Story優先順序。

國內由於固定合同項目較多，很多需求澄清發生更早，但實際上很多人不理解保持一定並發性，正是駕馭軟體不確定性的關鍵。「實時性」 是精益Just In Time能夠起作用的核心機制。

範圍管理上由於這樣的Story迭代機制，基本也需要實時，常用的工具是燃起圖（Burn-Up）和累積流量圖（CFD來至於Kanban）。Scrum的燃盡圖並不推薦，原因是很容易營造一種遵循計劃的假象。對於客戶/業務和項目管理者，從燃起圖能夠看到實時需求範圍的變化，按期交付風險也能夠實時推測。累計流量圖在成熟團隊廣泛應用，它能夠直觀告訴開發團隊瓶頸在哪裡，驅動改進。能夠收集累計流量圖所需的數據，本身也說明團隊具備了一定的成熟度。

（燃起Burn-Up圖示意，上圖為一個最簡單的統計展現，僅包含已完成和總共的Story個數。下圖是一個相對長期和複雜產品，針對Story進行了類型劃分的管理。注意這裡的「完成」，包含了Story的分析、開發和測試，甚至一些團隊StoryDoD中要求上線。製造過程中的Story都是沒有完成。）

行業里目前很關心這方面的電子化平台，ThoughtWorks由於歷史原因，用各種平台都有，目前最多的是Jira、Mingle和Rally。但實際上這些平台主要目的還是為了離岸敏捷交付團隊，本地的交付團隊很多是物理牆+Excel（或Trello）。Story本身不作為審計和追責記錄，真正的交付是線上工作的軟體。

3. 基於持續集成和測試前置的質量內建

持續集成是敏捷實踐中最廣泛共識的技術實踐（沒有之一）。ThoughtWorks對持續集成的重視可以從歷史經典的開源CrusieControl窺見一斑。由於大顯示器的普及和CI展示看板的美化，現在各個團隊基本都採用一個顯示器展示CI的實時構建情況，但歷史上還是有很多類似警報燈這樣的創意出現的。

（一個典型的團隊CI看板展示）

（看板一般所在的團隊位置）

ThoughtWorks持續集成紀律有兩條核心，第一是必須每次提交觸發構建；第二是每次提交必須基於上次的成功構建。這兩條紀律是底線。如果有人說哪個團隊CI紅著沒有修復，基本就等於說這個團隊沒有幹活兒，因為理論上對著失敗的構建提交代碼是無效的。

持續集成對代碼管理的要求是主幹開發，這是ThoughtWorks開發團隊的默認模式。去年和劉冉、覃宇通過《代碼管理核心技術及實踐》一書闡述了行業內流行的分支開發模式實踐和工具，但在ThoughtWorks內部，即使對使用比較廣泛的GitFlow模式，也是持負面意見居多。顯然主幹開發的代碼管理成本是最低的，但同時也引入了較高的代碼實踐能力和協同紀律的要求。

持續集成已經是軟體開發過程中質量內建的經典實踐，在這個基礎上ThoughtWorks開發團隊有共識的是測試前置，落地過程中有兩個經典方法，即開發的TDD和提前驗收（Desk Check或叫Shoulder Check）。

提前驗收操作起來是比較容易的，即開發人員完成Story後，在最後提交前邀請BA和QA快速在開發機上做展示。這樣做的好處是盡量避免Story被移動到後期測試或客戶驗收的時候，才發現需求實現有問題，返工浪費。由於這個預驗收時間很快，所以有些團隊說是「站肩膀後面」檢查。當然這個不是機械的規定，簡單Story也不一定要做提前驗收。

（提前驗收現場，Story開發人員快速講解實現，現場客戶也有可能參加到Story驗收交流中。）

（一團隊的代碼集體走查現場）

（開發人員的pair開發，往往會達到1+1 > 2的效率增長）

4. 基於Velocity和Cycle Time的持續改進

Velocity是一個很有爭議的話題，這個速率理論上只服務於項目管理，即目前規劃和實際情況是否出現偏差，是否需要進行風險管理，調整項目範圍等。

ThoughtWorks敏捷開發模式堅決反對把Velocity作為交付KPI，即不作為迭代內的開發合同。假設合作上不存在信任問題，還是有一個無法迴避的預測問題，如果Velocity和計劃的偏差很大，那麼實際的調整成本較高。當然這是一個行業問題，在「大規模手工打造」這個行業現狀沒有改觀之前，最好還是能夠坦誠開發過程中遇到的問題和變數。

Cycle Time是從需求進入開發團隊，到製造出可工作軟體的速度。理論上當然是越快越好，Kanban告訴我們流速快的團隊效率高、響應力快。如果不注意Cycle Time去「改進」Velocity，很可能造成更多的WIP（Kanban引入的在制品概念）堆積在迭代內，最後大家趕工埋下質量隱患，得不償失。所以我們可以看到在ThoughtWorks合作的兩個百人以上規模的大型團隊里，都強調團隊集體學習Kanban實踐。

（一個團隊三個半月的累計流量圖，能夠有效看到在某一個階段的WIP和Cycle Time數值，並分析潛在問題）

5. 基於客戶深度參與的統一團隊

從ThoughtWorks歷史的交付項目上來看，能夠建立互信持久合作關係（>3年）的客戶基本都深度參與了迭代開發過程。中國區歷史最長，合作規模最大的三個交付項目都是客戶團隊和開發團隊完全整合的。

迭代站會不超過15分鐘

需求澄清每次不超過1小時

展示會1小時以內

回顧會不超過兩小時

雖然如此，這樣的模式對客戶時間要求依然很高。在諮詢其它IT組織的過程中，相關業務人員（即開發團隊客戶）往往會有畏難情緒。但其實只要時間盒控制好，建立這樣的協作節奏後，總投入時間是下降的。看似集中方式的合作模式，比如每個月1天時間需求梳理，其實根本沒有辦法杜絕後續實現過程中發現的細節問題。而到了迭代驗收時才說出的「這不是我想要的」，更是巨大浪費的源頭。

對比Scrum的經典四會，ThoughtWorks敏捷開發和最後的評審會（Sprint Review Meeting）的差異相對較大。開發團隊更希望是針對實現的業務場景進行展示，所以會議的名字也變成了展示會（Showcase）。當然不少團隊也會評審迭代的產出，有相關的迭代進展報告。

（一大型離岸合作客戶將Showcase擴展到整個公司月度的跨產品展示）

不少和國內客戶合作的開發團隊有相對更重一些的迭代總結材料，會佔用PM不少的時間。這點上需要警惕，面向價值的原則意味著整個團隊，包含客戶，都應該更多去思考迭代實現的業務，而不是關注迭代大家的工作量。後者應該是開發團隊自己去持續考量和改進。

ThoughtWorks敏捷開發管理體系

做了多年的組織轉型諮詢，如果約束到軟體開發領域，管理體系（暫且認為文化部分屬於領導力）基本就是以下四個方面：

需求管理：包含從需求澄清到需求最終實現的整個生命周期。

技術管理：包含開發、測試技術的選擇和運用。

質量管理：包含開發過程中的質量管理及軟體交付前的質量保障。

迭代管理：包含開發團隊迭代運作規則及紀律。

顯然ThoughtWorks敏捷開發需求管理是圍繞Story展開，其核心是能夠支持小批量、小批次的精益模式，同時還要能夠盡量保證每個Story業務價值明確。《用戶故事與敏捷方法》這本書可能是ThoughtWorks內部沒有任何負面評價的實踐級著作了。近十年時間裡，大家稍有微辭的地方可能是書中對故事大小評估的描述，但INVEST原則的抽象可為神來之筆。

Story作為需求的管理方法，所有的技術、質量和迭代管理其實都是圍繞這個中心，畢竟最後開發目的是實現價值，而Story承載著業務價值。順便提一句，Story的質量其實是一個核心問題，ThoughtWorks從來不提倡一句話Story描述，即僅僅表面上遵循了As … I want … So that的經典模式，驗收條件對於一個Story來說至關重要。

值得一提的是圍繞Story的可視化系統，每個團隊都會有一面類似下圖的迭代看板，看板上流動的是迭代內的Story，而Story的生命周期則通過順序的泳道展現給團隊所有人。

（基礎的Story迭代看板設計，黃色卡片上會寫出Story的基本信息）

（一個團隊的Story看板，每個團隊都會有自己的內部流程設計，所以各個團隊的看板泳道設計也不盡相同）

技術和質量管理的核心仍然是前文提到的質量內建。持續集成和自動化測試實際上都將質量管理融入到了技術工程體系里。在ThoughtWorks敏捷開發體系里，很難將技術管理和質量管理分開，重過程質量是這個管理體系的精髓，由此也在2012年演進為《持續交付》的概念。

由於是全功能團隊，並工作在統一節奏下，所以迭代管理的範圍中，除了類似Scrum四會協作儀式機制，其餘硬性紀律較少。為了保證（成果和問題）「集體所有」（Collective Ownership），ThoughtWorks敏捷開發實踐方面特別注意不會聚焦到個體，比如我們說到的Story估點和Velocity統計都是團隊為單位，不會指定或統計到個人。

迭代過程中的缺陷也不會追述到某個特定開發人員。唯一產生個體比較和競爭的可能是在技術卓越原則下的比拼，比如作為TL，至少你寫出的代碼應該是讓團隊其他成員賞心悅目。

雖然本文不談文化，但這裡還是必須強調這樣的管理模式本質上是將「價值驅動、技術卓越」上升到文化價值觀層面作為支撐才得以實現的。即便經常拿尚奇口中的「tech@core」開玩笑，但實質上這是ThoughtWorks敏捷開發模式能夠工作的重要底座。也是為什麼很多其他團隊感覺ThoughtWorks這種管理模式不可行的核心癥結。

最後問一句，和你感受和認知的ThoughtWorks敏捷開發差異大嗎？

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！