敏捷開發的持續改進

「敏捷」這個詞近幾年非常火，經常會有人問：「我們應該怎樣開始做敏捷？」或者：「能不能來幫我們推一下敏捷？」這種問題我通常都不敢輕易回答——敏捷有很多實踐，管理的、工程的都有，但敏捷絕非我們看到的站會、持續集成、TDD等那麼簡單，真正的敏捷體系是從理念到文化的一次變革。

所以具體到一個團隊，究竟為什麼要做敏捷，能夠多大程度地承受改變所帶來的痛苦和風險，本質上還是需要自己先想清楚，我們要解決的問題或者期望的價值究竟是什麼，再來判斷應該做什麼以及怎麼做。

這裡分享幾個敏捷相關的過程改進案例，希望能夠給到大家一些可以借鑒的東西。

案例一：靈活地響應變化

兩年前我在酒店事業部做支持的時候，有一次同一位產品總監聊天，他向我抱怨，說：「技術團隊怎麼有那麼多的項目延期？他們能不能靠譜一點，至少給我的周計劃里，承諾要完成的事情應該做到吧！」

我反問了一個問題：「那作為一個產品總監，你能不能保持你的團隊一周內的需求不改變呢？」

他想了想說：「我做不到。」

我們相視一笑，很容易就達成了共識——我們不能指望不變或者少變，而是要提升整個團隊的應變能力，去響應甚至擁抱變化。

那麼怎樣才能提升團隊響應變化的能力呢？

首先，要建立良好的可視性——能夠清楚地知道每個人每天都在做什麼，進展如何，何時能完成——這樣在發生變化時，我們才知道應該安排誰、什麼時候去做是最合適的。

所以我們做story/task的拆分，並搭建看板，展示每個人的工作；再通過站會溝通進展以及問題，保證信息每天都能得到更新。

其次，要提升變更決策的效率——我們要讓有價值的變更能夠快速地得到實施，首先要有個快速且有效的決策機制。那麼應該由誰來做這個決策呢？決策人級別太高，決策效率會低；決策人級別太低，又擔心水平不夠，不能服眾。我的觀點是「讓具備這個能力的、級別最低的人來做」——資深人員能做就不要讓leader做，leader能做就不要讓總監做，總監能做就不要讓VP做。有做的不對或者不好的時候可以升級問題，但不要一開始就把職責都定在管理者身上。

所以我們引入了PO（ProductOwner）的概念。為每個團隊指定一個PO，他/她負責接收所有的需求、判斷價值和優先順序；如果有需要的話，還要幫助其他產品經理做系統的需求分析。大部分團隊的PO都是資深的產品經理；但也有小部分技術團隊，由於對應多個需求方，最後技術leader自己做了PO。在實踐中我們發現資深的產品經理和技術leader都能把PO這個角色做的很好，需要升級到管理決策的情況非常少。

最後，要降低變更管理的成本——變更過程中最令人感到痛苦的事情，就是re-plan。一般來說，如果只是調整當前項目的計劃，還相對比較容易。但由於項目延期或者對人員的時間佔用增加，通常會導致其它項目的等待或延期，這種情況溝通起來就比較費時費勁了。更糟糕的是，技術團隊已經對計劃做出了承諾，「客戶」就會很憤怒：「你們這幫人怎麼這麼不靠譜，承諾的事情為什麼老是變！」所以很多技術leader會傾向於拒絕變更，他們會說：「你們先去走個流程！」「你們先去找VP審批一下！」

所以我們轉變做計劃的思路，從承諾everything轉向只承諾當前優先順序最高的事情；從「事推動人」轉向「人拉動事」——也就是說我們盡量讓每個人都工作在優先順序最高的事情上；做完一件事情，再去需求隊列里取當前優先順序最高的；再完成之後，再去取下一件……如此循環。這樣我們就把對變更的決策與制定工作計劃這兩件事情「解耦」了，讓整個團隊都能夠聚焦在變更所帶來的價值，而不是痛苦和折騰的過程。

關於如何制定工作計劃（就是我們通常說的「排期」），這裡推薦一個實踐——每天上午站會結束之後，會有一個小型的計劃會議（planning meeting）。如果前一天有人交付了手頭的工作，就留下來參加計劃會議，leader會綜合待排期的需求優先順序、當前人員的能力等因素安排他們的工作。原則上已經開始開發的工作盡量不要中斷，除非有特別緊急的事情，leader會暫停部分相對低優先順序的工作，抽調人手響應緊急情況。一個10人以內的團隊，平均每天花費的時間不會超過15分鐘。

