標準化的范圍

即使有經(jīng)驗，也只能聚焦于“開發(fā)”，而不是“ThoughtWorks敏捷”。針對市場探索和產(chǎn)品創(chuàng)新的方法仍然存在根本性認知上的不同，數(shù)字化時代的不確定性又讓此刻去更大范圍標準化的想法不切實際。但我認為敏捷開發(fā)（即從開發(fā)團隊啟動交付到持續(xù)迭代運行）已經(jīng)為我們應(yīng)對市場不確定性和構(gòu)建高響應(yīng)力組織提供了基石，讓我們能夠在數(shù)字化時代將整個軟件開發(fā)逐漸改進為真正的價值和成效驅(qū)動，而不僅僅是快速交付了一堆不知道有用沒用的特性。

在下面的總結(jié)過程中，有兩個“技術(shù)處理”希望大家理解。

第一，軟件開發(fā)手工業(yè)的屬性造成了不同的團隊成熟度顯然是不同的，總結(jié)的ThoughtWorks敏捷開發(fā)實踐并非所有團隊都能夠做到，但我強調(diào)的一點是所有團隊都認同這些實踐是有價值的，可能出于某種外部約束做不了，比如部門墻造成業(yè)務(wù)人員無法參與。

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

換上咨詢顧問的帽子，ThoughtWorks敏捷開發(fā)方法應(yīng)該是現(xiàn)在市面上實踐過程中最接近敏捷宣言價值主張的實戰(zhàn)。當然，距離理想的價值和成效驅(qū)動的精益模式仍然有相當?shù)木嚯x，面臨的挑戰(zhàn)和困難可能不是敏捷開發(fā)能夠解決的，但這些問題現(xiàn)在卻反過來壓迫正確的敏捷開發(fā)方法，造成不少團隊越來越多的困惑。當一個有追求的開發(fā)團隊需要持續(xù)去解釋TDD和結(jié)對編程不會降低效率時，技術(shù)卓越的追求會被逐步消磨掉。

此外，因為我們作為一個全球化公司，以及員工工作環(huán)境的多樣性，我們在行文中有中英文夾敘的描述，比如在第5章講到GitFlow的時候，我們常用“merge……”這樣的描述，相信讀者也和我們一樣，在實際工作場景中也會經(jīng)常采用類似更有表達能力的措辭。如果有不適，請告訴我們，我們一起創(chuàng)造一個更接地氣的閱讀體驗。

ThoughtWorks敏捷開發(fā)核心原則

鋪墊很長，希望盡可能在討論范圍上保持客觀，現(xiàn)在讓我們一起來看看ThoughtWorks敏捷開發(fā)模式。

為了幫助大家理解，我嘗試從軟件開發(fā)實踐和管理體系兩個維度去解釋。先列舉一下核心實踐，然后從軟件開發(fā)的幾條管理主線幫助大家串聯(lián)一下這臺看似松散，實則精密的機器。這里要再次提醒大家我們討論的范圍僅僅是開發(fā)段，所列實踐也不會特別關(guān)注團隊文化建設(shè)。

在展開具體實踐前，首先要明確ThoughtWorks敏捷開發(fā)的核心原則：價值驅(qū)動與技術(shù)卓越。

這兩個四字短語在ThoughtWorks這個開發(fā)系統(tǒng)里有著不可撼動的地位。畢業(yè)剛加入的熱血青年質(zhì)問項目經(jīng)理一個Story（故事）的價值何在？Angular和React誰更全面？這樣的討論在內(nèi)部是受到鼓勵的。

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

這對管理人員來說近乎是殘忍的，這也是為什么ThoughtWorks在2010年左右經(jīng)歷了一批外聘PM的離職。雖然現(xiàn)在我們創(chuàng)造出了很大PM管理空間，但值得警惕的是如果沒有那些“惱人”的價值問題和技術(shù)上的一點偏執(zhí)，ThoughtWorks敏捷開發(fā)模式很可能就不存在了。

ThoughtWorks敏捷開發(fā)核心實踐

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

既然是核心實踐，就從一個最小集開始，如果減掉我就認為不再是ThoughtWorks的敏捷開發(fā)模式。當然，由于ThoughtWorks開發(fā)團隊更多做的是互聯(lián)網(wǎng)軟件的開發(fā)，這個實踐集并不一定適用于類似嵌入式設(shè)備和合規(guī)系統(tǒng)的軟件開發(fā)。以下是我認為的集合，歡迎大家一起研討！

1. 基于統(tǒng)一迭代節(jié)奏的全功能團隊

