想要把握這個時代扮超，就必須理解計算機。理解計算機的關(guān)鍵，則是要理解計算機背后的人出刷。

背景介紹

互聯(lián)網(wǎng)時代璧疗，頭部的基本需求已經(jīng)被全部滿足，未來的方向或許是現(xiàn)有模式的顛覆馁龟，或許是長尾個性化需求的充分滿足崩侠，又或許是小眾人群的挖掘。在這樣的大背景下坷檩，如何通過極致的研發(fā)運營效率却音，快速發(fā)現(xiàn)新的機會，降低創(chuàng)新成本就變得尤為重要矢炼。

實際上僧家，國外的互聯(lián)網(wǎng)公司已經(jīng)做了先行者，進行了很多不同的實踐裸删，其中之一就是持續(xù)交付。有人問：“為什么持續(xù)交付的概念在09年就已經(jīng)在國外盛行阵赠，而中國近幾年才開始流行涯塔？”

面對這樣的問題，有三個這樣的答案清蚀。

• 百度工程效率部負責人：這是互聯(lián)網(wǎng)發(fā)展的客觀規(guī)律匕荸，現(xiàn)在的企業(yè)對精益團隊有需要了，運維等底層技術(shù)也在不斷突破枷邪；
• 喬幫主：90年左右國外軟件工程就開始發(fā)展了榛搔，而中國的黃金一代在98年，我們?nèi)匀惶幱谝粋€補課的階段东揣；
• 騰訊副總裁：現(xiàn)在生意不好做了践惑，人手不夠但要做事，就開始講究效率了嘶卧。

騰訊的答案給人印象深刻尔觉，跟我們現(xiàn)在的實際場景也很像〗嬉鳎或者說侦铜，這是企業(yè)發(fā)展到一個階段的必然現(xiàn)象。

開始之前

文章的內(nèi)容多摘抄于《持續(xù)交付2.0》(侵權(quán)即刪)钟鸵，也希望大家能夠購買并閱讀喬老師的新作钉稍，我也算為精益思想的布道做了力所能及的貢獻。
在簽售會上棺耍，喬梁老師用了一個小時來介紹寫書的用意贡未，以幫助讀者更好的認識持續(xù)交付2.0。
這里，筆者不自大于能帶領(lǐng)大家領(lǐng)略持續(xù)交付方法論的思想羞秤，但希望文章能夠給大家埋下一個意識缸托，在面對組織上的迷茫時，能夠想起有持續(xù)交付這個方法瘾蛋，然后翻開書本俐镐，揣摩其深意。
如此這般哺哼，就是有價值的佩抹。

歷史縮影

Part I

在1968年，出現(xiàn)了第一次軟件危機取董，落后的軟件生產(chǎn)方式無法滿足迅速增長的計算機軟件需求棍苹，導(dǎo)致軟件開發(fā)和維護過程中出現(xiàn)一系列嚴重的問題。

在全新的計算機領(lǐng)域中茵汰，人們借鑒了工程領(lǐng)域的工程方法枢里，以實現(xiàn)“按預(yù)算準時交付所需功能的軟件項目”的愿望！

1970年蹂午，Dr. Winston 首次提出了瀑布式軟件開發(fā)方法栏豺，它將軟件開發(fā)過程定義為多個階段，每個階段有嚴格的輸入和輸出標準豆胸，管理者希望通過這種重計劃奥洼、重流程、重文檔的方式來解決危機晚胡，具備這三個特征的開發(fā)方法統(tǒng)稱為“重型軟件開發(fā)方法”灵奖。

瀑布圖

軟件開發(fā)像瀑布一樣，從一個階段流向另一個階段估盘。實際開發(fā)過程中瓷患，每個階段都需要花費過長的時間(數(shù)月)，需求也在不斷變更遣妥，然后按預(yù)算準時交付的問題仍然沒有得到很好的解決尉尾。

Part II

1994年，Chaos Report 顯示燥透，軟件交付項目的失敗或交付困難的比率仍舊很高(成功率16.2%沙咏，受到挑戰(zhàn)的52.7%，失敗的31.7%)班套。