這個案例是最輕量的敏捷實踐，在不改變組織結構和工程流程的前提下，能夠以最低的成本實現靈活的應變能力。這也是目前在金融事業部和大住宿事業部絕大多數團隊所採用的實踐。

案例二：高效地溝通與協同

有一天，專車事業部的一位總監找到我，說：「我們也很想做敏捷，你們能不能來幫個忙？」於是，我安排了一位同事去支持這個團隊。

她去到這個團隊，開始嘗試用我們一貫的方法，幫助團隊搭建看板、開站會，卻發現幾乎所有的leader一致認為站會是沒有意義的——他們曾經嘗試過，最後發現每日溝通花費了時間，但卻並不會給他們的工作帶來多大的幫助，於是都放棄了。

為什麼在那麼多團隊行之有效的實踐，到了某些地方就失效了呢？

經過調研，我們找到了問題的答案——要找對需要在一起溝通的人，這比溝通的形式更重要。

專車的這個團隊是個典型的app開發團隊，分為ios、android和服務端開發三個組；維護著兩個主要的產品，分別是給用戶下單用的「用戶端」和供司機搶單用的「司機端」。

當我們按照組織結構召集一個團隊開會的時候，團隊成員之間由於工作的相關度不高，所以並不太關心其他人幹了什麼，雖然站會時間不長，可大家覺得沒有價值，是在浪費時間。

而當我們將團隊重新組合之後，按照產品線劃分成司機端、用戶端和純服務端三個團隊，每個團隊都包括PM、各種DEV以及QA。調整完之後，大家溝通的積極性馬上就高了起來，因為大家是共同在做一件事情，是上下游的關係，相互能夠給對方提供信息並解決問題。

最終我們其實只做了一件事情，就是建立了一個完整的交付團隊（也就是通常人們說的「敏捷團隊」），所有的實踐就順理成章地實施起來了。從這裡我們可以看到，敏捷的團隊，是比敏捷的流程或者實踐更重要的東西。

那麼，什麼樣的團隊，才能算是一個敏捷的團隊呢？Mike Cohn給出過9個問題，用來判斷一個團隊是否「結構優良」，有興趣的同學可以去看相關的資料。這裡給出幾點我認為最重要的特點：

第一，要有交付能力——能夠獨立交付完整的業務功能，這是一個敏捷團隊的最基本的特性。這就意味著團隊必須包含交付所需要的全部角色（一般至少要有前後端開發、測試），或者具備全部角色的能力。

第二，要「高內聚，低耦合」——團隊所承接的需求，大部分都應該能在團隊內部完成，對其他團隊的依賴應該是少量的或者簡單的；同時，應該盡量避免兩個以上的團隊共享一個成員的情況。這樣才能進一步地減少等待以及各種管理的浪費，保證快速交付的能力。

第三，要保持小團隊——團隊太大會降低溝通效率，增加管理的浪費；而小團隊則更容易保持對目標的專註並形成凝聚力。一般認為7加減2是比較合適的範圍。

第四，要足夠長期——團隊需要一定的時間去形成統一的規則和文化。一個新團隊度過磨合期通常至少需要2-3個月的時間，而要想在這個基礎上形成自組織、自管理的團隊文化，則需要更長的時間。只有成熟度非常高的組織（團隊文化和基礎設施都高度成熟），才能頻繁地變更團隊的組成而不破壞團隊文化。

這個案例是中等程度的敏捷實踐，從過程改進的角度來看，仍然是屬於漸進式優化的做法：在保持組織結構不變的基礎上，按照業務和產品的結構劃分出「虛擬的」交付團隊。在這個團隊里，各種角色能夠頻繁地、一致地、充分地交流，及時發現和解決的問題，從而快速交付產品功能，實現業務價值。對這個實踐目前執行到位的團隊並不多，主要的原因是很多FE和QA團隊作為「公共資源」沒有與DEV進行對應的分拆，無法形成完整的交付團隊。

案例三：目標一致的團隊

去年下半年，我們在一個部門做支持的同學跟我反饋，說她覺得團隊的流程在退化：原本分拆了的FE和QA團隊又合回去了，團隊從原本的每日排期變回了周排期。跨團隊的項目越來越多，溝通、協調的過程也越來越複雜。整體的可視性在下降，管理的浪費在增加，當前雖然還沒有明顯的問題，但長期發展下去團隊的整體交付能力會下降。