剛加入ThoughtWorks的時候認識到開發(fā)團隊除了開發(fā)和測試（當然這里我們認為是QA）外，還有BA（業(yè)務(wù)分析師）。10年前這個角色在和任何客戶合作的時候還需要解釋，現(xiàn)在大家都已經(jīng)在開始談?wù)揢X和DevOps了。全功能團隊這個實踐本身并非是說要固定哪些角色在開發(fā)團隊，而是強調(diào)為了交付軟件所需要的技能都應(yīng)該在一個團隊里。在不遠的將來，我們可能會討論數(shù)據(jù)科學(xué)家的融入問題。

這個實踐還要強調(diào)“統(tǒng)一迭代節(jié)奏”，要求團隊各個角色同步協(xié)作，而不是每個角色自己迭代。我看見過很多偽的全功能團隊，一個迭代開發(fā)完的Story（故事）由QA下一個迭代測試。

2. 基于Story的需求及范圍實時管理

Story是開發(fā)團隊的最小工作單元，由于價值驅(qū)動的原則，Story的INVEST原則是各個角色廣泛認可的。如果哪個角色（包含業(yè)務(wù)）看不懂一個Story，那么大家會認為Story本身有問題。

ThoughtWorks敏捷開發(fā)不對Story進行更技術(shù)的Task（任務(wù)）拆分，這樣做保證了大家都關(guān)注Story承載的業(yè)務(wù)價值，當然這需要技術(shù)能力上的“全?！蔽幕С郑创蠹乙阅軌蛲瑫r做多個技術(shù)棧為榮。

運行成熟的ThoughtWorks開發(fā)團隊有任務(wù)拆分這個環(huán)節(jié)，形式可能是全隊在迭代啟動會上針對復(fù)雜的Story進行“實現(xiàn)預(yù)演”，也可能是資深開發(fā)人員在自己顯示器上貼出的彩色紙條，每張紙條承載著一個技術(shù)動作。小蟲和晶晶是我見過把這種Tasking深入工作骨髓的人，他們基于這種任務(wù)拆分模式的神一般的結(jié)對讓人終生難忘，我感到很幸運！

雖然有整體項目的Backlog，但Story一般是迭代澄清，為了保證統(tǒng)一迭代，BA一般只會提前一個迭代梳理下一個迭代（類似Scrum中的Sprint）的需求。非常成熟的ThoughtWorks開發(fā)團隊在這個過程中能夠讓客戶或業(yè)務(wù)負責人持續(xù)迭代參與Story澄清，并能夠持續(xù)調(diào)整Story優(yōu)先級。

國內(nèi)由于固定合同項目較多，很多需求澄清發(fā)生更早，但實際上很多人不理解保持一定并發(fā)性，正是駕馭軟件不確定性的關(guān)鍵?！皩崟r性”是精益JIT（Just In Time）思想能夠起作用的核心機制。

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

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

3. 基于持續(xù)集成和測試前置的質(zhì)量內(nèi)建

持續(xù)集成是敏捷實踐中最廣泛共識的技術(shù)實踐（沒有之一）。ThoughtWorks對持續(xù)集成的重視可以從歷史經(jīng)典的開源CruiseControl窺見一斑。由于大顯示器的普及和CI展示看板的美化，現(xiàn)在各個團隊基本都采用一個顯示器展示CI的實時構(gòu)建情況，但歷史上還有很多類似警報燈這樣的創(chuàng)意。

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

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

持續(xù)集成已經(jīng)是軟件開發(fā)過程中質(zhì)量內(nèi)建的經(jīng)典實踐，在這個基礎(chǔ)上ThoughtWorks開發(fā)團隊有共識的是測試前置，落地過程中有兩個經(jīng)典方法，即開發(fā)的TDD和提前驗收（提前驗收或叫Shoulder Check）。

TDD不用在這里多講了，每年總會有一兩次爭論，第二個D指的是Driven，即驅(qū)動，永遠是大家爭論的焦點，但先寫單元測試是ThoughtWorks程序員基本素養(yǎng)。代碼走查形式多樣，但成熟團隊一般都從單元測試開始，如果你跟骨灰級程序員新老頭走查，他的第一句會是“給我看看你的測試。”

提前驗收操作起來是比較容易的，即開發(fā)人員完成Story后，在最后提交前邀請BA和QA快速在開發(fā)機上做展示。這樣做的好處是盡量避免Story被移動到后期測試或客戶驗收的時候，才發(fā)現(xiàn)需求實現(xiàn)有問題，從而導(dǎo)致返工和浪費。由于這個預(yù)驗收時間很快，所以有些團隊說是“站在肩膀后面”檢查。當然這個不是機械的規(guī)定，簡單Story也不一定要做提前驗收。

