擁抱開發過程中的「黑天鵝」

6月29日，由阿里雲研發協同RDC、阿里云云效和雲棲社區聯合舉辦的「首屆阿里巴巴研發效能嘉年華」上，阿里巴巴資深專家、敏捷教練洪湖帶來「擁抱『黑天鵝』」的演講。本文主要從黑天鵝事件開始談起，接著分析了哪些模式是脆弱的，而後分享了通過案例得出了從變化中獲益的啟示，最後著重說明了打造敏捷組織的重要性。

直播視頻點擊觀看

隨著雲計算、大數據、AI智能等前沿科技的發展，傳統的研發速度越來越難滿足企業快速發展的需求，研發效能也成了繼商業模式、技術突破之後的另一核心競爭力。本文主要從黑天鵝事件開始談起，接著分析了哪些模式是脆弱的，而後分享了通過案例得出了從變化中獲益的啟示，最後著重說明了打造敏捷組織的重要性。一起來了解下吧：

黑天鵝事件

在發現澳大利亞的黑天鵝之前，歐洲人認為天鵝都是白色的，但這個不可動搖的信念隨著第一隻黑天鵝的出現而崩潰。人們總是以自己有限的經驗和不堪一擊的信念來解釋不可預測的黑天鵝事件。黑天鵝無法預測，我們應該做的是適應這種不可知的未來。

那麼，產品開發中可能會碰到什麼樣的「黑天鵝事件」？

我們先來看看想做一個成功產品的背後會有什麼樣的假設呢？

假設1：找到了正確的問題；

假設2：產品被正確定義；

假設3：產品被正確構建；

假設4：做出來的產品可以解決問題；

假設5：有足夠多的人願意買單。

任何一個假設都有可能不成立，在得到最終驗證之前，你沒法預測假設是否成立。

既然黑天鵝事件不可預測，那就不要天真地試圖預測，我們需要適應它們的存在。

怎樣適應「黑天鵝」事件呢？《反脆弱》這本書中給我們介紹了兩點：降低脆弱性和從變化中獲益的能力。弄清楚什麼是脆弱的，比預測對其造成傷害的某個事件是否會發生、何時會發生要容易得多。

什麼是脆弱的

瀑布開發

在瀑布模式下：

如果產品目標錯了，只有產品發布後才能知道目標錯了。而目標是在我們掌握知識最少的時候做出的決策；

如果架構出問題了，也就是技術風險，可能要到後期測試時才會暴露，而我們在設計階段，未寫一行代碼時就做出了最重要的架構決策；

同樣地，還存在集成風險，大家開發的很多模塊代碼在開始測試時才開始集成在一起；此外還有需求變化、延期等······

總體來看，瀑布開發是很脆弱的，它很難應對黑天鵝事件，一旦發生，我們沒辦法及時響應變化。

傳統項目管理

對於傳統項目管理，我們會管理四個變數，範圍、時間、成本、質量。大家都說質量很重要，它會影響我們長期的發展，所以質量不能犧牲。然後我們要確定範圍，估算什麼時候可以交付，以及需要的成本。

在規定的時間、規定的成本里，按照質量的要求，成功的交付了我們達成一致的範圍，這就是一個成功的項目。

那麼，如果這時發生了「黑天鵝」事件，我們會怎麼辦呢？

我們會採取一些秘密武器：例如Copy & Paste，可以快速的把功能實現出來，此外還可以減少測試、沒有自動化、不重構和去掉同行評審等。

之所以會採取以上的一些方法，是因為質量具有滯後性，其它幾個變數發生變化都是馬上就會有反饋的。從而我們的系統開始變的混亂，到處是重複的代碼。每次修改，我們都要祈禱別出問題，因為我們的代碼容易出錯，缺少自動化測試的保護。

整個響應速度越來越慢，我們不斷積累債務，忙於應付新功能，忙於修改BUG。

所以傳統項目管理模式是脆弱的。

組件團隊

現在比較多的團隊是這樣一種分工模式：一群開發按照各自的組件作分工，一個需求過來後，會把任務分配給各個人，各自負責一個模塊。他們之間的工作量不會均衡，這時往往會同時啟動多個需求，出現大量並發任務在進行的情況。

這時，如果某模塊進展不如預期，所有需求都會受影響；如果出現有人離職、請假時，或者當需求發生變化時，都需要調整所有人的計劃。

為此，有的組織會組建一個團隊去負責某個模塊，開發人員圍繞軟體模塊組合成團隊。這解決了問題了嗎？並沒有。

這種模式一定會導致瀑布式開發，當一個團隊負責某一模塊時，由誰來進行需求分析？由誰來完成高層設計？由誰來完成端到端的測試？由誰來做計劃、協調？，都不是某個團隊，這就需要有業務分析師分析好需求，需要一個架構工程師將架構做好，需要有專門的測試人員做端到端的測試，我們還需要優秀的項目經理，來貫穿協調。