當時我們的CTO正好坐在我旁邊，問了一個問題：「如果一個流程是好的，它就不應該會退化。如果它退化了，是不是說明有些什麼地方是不夠好的？退化的原因究竟是什麼？」

為什麼有些團隊的流程，在過程支持的同學退出之後，就會慢慢退化呢？究竟是因為人的惰性，還是流程的設計本身就有不合理或者不到位的地方呢？

經過對已經實施的團隊流程的反覆檢視，我認為流程會退化的主要原因有兩個：

一是這種虛擬團隊的組建機制不夠強壯——這種虛擬團隊之所以能夠形成，本質上是基於所有的資源經理的承諾，這是一個不太穩固的基礎。尤其是當資源團隊的leader發生變動的時候，新的leader沒有經歷過改進的過程，不理解為什麼要這樣做，或者不知道這種情況下該怎麼做，通常都會選擇自己最熟悉的管理方式。這個時候，如果團隊中沒有一個真正懂得這套體系的價值，並且能夠強勢堅持的人，流程就會發生退化。

二是團隊的職責範圍定的太窄——我們的交付團隊最初建設的時候，基本上是基於一個系統的，比如酒店交易的「用戶系統」、「訂單系統」。這在產品/系統建設的初期是沒有問題的，因為每個系統本身都還不完善，需要做的事情很多，大部分需求都可以由一個團隊獨立完成。但是隨著產品/系統的建設成熟，單個系統上可以做的東西越來越少，更多的需求會需要跨多個系統修改，這時候團隊的「高內聚，低耦合」特性就不存在了。

那麼怎樣解決這樣的問題呢？

今年3月中旬，我去上海與攜程的技術與管理同學們做交流，有幸與大家公認的「敏捷做的最好的團隊」——酒店無線的技術團隊做了一次關於敏捷實施的交流。在這裡把他們的經驗分享給大家。

酒店無線的技術團隊有70多人，組織架構按照技能劃分為iOS團隊、Android團隊、Service團隊和測試團隊（見下圖），存在的主要問題包括：

• 開發周期過長，從拿到PRD到交付要跨越一個月或者兩個月。

• 需求變更頻繁，2個月內會有很多變化，導致已經開發的代碼被浪費。

• 團隊成員技能單一，不能根據需要互相援助。

• 開發團隊只是被當作執行者，沒有目標感和參與感。

最終這個團隊選擇了scrum的模型，將原有的組織結構整合重編，調整成了如圖所示的一系列的scrumteam。每個scrum team都是完整的交付團隊，包含iOS、Android、Service開發和測試。並且鼓勵一專多能，iOS開發也會參與Service開發工作。每個團隊分別對應不同的目標（OKR），比如：用戶/訂單增長、基礎體驗優化、系統架構優化等等。

經過這樣的調整，大大縮減了溝通和管理的成本，提升了工作效率；團隊聚焦於目標的實現，會更加積極地參與目標的制定，團隊的士氣也得到了提高。

這種做法不僅解決了案例二中組織結構不穩固和職責範圍過窄的問題，更好地方在於，它把每個團隊的目標和特定的業務目標明確地關聯在一起，使得每個團隊成員都有可能最大程度地發揮主動性，幫助業務更好地取得成功——我們每年舉辦諸如hackathon之類的活動，希望工程師們能夠發揮創意，解決更多的業務問題。而事實上，如果能夠提供更加有效的組織結構和管理流程，工程師們每天都可以hackathon。

這個案例是局部的比較徹底的敏捷實踐，採用了組織變革的方式，將組織結構調整為基於交付團隊（敏捷團隊）而非職能團隊。並且在這個基礎上，逐步形成「無邊界」的工程師文化。這個實踐目前攜程的酒店無線技術團隊正在嘗試，我們期待這個團隊能夠成為一個標杆，帶動大家走向更加開放、更加敏捷的文化。

案例四：強健的工程體系和文化

採用scrum的這種模式，顯然在速度和靈活性方面有很大的優勢。但是，天下沒有白吃的午餐，想要獲得好處，就必然要付出代價。那麼，敏捷要付出的代價是什麼呢？

顯而易見的，首先是資源問題。敏捷團隊建設過程中最常見的情形之一，就是資源經理說「我的人手不夠，需要在不同的開發組之間協調資源，不然不夠用」，「如果要拆下去的話，我們需要多招N個人，還是現在這樣效率高」。