很多優(yōu)秀的軟件工作者也不滿意于瀑布式開發(fā)的交付成果肢藐，并在工作實踐中總結(jié)了新的開發(fā)方法。在2001年吱韭，17位軟件大師齊聚加拿大的小鎮(zhèn)“雪鳥”吆豹，總結(jié)了“輕量級軟件開發(fā)方法”的特點鱼的，發(fā)表了“敏捷宣言”。

敏捷開發(fā)方法痘煤，從一開始就不特指某一種開發(fā)方法凑阶，而是一簇軟件開發(fā)方法的代名詞。

敏捷的核心原則是：強調(diào)人的主觀能動性衷快，提倡面對面溝通宙橱、擁抱變化、通過迭代和增量開發(fā)盡早交付有價值的軟件蘸拔。

很多團隊認識到师郑，軟件開發(fā)其實是一件不斷迭代學習的過程，軟件工程師需要不斷和業(yè)務(wù)領(lǐng)域?qū)＜医涣饔懻搧韺W習调窍，將其轉(zhuǎn)化為數(shù)字世界的表達方式宝冕，并不斷持續(xù)這個過程。簡單的說邓萨，把業(yè)務(wù)和軟件工程師整合在一起地梨。

在敏捷早起，迭代的周期仍然非常的長缔恳，業(yè)務(wù)人員和研發(fā)人員之間關(guān)于需求的變更仍然是主要矛盾湿刽。

這兩個時期，無論是瀑布式開發(fā)還是敏捷開發(fā)褐耳，最重要的關(guān)注點都是可交付的軟件包本身，即如何快速的把軟件需求變成可交付的軟件包渴庆。

敏捷實踐

軟件需求的反復(fù)變更铃芦，儼然成為了IT領(lǐng)域最為突出的問題。

從“敏捷宣言”中襟雷，我們已經(jīng)看出了解決的方向：擁抱變化刃滓、盡早交付、增量開發(fā)耸弄、反復(fù)迭代咧虎。

接下來一系列的實踐，都在體現(xiàn)這樣的精神计呈。

持續(xù)集成

“持續(xù)集成”作為敏捷開發(fā)方法的一個工程實踐砰诵，率先被廣泛的IT組織接受。

持續(xù)集成捌显，就是把完成的代碼不斷轉(zhuǎn)變成可交付的代碼茁彭。簡單的說，把開發(fā)和測試的職責整合在一起扶歪。

DevOps

在2008年的多倫多敏捷大會上理肺，一個“敏捷基礎(chǔ)設(shè)施”的臨時話題中，獨立IT咨詢師 Patrick 分享了一個“將敏捷實踐應(yīng)用于運維領(lǐng)域”的討論，并成功催化出一種運動妹萨，迅速傳播年枕，這個運動就是DevOps。

DevOps的原始定義是“DevOps是運維工程師和開發(fā)工程師參與整個服務(wù)生命周期的一組實踐”乎完，并提出熏兄，倡導(dǎo)運維人員更多地使用和開發(fā)人員使用的相同的技術(shù)來進行系統(tǒng)運維工作。簡單的說囱怕，把開發(fā)工程師和運維工程師整合在一起霍弹。事實上，截止到今天娃弓，業(yè)界對于DevOps都沒有統(tǒng)一的標準定義典格，如同敏捷，每一位從業(yè)者都有他自己的看法台丛。但是值得明確的是耍缴，它們的目標和原則都非常明確，DevOps的目標是縮短開發(fā)周期挽霉，提高部署頻率和更可靠的發(fā)布防嗡，與業(yè)務(wù)目標保持一致。

和敏捷開發(fā)方法相似侠坎，DevOps并非一個標準蚁趁、一個模式 or 一個固定方法，它在提出之時的實操指導(dǎo)性略顯不足实胸。同一時間他嫡，IT領(lǐng)域出現(xiàn)了的另一個概念“持續(xù)交付”。

DevOps

教研-開發(fā)

持續(xù)交付 1.0

敏捷之勢庐完，愈演愈烈钢属，絕知此事須躬行。