如果中間發生任何變化，都會影響到其它團隊，協調起來非常困難。

這種模式也會鼓勵追求局部效率最優，當我們去看所有的需求時，假設有兩個團隊D和E，前面高優先順序的需求與它倆都沒有關係，它倆可能會啟動新需求。而當它啟動新需求時，需要與其它團隊討論，對其他團隊造成干擾，反而拖慢整個開發進度。

因此，組件化分工、組件團隊也是脆弱的。

高耦合的代碼

圖中反應的是內聚和耦合的關係，顯然它是高耦合的。

• 內聚：一個單位內部各種元素之間的關聯緊密程度；

• 耦合：兩個或多個單位之間的關聯緊密程度。

高耦合會導致代碼難以重用，加小需求可能需要修改N多個地方，隨之可能會帶來一些BUG。

因此，低內聚高耦合的代碼是脆弱的。

總結

什麼是脆弱的？

從流程角度來說，傳統的瀑布開發、項目管理模式是脆弱的；

從技術角度來看，低內聚高耦合的代碼、計劃式設計、缺失自動化保護是脆弱的；

從人的角度的說，專業化分工、組件團隊、豎井組織也是脆弱的。

從變化中獲益

從變化中受益的關鍵之處在哪呢？我們可以從以下兩個案例中得到啟發：

米格-15 vs F-86軍刀戰機

為什麼處處佔盡優勢的米格-15會敗給F-86軍刀呢？

制勝的關鍵是不是絕對速度更快，而是比對手更快的完成OODA環。

小白鼠實驗的啟示

為什麼用小白鼠？因為它的基因序列與人類很類似，繁殖快，生長周期短，且成本低。

當我們面對不確定的「黑天鵝」事件時，從變化中獲益的關鍵是：更快的、更低成本的學習循環，以更快的速度、更低的成本來驗證假設、響應變化。

因此，我們可以給敏捷性定義：組織在不斷變化和不可預測的競爭環境中應對變化和創造變化的能力，這就是我們要打造的能力。

打造敏捷的組織

那麼，如何才能更快的速度、更低的成本 驗證假設、響應變化？

小批量 à 短周期 à 快速反饋 à 響應變化

小批量

小批量的背後是有理論支撐的，如果分析排隊論，會發現批量以及資源利用率對周期的影響，隨著批量和利用率的增加，周期會急劇上升，它不是線性的。

如何小批量呢？

將大需求拆分成小需求，然後按照優先順序排序，進行開發。要避免按模塊拆分。

我們考慮風險驅動和價值驅動去排序，先把高價值、高風險的東西完成掉，快速的獲得這些反饋，才可能以更少的代價、更低的成本、更快速的獲得收益。

很容易得出，迭代開發模式是更適合來應對黑天鵝事件。

技術支撐

演進式設計：原來可以完成所有的設計再開始寫代碼，現在要變成一種演進式的設計，不要去實現未來的需求，只做適度的預先設計並保持合理的設計狀態，才可能在需要添加需求時輕鬆搞定。

改成小批量也不是沒有代價的，隨著批量越大，有些成本是會下降的，而有些成本是會增加的。敏捷開發許多技術上的實踐恰恰是希望解決這些問題，如果我們能夠在減小批量時不顯著增加成本，我們就可以更好的應對開發變化。那麼，哪些實踐會幫助我們控制小批量的成本呢？

測試自動化

我們需要構建分層的自動化測試體系，圖中越向上，越接近業務，反應真實需求狀況；越往下，越面向技術，成本更低、影響範圍更小，發現問題定位起來更容易。我們需要分層的自動化測試體系支撐快速迭代模式。

持續集成/持續部署

工程師每修改幾行代碼，每完成一小點功能，我們就可以提交代碼，觸發自動化測試得到驗證，才能快速地獲得反饋，去保證軟體一直處於可工作的狀態，如果沒有技術手段的保證，是沒有辦法用迭代開發模式的。

敏捷項目管理

讓範圍成為變數。在開發需求分析過程中，堅持質量內建，在時間和成本的約束下，讓價值產出最大化。

全功能團隊

在組織層面我們需要全功能團隊，面向特性的自組織團隊保證端到端的價值交付。一個需求的交流協作都是團隊內部的交流協作，可以更快速的應對變化。我們更鼓勵無差別的全功能團隊，當需求發生變化時，可以很容易作出調整。

我們希望打造有一個敏捷的組織，從交付層面講，用小批量、短周期方式更快地作迭代，用全功能的組織形式靈活地響應變化，同時，我們需要獲得快速地反饋不斷持續改進。

與其預測風雨，不如打造方舟！

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