所以這裡就涉及到人的能力問題，一方面我們需要有招聘人的能力，以達到各種資源的合理配比；另一方面，我們要有培養人的能力，鼓勵團隊成員成為「多面手」，每個人都能承擔至少2種角色，這樣在有需要的時候可以在團隊內部相互彌補。事實上，資源問題是個比較容易解決的問題，只要大家有意願、去努力，幾乎所有的團隊都能做到。

而真正嚴重的，其實是質量問題。很多強硬地推行了敏捷最後又退化的團隊，絕大部分都是因為hold不住質量。網上有很多這樣的案例，大家可以自己搜著看。

去哪兒酒店以前的交易系統HMS，當時就是有4個獨立的開發團隊在上面工作，分別對應不同的業務，就是因為沒有控制住質量，最後不得不用上100多個人、幾個月的時間，把系統重新做了一遍，就是現在的QTA。以至於團隊的老成員們都有點心理陰影，一聽說要讓幾個團隊修改同一個系統就緊張。

而我們之所以一直只在小範圍做試點，沒敢大規模地「推敏捷」，最擔心的也是這個問題——如果沒有足夠的把握，能在這種組織模式下保證系統的質量，即使我們「推」成功了，總有一天還會要退回去的。

那麼怎樣保證質量呢？

這個時候就可以翻開敏捷的書籍們了，裡面有各種各樣的實踐：單元測試、持續集成、codereview……遵循這些實踐，我們最終的目標是打造一個質量風險高度可控的工程體系，並且在這個過程中提升人員的能力，形成團隊的文化。

這裡分享一下Google在工程體系方面的實踐。

Google的所有代碼全部放在一個代碼庫中，除了搜索引擎的核心演算法等少數模塊，絕大部分代碼是沒有許可權控制的，所有人都可以修改。代碼全部是主幹開發以及源碼依賴，自動化的測試（包括單元測試）、持續集成和code review是必須的——每次提交代碼時，系統會基於最新的源碼進行編譯，並執行自動化測試。自動化測試不僅會「向下」執行，而且會根據依賴關係「向上」執行所有可能被影響到的系統/模塊的test case。持續集成通過之後，還要經過code review，沒有問題了代碼才能真正入庫。

這種做法保證了代碼庫的基礎質量，建立了可以讓「任何人隨時修改任何代碼」的體系能力。

這樣的工程體系很好很強大，顯然要投入相當多的資源和時間去建設，而且需要每一個工程師時時刻刻都用心去維護，這就必須要形成工程質量的文化。

那麼，什麼是工程質量的文化呢？當我們提到敏捷的團隊是面向目標而非系統時，很多leader的第一反應是：「系統沒有owner，質量怎麼辦？」 其實潛在的意思就是「是owner的人才會好好乾，不是owner的人就會隨便造。」這樣的文化是不可能把敏捷做好的——系統沒有owner，就需要每個人都有owner的意識，這才是敏捷的文化！只有建立了這樣的文化，敏捷的體系才能夠長期有效地運作。

最後分享一個關於文化的案例。

我在前一家公司（騰訊）工作的時候，團隊也在實施全主幹開發、全源碼依賴以及持續集成等實踐。當時新版的搜索引擎和雲計算平台都在開發中，搜索引擎依賴雲計算平台。搜索引擎團隊有幾個開發leader經常投訴雲計算平台，因為他們發現很多次持續集成不通過的原因，是雲計算平台有bug、不穩定。他們覺得太影響效率，要求雲計算平台發布穩定分支，開發團隊基於穩定分支做集成。只有2個前Google的開發leader說：「沒關係，我們就依賴最新的源碼，這樣才能第一時間幫助他們發現問題，儘快解決，系統就會做的更好。」

大家可以看到，開放的企業文化會造就同樣開放和有大局觀的員工——不own一個系統，工程師們會own所有。

這個案例是公司級的極致的敏捷實踐。打造這樣的工程體系和文化，成本是巨大的。我們要不要投入這樣的成本去換取極致的速度與靈活性？或者說什麼時候才是「合適」去做這件事的時候？我們仍然在探尋中。

【作者簡介】黎娟，去哪兒過程改進總監。15年軟體項目管理及過程改進經驗，曾先後就職於雅虎中國/阿里巴巴、騰訊、去哪兒網，擅長問題分析以及基於問題驅動的過程改進。本文來自黎娟在「攜程技術沙龍——敏捷總動員」上的分享。

沒看夠？更多來自攜程技術人的一手乾貨，歡迎搜索關注「攜程技術中心」微信公號哦~

推薦閱讀：