ThoughtWorks敏捷開發(fā)對回歸測試考慮不多，質(zhì)量內(nèi)建意味著不希望最后靠測試把質(zhì)量關(guān)，相比之下，大家對代碼走查和結(jié)對編程這些開發(fā)過程中的質(zhì)量實踐更看重，但這些實踐的頻繁運用在很多團隊都受到了成本的約束，并非普遍。關(guān)于分層的自動化測試也是一個質(zhì)量保障的核心話題，但隨著技術(shù)的進步，認知在逐步清晰，我個人認為還不能說是非常成熟的基礎(chǔ)方法。

4. 基于效能和周期時間的持續(xù)改進

持續(xù)改進是每個團隊必須做的，Retro（回顧會議，全稱Retrospective）是基本形式，回顧的內(nèi)容很多，從交付質(zhì)量、實踐到團隊氛圍。但實質(zhì)上最基本的改進還是圍繞Velocity（即迭代交付的Story點數(shù)）和Cycle Time（交付時間）。這里的Cycle Time還稱不上“端到端”，原因是很多團隊前期的產(chǎn)品梳理和后期的用戶驗收還是遵循客戶合作節(jié)奏，比如2個月一次上線。當然原則上共識的是，每次持續(xù)集成構(gòu)建出來的版本都應(yīng)該是可發(fā)布的。

Velocity是一個很有爭議的話題，這個速率理論上只服務(wù)于項目管理，即目前規(guī)劃和實際情況是否出現(xiàn)偏差，是否需要進行風險管理，調(diào)整項目范圍等。

ThoughtWorks敏捷開發(fā)模式堅決反對把效能（Velocity）作為交付KPI，即不作為迭代內(nèi)的開發(fā)合同。假設(shè)合作上不存在信任問題，還是有一個無法回避的預(yù)測問題，如果效能（Velocity）和計劃的偏差很大，那么實際的調(diào)整成本較高。當然這是一個行業(yè)問題，在“大規(guī)模手工打造”這個行業(yè)現(xiàn)狀沒有改觀之前，最好還是能夠坦誠開發(fā)過程中遇到的問題和變數(shù)。

Cycle Time（周期時間）是從需求進入開發(fā)團隊，到制造出可工作軟件的速度。理論上當然是越快越好，Kanban告訴我們流速快的團隊效率高、響應(yīng)力快。如果不注意Cycle Time而去“改進”（Velocity），很可能造成更多的WIP（Kanban引入的“在制品”概念）堆積在迭代內(nèi)，最后大家趕工埋下質(zhì)量隱患，得不償失。我們可以看到，在ThoughtWorks兩個百人以上規(guī)模的大型團隊合用中，都強調(diào)團隊集體學(xué)習(xí)Kanban實踐。

5. 基于客戶深度參與的統(tǒng)一團隊

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

客戶參加迭代內(nèi)站會、展示會和回顧會是ThoughtWorks敏捷開發(fā)提出的要求。即使在通訊手段相對落后的七八年前，離岸的客戶也是幾乎每天和開發(fā)團隊通過電話進行“站會”。這樣做的好處不言而喻，大家都能夠體會到這種模式下快速建立的信任關(guān)系。當然客戶和開發(fā)團隊都有很多其他工作要做，所以這樣的協(xié)作模式就要求控制每種會議的時間。一些比較普遍的原則如下：

• 迭代站會不超過15分鐘
• 需求澄清每次不超過一個小時
• 展示會一個小時以內(nèi)
• 回顧會不超過兩小時

雖然如此，這樣的模式對客戶時間要求依然很高。在咨詢其他IT組織的過程中，相關(guān)業(yè)務(wù)人員（即開發(fā)團隊客戶）往往會有畏難情緒。但其實只要時間盒控制好，建立這樣的協(xié)作節(jié)奏后，總投入時間是下降的?？此萍蟹绞降暮献髂Ｊ?，比如每個月1天時間需求梳理，其實根本沒有辦法杜絕后續(xù)實現(xiàn)過程中發(fā)現(xiàn)的細節(jié)問題。而到了迭代驗收時才說出的“這不是我想要的”，更是巨大浪費的源頭。

對比Scrum的經(jīng)典四會，ThoughtWorks敏捷開發(fā)和最后的Review（評審會，Sprint Review Meeting）的差異相對較大。開發(fā)團隊更希望是針對實現(xiàn)的業(yè)務(wù)場景進行展示，所以會議的名字也變成了Showcase（展示會）。當然，不少團隊也會評審迭代的產(chǎn)出，有相關(guān)的迭代進展報告。

不少和國內(nèi)客戶合作的開發(fā)團隊有相對更重一些的迭代總結(jié)材料，會占用PM不少的時間。這點需要警惕，面向價值的原則意味著整個團隊，包含客戶，都應(yīng)該更多去思考迭代實現(xiàn)的業(yè)務(wù)，而不是關(guān)注迭代大家的工作量。后者應(yīng)該是開發(fā)團隊自己去持續(xù)考量和改進。