秉承能夠?qū)嵺`的原則门躯，10年正式出版了一本書《持續(xù)交付》淆党，持續(xù)交付被定義為一種能力，以一種可持續(xù)的方式讶凉，安全快速的把代碼部署到生產(chǎn)環(huán)境上染乌，讓用戶使用。簡單的說懂讯，把業(yè)務(wù)人員慕匠、開發(fā)人員、測試人員和運維人員都整合在一起域醇。業(yè)務(wù)人員提出軟件需求台谊，開發(fā)人員完成編碼蓉媳，測試人員檢測功能，運維人員部署并監(jiān)控服務(wù)锅铅，業(yè)務(wù)人員通過監(jiān)控數(shù)據(jù)提出新的軟件需求酪呻，這就是持續(xù)交付1.0的閉環(huán)模型。

持續(xù)交付1.0

持續(xù)交付這本書盐须，提供了一系列工作原則和優(yōu)秀的實踐方法玩荠，真正在實踐中提升了軟件開發(fā)活動的效率，是一個經(jīng)過檢驗的范式贼邓。

精益思想

技術(shù)必須創(chuàng)造價值阶冈，如果沒有或者不夠，那一定是我錯了塑径。

在實際場景中發(fā)現(xiàn)女坑，有一些軟件功能并沒有產(chǎn)生什么影響，根本沒有用戶使用统舀。但是這些功能確實花費了團隊的很多精力才設(shè)計實現(xiàn)匆骗，這是一種巨大的浪費。這種“無效”的功能越多誉简，浪費就越大碉就，我們能否找到一些方法，讓我們付出的努力對業(yè)務(wù)改善更加有效闷串，或者只用很少的成本就驗證對業(yè)務(wù)無效呢瓮钥？

最小可行性產(chǎn)品（Minimum Viable Product, MVP）。這個原型并不是一下子設(shè)計得到一個完美的產(chǎn)品烹吵，而是為了驗證自己心中的商業(yè)假設(shè)碉熄，得到用戶的真實反饋后，從每次的結(jié)果中學習年叮，再快速迭代，持續(xù)修正玻募，在資源耗盡前從迷霧中找到通往成功的道路只损，最終適應(yīng)市場的需求。

精益思想七咧。根據(jù)用戶需求跃惫，定義企業(yè)生產(chǎn)價值，按照價值流來組織全部生產(chǎn)活動艾栋，使價值在生產(chǎn)活動之間流動起來爆存，由需求拉動產(chǎn)品的生產(chǎn)，從而識別整個生產(chǎn)過程中不經(jīng)意間產(chǎn)生的浪費蝗砾，并消除之先较。在業(yè)務(wù)生產(chǎn)中的所有活動携冤，可以被歸結(jié)為兩種，增加價值的活動和不增加的闲勺，不增加價值的活動就被稱之為“浪費”曾棕，浪費也可以被歸結(jié)為兩種，必要的浪費（工作項的交接菜循、尋找信息翘地、測試、管理）癌幕，和不必要的浪費（無人使用的功能衙耕，庫存，軟件缺陷）勺远。

盡管“消除所有浪費”幾乎是不可能的橙喘，但是，我們?nèi)耘f要全面貫徹“識別和消除一切浪費”的理念谚中，持續(xù)不斷的優(yōu)化流程和工作方式渴杆，達到高質(zhì)量、低成本宪塔、無風險地快速交付客戶價值的目的磁奖。

持續(xù)交付 2.0

回到開始，我們正處于一個補課的階段某筐。

2009年左右比搭，LinkedIn 從過去每年發(fā)布12次，到現(xiàn)在實行3x3南誊，每周部署3次（Mon, Wen, Fri）身诺，每天發(fā)布3次(11am, 1pm, 4pm)，Amazon的成功是每年抄囚、每周霉赡、每月、每天多次實驗的結(jié)果幔托，F(xiàn)aceBook在任何時候都不只一個版本在運行穴亏，而是一萬個。

“持續(xù)交付2.0”是一種產(chǎn)品研發(fā)管理思維框架重挑。簡單的說嗓化，精益思想和持續(xù)交付1.0整合起來，強調(diào)業(yè)務(wù)和技術(shù)之間的快速閉環(huán)谬哀，以一種可持續(xù)方式刺覆，高質(zhì)量、低成本史煎、無風險地快速交付客戶價值谦屑。對企業(yè)來說驳糯，開發(fā)軟件產(chǎn)品的目標是創(chuàng)造客戶價值椅挣。因此卖氨，我們不應(yīng)該僅僅關(guān)注快速開發(fā)軟件功能譬圣，同時還應(yīng)該關(guān)注我們所交付的軟件的業(yè)務(wù)正確性胶坠，以及如何以有效的資源快速驗證和解決業(yè)務(wù)問題缆镣。也就是說君躺，不斷探索發(fā)現(xiàn)真正要解決的業(yè)務(wù)問題纬乍，提出科學的目標跋选，設(shè)計最小可行解決方案谓苟，通過快速實現(xiàn)解決方案并從真實反饋中收集數(shù)據(jù)官脓，以驗證該問題是否得以解決。這是一個從業(yè)務(wù)問題出發(fā)涝焙，到業(yè)務(wù)問題解決的完整業(yè)務(wù)閉環(huán)卑笨，也是一個整合精益思想和持續(xù)交付的雙環(huán)模型。

持續(xù)交付2.0的四個核心原則

• 堅持少做

  • Netflix 認為仑撞，它們想做的事情中赤兴，可能有90%是錯誤的。
  • MicroSoft 認為隧哮，那些旨在改進關(guān)鍵指標而精心設(shè)計和開發(fā)的功能特性中桶良，只有1/3左右成功改進了關(guān)鍵指標。
  • Instagram 被問及“5個工程師如何支持4000萬用戶沮翔？”時說陨帆，“少做，先做最簡單的事情”采蚀。

• 持續(xù)分解問題
  復(fù)雜的業(yè)務(wù)問題中一定會包含很多不確定因素疲牵，它們會影響問題解決的速度和質(zhì)量。通過對問題的層層分解榆鼠，可以讓團隊更了解業(yè)務(wù)纲爸，更早識別出風險。

• 堅持快速反饋
  如果忽視每一項工作的結(jié)果反饋妆够，那么就失去了由問題分解帶來的另一半收益识啦，確認風險降低or解除！

• 持續(xù)改進并衡量
  無論做了什么樣的改進责静，如果無法以某種方式衡量它的結(jié)果袁滥，就無法證明真的得到了改進盖桥。

2.0 雙環(huán)模型

價值探索環(huán)

這是一個外在的環(huán)灾螃，價值只能被外部定義。

很多企業(yè)在開發(fā)新產(chǎn)品時揩徊，會采用“概念驗證”或“產(chǎn)品原型法”腰鬼，然后用較長的開發(fā)過程去實現(xiàn)產(chǎn)品嵌赠。由于市場變化太快，花大量時間完成開發(fā)后熄赡，可能因為對潛在用戶的理解存在偏差or用戶需求發(fā)生變化姜挺，導(dǎo)致當初的設(shè)計不被市場接受。在這個過程中有三個假設(shè)彼硫，用戶假設(shè)（潛在用戶）炊豪，問題假設(shè)（臆想需求），解決方案假設(shè)（我們很牛）拧篮。這三類假設(shè)中词渤，任何一個不成立，都會導(dǎo)致事倍功半串绩，甚至前功盡棄缺虐。

價值探索環(huán)的目的就是要我們從業(yè)務(wù)問題出發(fā)，和團隊一起礁凡，共同找出這三類假設(shè)高氮，制定MVP，借助環(huán)的高速運轉(zhuǎn)顷牌，獲得反饋剪芍，不斷驗證和迭代。

• 提問
  不僅僅是找到“實現(xiàn)什么”以及“如何實現(xiàn)”韧掩，更要了解“為什么要實現(xiàn)”紊浩。

舉辦一個知識分享會，有一個客戶希望下午能喝一杯咖啡疗锐。于是我們就問“需要什么口味”“熱的還是冰的”“大杯還是中杯”“什么時候拿到”坊谁，這樣就會去準備冰箱、冰塊滑臊、水杯等等口芍。反而忽略了客戶為什么想要咖啡。如果客戶是因為害怕而錯過精彩分享雇卷，我們是不是可以采取錄制視頻鬓椭，增加互動環(huán)節(jié)，允許會場走動等活動关划。

• 錨定
  當選定問題之后小染，我們要確定具體的目標和結(jié)果。
  目標最重要的特征之一是可客觀衡量贮折。學生喜歡的課程（學生有效停留率達到95%）裤翩，有效的課程（糾錯率達到60%），服務(wù)的穩(wěn)定性（成功響應(yīng)率達到99%）调榄。

• 共創(chuàng)
  有了目標之后踊赠，團隊為設(shè)法驗證or達成目標而找出多種可行性解決方案的過程呵扛。
  同樣的，方案最重要的特征之一就是要有量化指示器筐带！為了提高產(chǎn)品的使用率今穿，team member要提高產(chǎn)品的有效率（學生的絕對糾錯率達到70%），team leader要提高團隊的效率（做課效率從10人天提升至2人天）伦籍，tech team要賦能業(yè)務(wù)（監(jiān)控數(shù)據(jù)從每周更新到每天更新）蓝晒。

• 精煉
  在共創(chuàng)環(huán)節(jié)會有多個方案，精煉是從中選出團隊認為最小可行性解決方案的過程帖鸦。
  不難想象拔创，哪怕是巨大的工程，其解決方案也是一組迷你方案的集合富蓄。精煉的目的不是并不是為了刪除在共創(chuàng)階段得出的解決方案剩燥，而是將它們按照優(yōu)先級排列，并讓團隊將解決方案進一步分解立倍，順序選出共同認可的最重要改進項灭红，并確保它能夠盡早被驗證。那么口注，如何確定我們完成了精煉呢变擒？可以嘗試寫出下面的句子。

我們相信寝志，通過實現(xiàn)（xxxx最小功能組合）娇斑，我們的指標可以達到（xxxx程度）的話，說明我們關(guān)于（xxxx）的假設(shè)是成立的材部。

工作原則

• 分解并快速試錯
• 一次只驗證一點
• 允許失敗

快速驗證環(huán)

這是一個內(nèi)在的環(huán)毫缆，有了需求，如何快速上線并獲得真實可靠的反饋乐导。

質(zhì)量和速度是驗證環(huán)的關(guān)鍵苦丁，也就是說，發(fā)布質(zhì)量好而且頻率要高物臂！(一些來自于1.0的方法：質(zhì)量內(nèi)建旺拉、小批量交付、自動化一切重復(fù)工作)

• 構(gòu)建
  構(gòu)建是將自然語言的描述轉(zhuǎn)換成計算機可執(zhí)行的軟件棵磷，即可交付的軟件包蛾狗。
  這個環(huán)節(jié)參與的角色最多，參與角色如業(yè)務(wù)人員仪媒、產(chǎn)品經(jīng)理沉桌、工程師，每個角色的背景知識和技能優(yōu)勢各不相同，如何快速將人們頭腦中的解決方案變成可以運行的高質(zhì)量軟件包蒲牧，一致是軟件工程領(lǐng)域的難題。這也決定了這是驗證環(huán)內(nèi)不確定因素最多的一個環(huán)節(jié)赌莺。有三個方法可以了解一下：時間盒管理（timeboxing - deadline）冰抢、任務(wù)分解（breakdown）、持續(xù)驗證（demo）艘狭。

• 運行
  運行將可交付的軟件包部署至生產(chǎn)環(huán)境挎扰。
  如何讓用戶在無感知的情況下完成軟件版本的升級更新是互聯(lián)網(wǎng)時代最為重要的課題。這一階段是開發(fā)和運維之間發(fā)生沖突最多的環(huán)節(jié)巢音，也是重復(fù)性手工操作最多的環(huán)節(jié)遵倦。

• 監(jiān)測
  監(jiān)測是收集數(shù)據(jù)，統(tǒng)計展現(xiàn)結(jié)果官撼、及時發(fā)現(xiàn)生產(chǎn)系統(tǒng)問題以及業(yè)務(wù)指標的異常波動并作出適當?shù)姆磻?yīng)梧躺。

• 決策
  決策是指受到真實的業(yè)務(wù)數(shù)據(jù)反饋結(jié)果后，根據(jù)探索環(huán)中已確定的響應(yīng)衡量指標進行對比分析傲绣，從而驗證是否符合最初的預(yù)期掠哥。

工作原則

• 質(zhì)量內(nèi)建(built quality in)
  從生產(chǎn)過程的第一個環(huán)節(jié)起，就要注重產(chǎn)出物的質(zhì)量秃诵，并且在每個環(huán)節(jié)中都要開展質(zhì)量保障活動续搀，消除因質(zhì)量問題導(dǎo)致的返工及次品率上升，以此降低最終的質(zhì)量風險菠净，保障進度禁舷。

• 消除等待
  價值流動，從關(guān)注“人”到關(guān)注“事”
  任務(wù)自助毅往，讓“專業(yè)”的人做“專業(yè)”的事牵咙，讓“專業(yè)”的任務(wù)能自助

• 重復(fù)事務(wù)自動化
  如果以前一個月發(fā)布一次，現(xiàn)在每個月發(fā)布八次攀唯，那發(fā)布成本就是以前的八倍霜大，所以自動化發(fā)布流程就顯得尤為重要。依此類推革答。

• 監(jiān)測一切
  “應(yīng)用健康監(jiān)測”和“業(yè)務(wù)健康檢測”

補遺

團隊的文化建設(shè)

It is our choices, Harry, that show what we truly are, far more than our abilities.

鏈接中是騰訊的人才發(fā)展觀战坤，干貨很多，值得一讀残拐。

寫書原因

曾：你寫本書吧途茫，把你的精益思想寫出來
喬：為什么要寫啊，你給我一個事情溪食，我能保證把它解決
曾：你能解決一個問題囊卜，一個團隊，可是我有這么多團隊，這么多問題栅组，怎么辦雀瓢？
（語言記錄不盡詳實）

在團隊中也一樣吧，程序員能寫一個模塊玉掸，一個系統(tǒng)刃麸，那企業(yè)有那么多模塊，那么多系統(tǒng)司浪，怎么辦泊业？

A Small Tip

持續(xù)交付2.0是非常好的思維框架，但也并不是可以完全照搬照抄的啊易，框架中重要的是方法論吁伺，讀書的過程更應(yīng)該吸收這種思想。就比如軟件領(lǐng)域的大型游戲開發(fā)租谈，就不可能做一個MVP然后得到用戶真實數(shù)據(jù)后迭代篮奄。

SCRUM中令人愉悅的經(jīng)驗

• 持續(xù)breakdown的做法。其一割去，團隊中每個人都會參與業(yè)務(wù)分解宦搬，讓每個人都有參與感，很容易build團隊歸屬感劫拗，也讓團隊成員相互理解间校；其二：任務(wù)足夠小，一旦完成就可以點掉一個页慷，就像打游戲得分一樣憔足，給個人的反饋非常及時，是一種成就感酒繁；其三滓彰，在持續(xù)分解時，能暴露更多的業(yè)務(wù)細節(jié)州袒，既能少做很多事情揭绑，也能提高了效率。
• 關(guān)注價值的做法郎哭。其一他匪，每天站會都能感受到價值流動，從交付的代碼到實際產(chǎn)生的價值夸研，是直觀的刺激邦蜜，讓人有成就感；其二亥至，sprint的故事拆解環(huán)節(jié)中悼沈，每個故事都必須有價值贱迟，要找到能夠?qū)崿F(xiàn)價值的最少行為，這讓團隊專注絮供，讓價值清晰衣吠。
• 記錄工時的做法。程序員有一些不同的薪酬計算方式壤靶，paid by lines, commits, hours等等缚俏。考慮到程序員其實是“腦力”工作者萍肆，寫代碼是一件非常具有不確定性的工作，SCRUM在試圖不斷減小這種不確定性胀屿，工時直白地展現(xiàn)了一個程序員或者說一個團隊的交付能力塘揣，這很好。不過當工時和薪酬掛鉤時宿崭，hmmm...

** 轉(zhuǎn)載請注明出處 ~