一句話概括我所做的事情就是：幫助研發(fā)團(tuán)隊(duì)改進(jìn)研發(fā)流程，包括使用工具、使用方法、借鑒他人經(jīng)驗(yàn)等方式，讓大家的軟件開發(fā)效率變得更高。
我的DevOps之路
DevOps這個(gè)詞從一出現(xiàn)就受到很多關(guān)注，尤其是近一兩年來變得非常熱，以致大家對(duì)DevOps有很多的誤解，這種熱度確實(shí)有一定的炒作的成分，但個(gè)人覺得任何事情的出現(xiàn)和流行都有其內(nèi)在的原因，DevOps也不例外。
本篇簡單總結(jié)過去十年我所做的相關(guān)的事情，通過我的經(jīng)歷來看過去十年DevOps在國內(nèi)的發(fā)展歷程。希望這個(gè)過程可以幫助大家了解：DevOps到底是什么、是做什么的、能幫到我們什么。由于是結(jié)合我個(gè)人經(jīng)驗(yàn)來談DevOps，所以很多說法會(huì)帶有個(gè)人的主觀判斷，分享給大家，旨在一起探討。
第一個(gè)時(shí)間點(diǎn)：2005年
之所以把第一個(gè)時(shí)間點(diǎn)放在2005年，是因?yàn)檫@一年我從澳洲回到北京，組建了一家外企研發(fā)中心。在這之前我就是一個(gè)純粹的開發(fā)人員，寫code、做項(xiàng)目、做產(chǎn)品、做發(fā)布，從2005年起我的角色開始轉(zhuǎn)變，開始要去帶一個(gè)團(tuán)隊(duì)，并從團(tuán)隊(duì)的角度考慮問題。
當(dāng)我在國內(nèi)找到了幾名開發(fā)人員和我一起做一些項(xiàng)目的時(shí)候，我發(fā)現(xiàn)了第一個(gè)問題：當(dāng)時(shí)我們的源代碼管理服務(wù)器處于澳大利亞悉尼，在北京如果想要把代碼提交過去非常痛苦。這種痛苦到什么程度呢？我們切入一個(gè)文件大概需要十分鐘的時(shí)間，這是非常讓人無法容忍的事情，會(huì)嚴(yán)重造成工作效率的低下。
我們找各種辦法希望能解決這個(gè)問題，包括提高網(wǎng)絡(luò)連接，但遺憾的是沒有找到更好的辦法。老板和微軟的關(guān)系特別好，他看到了微軟一個(gè)還沒有發(fā)布的產(chǎn)品——TFS（當(dāng)時(shí)還處于beta版本），我們注意到這個(gè)產(chǎn)品是因?yàn)樗膕ource control是基于HTTP的，所以我們決定把現(xiàn)在基于VSS的source control遷移到基于HTTP的TFS的source control上。從2005年開始大概持續(xù)了兩年的時(shí)間，我把公司所有的項(xiàng)目從VSS遷移到了HTTP。
其實(shí)VSS也是一個(gè)很不錯(cuò)的source control，但當(dāng)出現(xiàn)這種跨地域訪問的時(shí)候它的性能就會(huì)有很大的問題。這是我接觸專業(yè)的軟件工程工具或開始去想如何提高團(tuán)隊(duì)效率的一個(gè)起點(diǎn)。
第二個(gè)時(shí)間點(diǎn)：2008年
第二個(gè)關(guān)鍵時(shí)間節(jié)點(diǎn)是2008年，當(dāng)時(shí)我和微軟組織了一個(gè)叫VSTS Real World的活動(dòng)，這場活動(dòng)實(shí)際上就是：我們找到了很多國內(nèi)有影響力的獨(dú)立軟件開發(fā)商，把其中比較資深的軟件開發(fā)人員集中到一起，讓他們?nèi)ンw驗(yàn)如何在一個(gè)完整的軟件工程管理平臺(tái)上，完成一個(gè)軟件從需求到分析到開發(fā)到測試到打包到發(fā)布的過程。
從微軟的角度來說，是希望推廣他們的工具；從我的角度來說，是第一次完整地把自己之前在軟件交付整個(gè)端到端的流程方面的經(jīng)驗(yàn)分享到自己團(tuán)隊(duì)之外去。
活動(dòng)開發(fā)的項(xiàng)目是以汶川地震這個(gè)背景為假設(shè)場景，要求開發(fā)一個(gè)叫“孤兒領(lǐng)養(yǎng)”的系統(tǒng)。
這個(gè)項(xiàng)目對(duì)我個(gè)人來說非常重要，它是我作為軟件工程顧問所完成的第一個(gè)完整的項(xiàng)目。雖然是一種培訓(xùn)的交付形式，但其實(shí)在制作這場活動(dòng)的相應(yīng)的資料時(shí)，我是把自己和團(tuán)隊(duì)的經(jīng)驗(yàn)通過文檔、PPT、示例代碼的方式，整理成一整套的資料分享給其他開發(fā)團(tuán)隊(duì)，并且在這5天的時(shí)間內(nèi)，和大家一起完成一個(gè)真實(shí)的項(xiàng)目開發(fā)。在這個(gè)過程中，我們也采用了一定程度上的敏捷開發(fā)的概念，比如迭代、用戶故事等。
第三個(gè)時(shí)間點(diǎn)：2008-2009年
上圖中有一個(gè)關(guān)鍵時(shí)間點(diǎn)，標(biāo)注著DevOpsDays，DevOps這個(gè)詞的出現(xiàn)大概是在2008-2009年這個(gè)時(shí)間段內(nèi)，這期間開始有越來越多的人關(guān)注到底怎樣提升軟件研發(fā)的效率，DevOpsDays的活動(dòng)是Patrick Debois 在這個(gè)時(shí)間點(diǎn)第一次幫助社區(qū)開始組織這樣的活動(dòng)時(shí)發(fā)起的。在那個(gè)時(shí)間我對(duì)DevOps完全沒有任何理解，對(duì)于我來說，我的理解就是軟件工程，就是幫助團(tuán)隊(duì)提高效率，把工具用好。
第四個(gè)時(shí)間點(diǎn)：2008年-2012年
在2008年-2012年這段時(shí)間里，我所帶領(lǐng)的外企研發(fā)團(tuán)隊(duì)在業(yè)務(wù)上有一個(gè)非常大的轉(zhuǎn)型：2008年以前基本上是對(duì)外做外包，為澳洲總部做軟件外包；2008年以后開始接觸一些國內(nèi)的軟件工程項(xiàng)目，以及研發(fā)平臺(tái)解決方案的工具落地項(xiàng)目，（現(xiàn)在我們叫做DevOps咨詢項(xiàng)目）。之所以從2008年開始轉(zhuǎn)型，有非常重要的外因和內(nèi)因，這也是我希望通過這個(gè)過程和大家分享的。
從一個(gè)企業(yè)來說，為什么會(huì)轉(zhuǎn)變自己的業(yè)務(wù)模式，為什么會(huì)改變自己的研發(fā)模式，其實(shí)很大程度上是因?yàn)橛蟹浅?qiáng)的外因逼迫你不得不這樣做，另外還有非常強(qiáng)的內(nèi)因，讓你自己也意識(shí)到“我可以這樣做”或者說“我這樣做會(huì)比以前做得更好”。
從2008年起，我就開始在國內(nèi)承接一些軟件工程類似的項(xiàng)目，比如研發(fā)過程改進(jìn)、效率提升。我們所接觸的第一家比較大型的客戶是京東商城。之所以重點(diǎn)提起這個(gè)客戶，是因?yàn)閷?duì)于我個(gè)人來說，這個(gè)客戶讓我對(duì)軟件工程有比較深的了解。
首先，京東為什么要做這個(gè)事情？我們?cè)?012年開始和京東做這個(gè)項(xiàng)目的時(shí)候，京東整個(gè)研發(fā)團(tuán)隊(duì)的規(guī)模是大概1500人，在2013年項(xiàng)目結(jié)束我們離開京東這個(gè)團(tuán)隊(duì)的時(shí)候，它的研發(fā)規(guī)模基本翻了一倍。
以此可以看到為什么它會(huì)在這個(gè)時(shí)間點(diǎn)去做這樣一個(gè)項(xiàng)目，因?yàn)檫@時(shí)候如果還沒有人通過專業(yè)的角度去幫助他們梳理研發(fā)流程、考慮在這么大的規(guī)模下怎么保持研發(fā)交付的效率，可能他們?cè)跇I(yè)務(wù)上會(huì)受到非常大的挑戰(zhàn)。
當(dāng)時(shí)我們做了什么呢？我們只做了一件事情：幫助它重新梳理軟件需求上線的過程，并且通過一個(gè)工具把它相關(guān)的系統(tǒng)和信息收集起來，讓他們的開發(fā)團(tuán)隊(duì)、項(xiàng)目經(jīng)理、業(yè)務(wù)人員能很快做出決策，并且將一部分功能自動(dòng)化。
這里一個(gè)大的背景是：我相信現(xiàn)在很多互聯(lián)網(wǎng)公司的需求上線可能仍然是采取這種模式——上線窗口，典型的是，當(dāng)時(shí)京東的上線窗口是每周二和周四，它會(huì)在每周二上線一些大版本或一些比較大的改動(dòng)。
為什么選擇在周二呢？周一剛進(jìn)入公司可能還沒進(jìn)入狀態(tài)，周二開始比較快速地工作，把精力放到工作上，這個(gè)時(shí)間點(diǎn)對(duì)于一個(gè)在線商城來說流量比較低，所以這時(shí)候上一些大版本是相對(duì)安全的；而另一個(gè)時(shí)間點(diǎn)——周四很容易理解，過了周五就是周末了，這個(gè)時(shí)間大家會(huì)考慮是不是要買點(diǎn)東西周末拿回家。
在京東內(nèi)部，他們?cè)诿總�(gè)上線時(shí)間點(diǎn)之前都會(huì)開一個(gè)上線協(xié)調(diào)會(huì)，這個(gè)協(xié)調(diào)會(huì)上就會(huì)出現(xiàn)：一個(gè)團(tuán)隊(duì)說“我作為一個(gè)產(chǎn)品線，我想要去發(fā)布我的需求”，而另外一個(gè)產(chǎn)品線的團(tuán)隊(duì)會(huì)站起來說“你不能發(fā)，因?yàn)槲疫�沒有準(zhǔn)備好”，這時(shí)候就會(huì)出現(xiàn)這種有意見分歧的問題，這樣的問題只有到馬上要到上線時(shí)間點(diǎn)的時(shí)候才會(huì)暴露出來，所以造成很多需求延遲，沒辦法按照希望的狀態(tài)被發(fā)布出去。
我們所做的系統(tǒng)是把這個(gè)信息盡早地收集起來，比如三周以后要上這樣一個(gè)需求，在三周之前提到系統(tǒng)里，系統(tǒng)會(huì)鏈接到需求規(guī)劃、測試、自動(dòng)化打包、上線系統(tǒng)，這個(gè)過程中還會(huì)有一些審批的流程，把相關(guān)的一些關(guān)聯(lián)方依賴方聚合起來，幫助判斷這個(gè)需求是否能上。
其實(shí)從現(xiàn)在DevOps或者敏捷的角度去看這件事情，會(huì)叫測試提前，或者運(yùn)維規(guī)劃提前等這種概念。在那個(gè)時(shí)候京東做的就是這么一件事情，它就是把風(fēng)險(xiǎn)盡量早地暴露出來，讓團(tuán)隊(duì)能夠有更多的時(shí)間去解決這些問題，這樣的話，在真正需要上線的時(shí)候可以非常順利地完成上線操作。
通過這個(gè)項(xiàng)目我開始意識(shí)到：軟件開發(fā)，幾個(gè)人做的時(shí)候是比較簡單的，當(dāng)團(tuán)隊(duì)發(fā)展到一定規(guī)模的時(shí)候，做起來會(huì)越來越困難。這個(gè)困難的來源在于軟件開發(fā)本身是件個(gè)人英雄主義的事情，它必須要依賴于每一個(gè)開發(fā)人員的智慧，去探索創(chuàng)造性地解決問題，這是造成所有軟件項(xiàng)目管理問題的根源，也是其本質(zhì)。對(duì)于軟件開發(fā)來說，沒有辦法認(rèn)清其本質(zhì)就沒有辦法很好地去管理它，就沒有辦法讓你的管理思路選擇適應(yīng)軟件開發(fā)過程的思路而去管理這個(gè)過程，這樣效率肯定上不去。
第五個(gè)時(shí)間點(diǎn)：2016年
到2016年，我以咨詢顧問的身份參與到中國農(nóng)業(yè)銀行的互聯(lián)網(wǎng)金融這個(gè)項(xiàng)目，去支撐和幫助他們解決在項(xiàng)目開發(fā)中遇到的一些問題。到現(xiàn)在為止，我的客戶群體在向金融行業(yè)傾斜。
過去10年間，中國大陸的微軟DevOps工具相關(guān)的所有大型實(shí)施項(xiàng)目都與我有關(guān)，通過服務(wù)過的企業(yè)和十年的實(shí)踐我總結(jié)出：現(xiàn)在最需要軟件工程過程改進(jìn)，或者說需要DevOps的團(tuán)隊(duì)定位是：嚴(yán)重依賴IT的非IT行業(yè)的團(tuán)隊(duì)。
什么是嚴(yán)重依賴IT的非IT行業(yè)的團(tuán)隊(duì)？
比如金融行業(yè)是一個(gè)非常典型的例子。首先任何一個(gè)金融企業(yè)如果沒有IT的支撐，它是根本就轉(zhuǎn)不起來的，但它自己本身的業(yè)務(wù)又是和IT完全不相關(guān)的。這就造成這些企業(yè)的客戶以及這些企業(yè)真正的業(yè)務(wù)從業(yè)人員對(duì)于IT的理解有非常大的誤差，IT人員想要在這些企業(yè)里發(fā)揮作用，就需要和完全不理解IT的人進(jìn)行溝通，同時(shí)要能夠?qū)λ麄冞M(jìn)行交付，導(dǎo)致兩方面的溝通存在很大問題，IT人員還需要對(duì)業(yè)務(wù)進(jìn)行了解，溝通成本的增加對(duì)軟件交付效率造成非常大的影響。
銀行有非常典型的溝通問題，還有一些歷史遺留問題，涉及到粒度和解耦，為什么說這兩個(gè)是DevOps實(shí)施的兩大法寶，這是我在給客戶建議或幫助他們進(jìn)行過程改進(jìn)的時(shí)候所摸索出來的心得。本文將重點(diǎn)分享這兩大法寶。
DevOps實(shí)施落地的2大法寶
不管是敏捷、精益、持續(xù)集成、持續(xù)交付或DevOps等概念，目的都是提高效率，即提高單位資源的產(chǎn)出。其關(guān)鍵原因在于，中國的經(jīng)濟(jì)發(fā)展迅速，很多企業(yè)已經(jīng)度過了那個(gè)靠增加投資來增加產(chǎn)出的階段，現(xiàn)在IT從業(yè)人員薪資在增長，所使用的各種工具和環(huán)境，包括市場都非常成熟，很難找到一種短時(shí)間內(nèi)獲得爆發(fā)性收益的方式，企業(yè)之間到了拼內(nèi)在實(shí)力的階段，在這個(gè)階段效率非常重要。
管理粒度。有兩層含義：1動(dòng)詞，管理這個(gè)粒度，2名詞，管理的粒度。在進(jìn)行研發(fā)效率優(yōu)化的時(shí)候，我們要關(guān)注的就是各種粒度，需求大小、團(tuán)隊(duì)大小、交付的代碼量的多少，原則是越小越好。因?yàn)檐浖邪l(fā)本身是一個(gè)復(fù)雜的過程，對(duì)于復(fù)雜過程的管理永遠(yuǎn)沒辦法適應(yīng)其復(fù)雜度，最有效的方式是將復(fù)雜問題簡單化，然后去管理簡單問題。所以，從管理的角度如果想優(yōu)化效率就要盡量減小管理單元。
工程解耦。軟件工程涉及兩個(gè)領(lǐng)域：管理領(lǐng)域——怎么去管理過程和團(tuán)隊(duì)；工程領(lǐng)域——實(shí)現(xiàn)要實(shí)現(xiàn)的內(nèi)容，從軟件角度來說就是怎么編碼，怎么把大家腦子里的東西變成可運(yùn)行的應(yīng)用和服務(wù)，這個(gè)過程就是工程領(lǐng)域。在工程領(lǐng)域上想提升效率要做的就是解耦，不停地解耦，讓你的程序、服務(wù)、所有部分都可以相對(duì)獨(dú)立地被開發(fā)、測試、部署、運(yùn)行，這樣整體效率才能提升上去。
軟件研發(fā)的自然屬性
建立正確的認(rèn)知才能有正確的辦法。
什么是軟件的生產(chǎn)制造過程？
如果把軟件的開發(fā)過程和汽車的制造過程拿來比較。要制造一輛汽車，首先得有一輛原型車，這輛原型車被確認(rèn)以后，汽車的生產(chǎn)工廠就會(huì)不停地重復(fù)生產(chǎn)同樣的汽車。也就是說汽車的生產(chǎn)過程其實(shí)就是重復(fù)生產(chǎn)同樣的產(chǎn)品。
來看軟件的開發(fā)過程，軟件每次交付的內(nèi)容都不一樣。如果映射這兩個(gè)過程的話，會(huì)發(fā)現(xiàn)軟件開發(fā)的整個(gè)過程，包括需求、設(shè)計(jì)、開發(fā)、測試、構(gòu)建、交付的所有過程都是在進(jìn)行設(shè)計(jì)，而不是在進(jìn)行制造。制造的過程是制造一個(gè)同樣的產(chǎn)品，軟件開發(fā)過程是每次產(chǎn)生不一樣的產(chǎn)品。
回到剛才那個(gè)問題，到底什么是軟件的生產(chǎn)制造過程？其實(shí)很簡單，就是把軟件編譯打包好，右鍵點(diǎn)擊zip包，選擇復(fù)制、粘貼，這就是軟件的生產(chǎn)制造過程。
汽車最大的人員和資源投入是在工廠里，需要大量的工人和技師讓工廠能運(yùn)轉(zhuǎn)起來，制造汽車的資源投入是在重復(fù)的過程中投入比例最大，而做軟件的過程資源投入的比例99.99%是在設(shè)計(jì)過程，因?yàn)槟莻�(gè)復(fù)制&粘貼的過程不需要這么專業(yè)的人來做。
解了這兩者之間的區(qū)別，但有沒有想過，傳統(tǒng)的軟件研發(fā)/軟件工程里所定義的管理方法，都是在用管理一個(gè)汽車生產(chǎn)線上的流程的方法來管理一個(gè)完全不同的設(shè)計(jì)過程。
這就是為什么傳統(tǒng)的軟件工程方法真正用到軟件開發(fā)過程中會(huì)非常難用、還會(huì)出現(xiàn)各種問題的原因。如果采用傳統(tǒng)項(xiàng)目管理方式來管理軟件開發(fā)過程，就相當(dāng)于看到一條筆直的路，要開車從這頭到那頭，打著火、掛上檔、踩油門、松開方向盤、閉上眼睛，希望自己能夠順利地到底終點(diǎn)。
而事實(shí)上，結(jié)果完全不是這樣，會(huì)有軟件變更、用戶變卦、中間出現(xiàn)bug、開發(fā)測試?yán)斫獠灰恢隆⑸暇�過程中環(huán)境不一樣……這些問題都是無法在開發(fā)之前預(yù)見的，整個(gè)軟件開發(fā)過程是一個(gè)設(shè)計(jì)過程，是無法被預(yù)計(jì)、被計(jì)劃，和通過計(jì)劃來控制的。
這就是我說的軟件開發(fā)本身是一件個(gè)人英雄主義的事情，要靠每一個(gè)開發(fā)人員自己的創(chuàng)造性來解決問題，是不能通過一個(gè)看似嚴(yán)謹(jǐn)?shù)沫h(huán)環(huán)相扣的過程來進(jìn)行控制的。在軟件研發(fā)里要強(qiáng)調(diào)的一點(diǎn)：所謂計(jì)劃不是為了限制變化而是適應(yīng)變化的。
敏捷讓我們重新定義管理
這就必須提到敏捷。敏捷是什么，敏捷到底幫助我們認(rèn)清了什么。其實(shí)敏捷真正做的事情是幫我們認(rèn)清了到底什么是軟件開發(fā)，軟件開發(fā)的管理過程到底在管理什么。
傳統(tǒng)的項(xiàng)目管理，管理的是時(shí)間、成本和范圍，它認(rèn)為我們的目標(biāo)是一致的，在一個(gè)固定目標(biāo)的情況下，我們所要管理的就只有成本、時(shí)間和范圍。這就好像我們蓋一棟大樓，肯定是有一個(gè)藍(lán)圖的，有了這個(gè)藍(lán)圖以后這棟大樓到底需要多久蓋一層、蓋一層需要多少資源、需要多少人力投入、可能會(huì)遇到什么問題，這些基本都是可預(yù)知的。
軟件開發(fā)不是這樣，軟件開發(fā)從來沒有定義清楚我現(xiàn)在要蓋一棟大樓，也就是說你從用戶那里拿到的所謂的需求，永遠(yuǎn)都是一個(gè)假設(shè)。為什么說是假設(shè)？需求和假設(shè)到底有什么區(qū)別？區(qū)別就在于：假設(shè)的價(jià)值和質(zhì)量是可變的。當(dāng)你的價(jià)值和質(zhì)量是可變的時(shí)候，其實(shí)你拿到的就是一個(gè)假設(shè)而不是一個(gè)需求。
實(shí)際的體現(xiàn)點(diǎn)是：當(dāng)你把樓蓋到第十幾層的時(shí)候，用戶過來說我要加個(gè)地下室，你肯定覺得用戶瘋了，但是從用戶的角度來說他覺得這個(gè)很正常，他認(rèn)為你不就是一堆代碼嗎？為什么不能在這兒加入一行呢？他完全意識(shí)不到，他所加入的位置其實(shí)是地下室。
原因在于我們所做的軟件是虛擬的，沒有辦法被實(shí)例化，在軟件造出來之前沒有任何人能看到它長什么樣，沒有任何人能體驗(yàn)到這個(gè)軟件最終會(huì)給他什么。作為一個(gè)軟件來說，只有當(dāng)軟件已經(jīng)被做出來給到用戶之后，用戶才真正知道這個(gè)軟件到底是不是符合他當(dāng)初的所謂需求。也就是說，大家看到的需求文檔、開發(fā)計(jì)劃其實(shí)都是假設(shè)，在做出來、代碼寫出來給到用戶之前都通通有可能是錯(cuò)誤的。
當(dāng)我們管理這樣一個(gè)不確定的過程的時(shí)候，如果還用傳統(tǒng)的項(xiàng)目管理方式來管理它的話，必然會(huì)遇到很多問題。敏捷重新定義了軟件開發(fā)管理的思路。它定義的方式就是：把慣常的項(xiàng)目管理認(rèn)為不變的價(jià)值和質(zhì)量定義為可變的變量，傳統(tǒng)的項(xiàng)目管理領(lǐng)域里的變量——時(shí)間、范圍和成本，仍然是變量，所以軟件開發(fā)管理領(lǐng)域中的變量要比傳統(tǒng)項(xiàng)目管理中的變量要多得多、復(fù)雜得多。
這其實(shí)就是軟件研發(fā)的本質(zhì)。軟件研發(fā)的項(xiàng)目管理和傳統(tǒng)的項(xiàng)目管理不是同一個(gè)概念，如果用傳統(tǒng)的方式來管理軟件研發(fā)的過程必然會(huì)遇到問題。
傳統(tǒng)開發(fā) VS 敏捷開發(fā)
上圖是在比較傳統(tǒng)開發(fā)和敏捷開發(fā)，從過程上來其實(shí)是瀑布式和迭代式的比較。瀑布式和迭代式到底有什么區(qū)別？圖的上半部分是瀑布式的過程，下半部分是迭代式的過程。從圖中可以看到兩者最大的區(qū)別就是：迭代式的過程每一個(gè)管理單元會(huì)變得更小，交付的時(shí)間點(diǎn)會(huì)更加提前，實(shí)際上這就是我所說的第一個(gè)法寶——粒度。為什么敏捷開發(fā)能更加適應(yīng)軟件開發(fā)過程，原因就在于它縮小了管理粒度。
當(dāng)你定一個(gè)三個(gè)月的開發(fā)計(jì)劃，并且一次開始執(zhí)行，如果中間出現(xiàn)問題，可能需要把很多東西從頭來過。敏捷開發(fā)要求我們把開發(fā)過程變成一段一段的，每一段都是一個(gè)完整的交付過程。這樣就算犯錯(cuò)誤，所犯錯(cuò)誤的機(jī)會(huì)成本也會(huì)低很多。
也就是說，當(dāng)你的團(tuán)隊(duì)規(guī)模到達(dá)一定程度，當(dāng)你所開發(fā)的軟件體量到達(dá)一定程度，軟件開發(fā)必然會(huì)變成一個(gè)非常復(fù)雜的，并且你沒有辦法去把它管理好的過程。當(dāng)?shù)竭_(dá)這樣的量級(jí)時(shí)怎么處理？千萬不要試圖以一個(gè)非常嚴(yán)謹(jǐn)?shù)墓芾砹鞒虂磉m應(yīng)它，這是不可能做到的。你所要做的就是盡量減少你所管理的單元。簡單來說就是：把你的需求從Word挪到Excel里，把你的需求從一大堆的描述變成一條一條的描述，把你的團(tuán)隊(duì)從幾百人的大團(tuán)隊(duì)變成一個(gè)個(gè)幾個(gè)人十來個(gè)人的小團(tuán)隊(duì)，把你所交付的軟件從一個(gè)單體的軟件變成一個(gè)個(gè)小的服務(wù)，這都是在控制粒度。
當(dāng)你降低了粒度以后，并不是說你變得有多聰明了，而是在你同樣的聰明程度下你所處理的問題的復(fù)雜度降低了，你就能把它處理好。
總結(jié)：計(jì)劃不是用來限制變化的，而是用來適應(yīng)變化的。軟件開發(fā)的計(jì)劃本身也是“管理單元”，計(jì)劃對(duì)變化的適應(yīng)能力來源于計(jì)劃本身“粒度”的縮小。計(jì)劃越大越有可能沒辦法被順利執(zhí)行，計(jì)劃越小就越容易被成功地執(zhí)行。
軟件研發(fā)是一個(gè)復(fù)雜過程，不要試圖用復(fù)雜方法處理復(fù)雜過程，嘗試將復(fù)雜過程簡化成簡單過程，再用簡單方法處理簡單過程。
經(jīng)常有人問我：我的團(tuán)隊(duì)適不適合做DevOps？我的產(chǎn)品適不適合做DevOps？這就是個(gè)偽命題，這個(gè)問題在于你怎么看待你所管理的過程，如果愿意并能夠把管理的過程簡單化，就肯定可以做DevOps，且做DevOps的過程就是在不斷簡單化管理過程的過程。
軟件研發(fā)管理過程全景
到底軟件研發(fā)管理過程是什么樣的？如圖所示，我們要管理的就是圖上的點(diǎn)和線。圖上最下面比較粗的線上列出來的簡寫其實(shí)就是CMMI定義的管理過程。
用CMMI模型可視化地展示一個(gè)軟件研發(fā)的管理過程，從最左邊的需求提起，可以看到包括兩大部分的內(nèi)容：
技術(shù)架構(gòu)——從技術(shù)的角度怎樣來描述產(chǎn)品長成什么樣子，這里看到的就是一個(gè)大的產(chǎn)品，下面分成很多子系統(tǒng)，每個(gè)子系統(tǒng)里包含很多模塊，這就是所能看到的軟件的技術(shù)架構(gòu)。
條目化需求，條目化需求就是用戶提出的一個(gè)一個(gè)的他希望軟件幫助他做到的不同的場景。
往右一點(diǎn)是設(shè)計(jì)過程，軟件的架構(gòu)設(shè)計(jì)就是將用戶所希望實(shí)現(xiàn)的場景和技術(shù)架構(gòu)進(jìn)行映射，需要識(shí)別的是通過哪些技術(shù)可以實(shí)現(xiàn)用戶所希望實(shí)現(xiàn)的場景，并且還要在用戶場景不斷影響技術(shù)架構(gòu)的過程中保持架構(gòu)的穩(wěn)定性、可擴(kuò)展性、性能等。所以它所做的就是把底下的框框和上面的框框聯(lián)系起來。
再往右有一個(gè)項(xiàng)目計(jì)劃，這里我列出來了一些項(xiàng)目，項(xiàng)目里會(huì)有開發(fā)任務(wù)、測試用例、可能還會(huì)有bug等，項(xiàng)目是從左邊的條目化需求引過來的，這是敏捷的做法。
傳統(tǒng)的軟件開發(fā)的做法是：用戶想做這個(gè)事，先做分析，需要實(shí)現(xiàn)哪些技術(shù)模塊，然后要求把技術(shù)模塊的技術(shù)點(diǎn)梳理成所謂的開發(fā)計(jì)劃，它所傳遞的項(xiàng)目來源是來自于產(chǎn)品的模塊，這是一種瀑布的做法。就是在軟件開發(fā)過程中，將業(yè)務(wù)需求打散形成整個(gè)產(chǎn)品的完整設(shè)計(jì)，針對(duì)完整設(shè)計(jì)進(jìn)行完整開發(fā)和完整交付。
它和直接使用條目化需求組織開發(fā)過程的區(qū)別在于：在你進(jìn)行完整設(shè)計(jì)、完整開發(fā)的過程中，會(huì)發(fā)現(xiàn)到了最后收斂的時(shí)候，當(dāng)真正實(shí)現(xiàn)了這些軟件需求，需要通過一些軟件的版本進(jìn)行交付的時(shí)候，你必須要讓這些模塊的功能收斂到用戶希望的場景上。實(shí)際上你交付的還是用戶場景，只是在開發(fā)的過程中把它變成了技術(shù)語言，在最后交付的時(shí)候再把技術(shù)語言轉(zhuǎn)化為業(yè)務(wù)語言。
這兩次轉(zhuǎn)化就意味著我們必須要整體開發(fā)整體交付，也就造成了管理粒度非常大，隨之而來的就是各種問題。
敏捷開發(fā)從過程管理上要把握一個(gè)非常重要的原則：中間的開發(fā)過程必須圍繞一個(gè)一個(gè)條目化的業(yè)務(wù)需求來組織，而不是圍繞技術(shù)功能點(diǎn)。用戶要什么我們就開發(fā)什么，就怎樣去組織開發(fā)過程，最后交給他什么。因?yàn)榫退闶悄惆阉蛏⒊杉夹g(shù)需求，最后交付的還是業(yè)務(wù)場景，這是沒有變化的。技術(shù)與業(yè)務(wù)之間轉(zhuǎn)化的過程，會(huì)造成非常多的問題，包括之前說的依賴問題，都是和過程的組織方式有關(guān)系的。
就這一點(diǎn)在我過去所服務(wù)過的客戶里一些傳統(tǒng)的開發(fā)團(tuán)隊(duì)都非常難做到，因?yàn)檫@和他們現(xiàn)在的管理方法、組織過程以及他們對(duì)軟件開發(fā)的認(rèn)知都是不一樣的。他們可能都會(huì)提我們要做敏捷，可能也會(huì)說我們要用用戶故事來進(jìn)行需求梳理，但他們沒有意識(shí)到用用戶故事的時(shí)候，更深層次的要求是：整個(gè)開發(fā)過程都要圍繞單個(gè)用戶故事作為管理粒度，來推進(jìn)整個(gè)管理過程并且最后進(jìn)行交付。
再往右可以看到編碼、版本、運(yùn)維的各種環(huán)節(jié)，代碼的變更會(huì)從開發(fā)任務(wù)產(chǎn)生出來，也可能會(huì)從測試用例產(chǎn)生出來，但最后都會(huì)被收斂到某一個(gè)版本上，而這個(gè)版本會(huì)按照順序進(jìn)入到我們的開發(fā)環(huán)境、測試環(huán)境、準(zhǔn)生產(chǎn)環(huán)境和生產(chǎn)環(huán)境，最后在環(huán)境里產(chǎn)生出一些反饋，再回到需求，這就形成了完整的軟件研發(fā)過程的閉環(huán)。
結(jié)合前面介紹的內(nèi)容來看，如果從管理過程來理解軟件研發(fā)，管理的就是這里面的點(diǎn)和線；如果從工程角度來理解軟件研發(fā)，更多的傾向是：從開發(fā)測試這個(gè)環(huán)節(jié)開始，怎樣能夠讓做出來的東西更快地進(jìn)入到最后的環(huán)境，并且在這個(gè)過程中保持其跟蹤性以及我們對(duì)質(zhì)量的控制。
總結(jié)：研發(fā)過程改進(jìn)，就是對(duì)上圖中的點(diǎn)和線建立對(duì)應(yīng)的管理單元的過程；并將這些管理單元形成能夠快速交付需求的管理體系。
軟件研發(fā)過程：管理屬性和工程屬性
軟件研發(fā)過程具有管理屬性和工程屬性。管理屬性定義了用戶要我們做什么；工程屬性定義了我們的團(tuán)隊(duì)真正做出來了什么，就是我們交付的東西，這兩個(gè)是軟件開發(fā)里非常重要的轉(zhuǎn)換，而這個(gè)轉(zhuǎn)換靠統(tǒng)一的版本管理來銜接。就是要建立一個(gè)統(tǒng)一的版本號(hào)的規(guī)范，在任何時(shí)候都可以通過一個(gè)編碼快速識(shí)別出現(xiàn)在軟件開發(fā)處于什么樣的狀態(tài)、現(xiàn)在的需求處于什么狀態(tài)、現(xiàn)在需要交付的東西是哪個(gè)。
至此，如果再次反思這個(gè)過程就會(huì)對(duì)第一大法寶——粒度有一個(gè)深入的理解了。軟件開發(fā)過程要管理的其實(shí)就是這個(gè)粒度，目標(biāo)是盡量縮小管理粒度。在整個(gè)軟件研發(fā)體系里流動(dòng)的是被管理的內(nèi)容，需求、任務(wù)、測試用例、編寫的代碼、交付的模塊都是被管理的單元，管理單元越小意味著越容易管理，交付的效率越高。
持續(xù)交付就是持續(xù)解耦
前文討論得更多的是管理屬性，現(xiàn)在來看工程屬性。從工程屬性上我們要做的就是持續(xù)交付。持續(xù)交付到底是什么，持續(xù)交付意味著軟件一直處于可交付狀態(tài)。
持續(xù)交付本身并不完全等同于CI/CD，不完全等于持續(xù)集成和持續(xù)部署，因?yàn)槌掷m(xù)集成和持續(xù)部署只能保證有一個(gè)可交付的產(chǎn)品，或者有一個(gè)可交付的代碼集并可以很快把它轉(zhuǎn)化成交付件，且在交付的過程中可以自動(dòng)進(jìn)行，CI/CD主要做的是這件事，而本身代碼是否處于交付狀態(tài)靠管理過程控制粒度進(jìn)行保證。
持續(xù)交付實(shí)施框架
上圖展示的是持續(xù)交付實(shí)施框架，把持續(xù)交付分成了7大領(lǐng)域，并且把當(dāng)前的實(shí)踐狀態(tài)分成了每100天交付1次和1天交付100次。實(shí)際上在任何一個(gè)團(tuán)隊(duì)里，當(dāng)你希望把自己的交付速度提升到每天交付一百次，那你需要從這7個(gè)領(lǐng)域進(jìn)行規(guī)劃、設(shè)計(jì)、實(shí)施，在這7個(gè)領(lǐng)域里我們到底在做什么，歸結(jié)到底就是：解耦。
持續(xù)交付的挑戰(zhàn)：系統(tǒng)耦合
想要把解耦說清楚，可以從一個(gè)簡單的場景——取錢來看。站到ATM機(jī)面前，把卡插進(jìn)去、輸入密碼、輸入金額、拿走現(xiàn)金，對(duì)于用戶來說是再簡單不過的事情，但其實(shí)這里面的技術(shù)非常復(fù)雜，在ATM機(jī)里需要處理很多的事情：機(jī)器系統(tǒng)控制、智能卡識(shí)別、接收用戶輸入、連接銀行系統(tǒng)、監(jiān)控等；還要把信息和數(shù)據(jù)傳輸給銀行，這個(gè)過程中又涉及到數(shù)據(jù)加密、數(shù)據(jù)完整性、監(jiān)控等；到了核心銀行系統(tǒng)后需要查找賬戶、賬務(wù)信息、進(jìn)行審計(jì)和風(fēng)險(xiǎn)控制等。
這十幾二十個(gè)系統(tǒng)意味著數(shù)十個(gè)團(tuán)隊(duì)和上百人的團(tuán)隊(duì)規(guī)模，也就是當(dāng)你把一個(gè)簡單的用戶場景從技術(shù)架構(gòu)角度去看的時(shí)候，打散成技術(shù)點(diǎn)都會(huì)變得非常復(fù)雜，這在金融業(yè)銀行業(yè)尤為嚴(yán)重。
這樣復(fù)雜的系統(tǒng)造成的結(jié)果我稱之為“漣漪效應(yīng)”。在一個(gè)平靜的水面扔下一顆小石子，會(huì)在水面蕩開一圈圈的漣漪，如果水中有幾顆樹，漣漪會(huì)撞到樹。如果把石子理解成需求，樹就是受到影響的系統(tǒng)，一個(gè)石子的場景相對(duì)簡單，嘗試一下同時(shí)扔下兩顆石子，第一顆石子扔下去蕩開的漣漪在碰撞樹的過程中會(huì)和第二顆石子蕩開的漣漪產(chǎn)生交叉反應(yīng)，繼續(xù)影響，產(chǎn)生反過來的影響，這是復(fù)雜系統(tǒng)中分析需求、進(jìn)行架構(gòu)設(shè)計(jì)時(shí)難解決的問題，就是系統(tǒng)耦合的典型場景。怎么解耦是軟件工程領(lǐng)域必須解決的問題。
首先我們需要知道軟件開發(fā)中到底是怎樣的耦合。軟件開發(fā)中有三級(jí)耦合：
代碼級(jí)耦合。所有人在同一個(gè)代碼分支上同時(shí)遷入遷出代碼，也就是大家同時(shí)開發(fā)同一個(gè)產(chǎn)品，這種情況下團(tuán)隊(duì)規(guī)模是沒有辦法超過20人的，這是一個(gè)經(jīng)驗(yàn)數(shù)字，想象一下一個(gè)超過20人的團(tuán)隊(duì)頻繁地在同一個(gè)代碼分支上進(jìn)行遷入遷出，基本上是無法工作的。
組件級(jí)耦合。不管是什么開發(fā)語言都會(huì)有包管理器的概念，比如前端可能會(huì)用到npm、bower，比如做Python會(huì)用到pip，這些包管理器所做的就是進(jìn)行組件級(jí)的解耦。
組件級(jí)解耦是指：當(dāng)我不是直接引用你的代碼，而是通過你對(duì)版本管理的包進(jìn)行引用的時(shí)候，就可以在一定程度上延遲包的變化對(duì)我的影響，比如說我可以一直引用一個(gè)1.0的包，但是這個(gè)包的開發(fā)者已經(jīng)在升級(jí)2.0，但我可以完全不理會(huì)他那條分支上的代碼變化，我就只引用1.0的包，這時(shí)兩個(gè)團(tuán)隊(duì)就被解耦了，如果這是一個(gè)產(chǎn)品的兩個(gè)部分，也被解耦了。
組件級(jí)解耦有個(gè)最大的限制條件：到達(dá)軟件上線時(shí)間點(diǎn)的時(shí)候，要統(tǒng)一同一個(gè)應(yīng)用里的所有的包的依賴。當(dāng)然我說的這是一個(gè)單體應(yīng)用，所有的代碼編譯到一起，在一個(gè)運(yùn)行時(shí)RunTime里運(yùn)行，如果是這種情況，那么包管理的隔離就只能到達(dá)產(chǎn)品發(fā)布的時(shí)間點(diǎn)，如果這幾個(gè)團(tuán)隊(duì)開發(fā)同一個(gè)產(chǎn)品，就算在開發(fā)過程中可以讓大家去引用不同版本的包，但是如果要一起上線，那么必須在上線的時(shí)間點(diǎn)統(tǒng)一大家用的所有的包的版本，不然沒辦法在同一個(gè)環(huán)境運(yùn)行。所以組件級(jí)耦合只能解決在開發(fā)測試過程中的一定程度的解耦，沒辦法幫助團(tuán)隊(duì)徹底解耦。
怎樣才能徹底解耦？就會(huì)應(yīng)用到現(xiàn)在炒得火熱的微服務(wù)，其實(shí)它所做的就是徹底的運(yùn)行環(huán)境級(jí)別的解耦。
大家經(jīng)常看到，很多的web api都會(huì)在url里面標(biāo)識(shí)不同的版本號(hào)。比如團(tuán)隊(duì)1發(fā)布了v1版本的api，并且已經(jīng)被團(tuán)隊(duì)2消費(fèi)；那么團(tuán)隊(duì)1可以繼續(xù)按照自己的步調(diào)發(fā)布v2版本的api，而團(tuán)隊(duì)2可以繼續(xù)使用團(tuán)隊(duì)1的v1版本的api；團(tuán)隊(duì)2可以在自己覺得舒服的時(shí)間點(diǎn)來升級(jí)到支持團(tuán)隊(duì)1的v2版本。這樣，團(tuán)隊(duì)1和團(tuán)隊(duì)2就徹底解耦，可以獨(dú)立完成需求，開發(fā)，測試，交付的整個(gè)過程。
這時(shí)這兩個(gè)團(tuán)隊(duì)從需求、開發(fā)、測試到交付的整個(gè)過程都是可以不去互相影響的，因?yàn)榫退氵\(yùn)行時(shí)在生產(chǎn)環(huán)境，這個(gè)服務(wù)被部署了以后，他們都可以在不同的版本間進(jìn)行切換，這樣就保證了每個(gè)團(tuán)隊(duì)都可以自主地組織自己的開發(fā)過程。
實(shí)際上它就是降低了管理單元，讓管理單元可以小到一個(gè)團(tuán)隊(duì)里邊，甚至小到幾個(gè)開發(fā)人員，這時(shí)可能看到的還是幾百人的大團(tuán)隊(duì)，其實(shí)里面是一個(gè)一個(gè)小的獨(dú)立運(yùn)作的細(xì)胞，這些細(xì)胞都可以按照自己的步調(diào)去移動(dòng)、去發(fā)布、去測試，這樣大家才能更加高效地工作。
這三級(jí)解耦的過程中，團(tuán)隊(duì)的自由度、業(yè)務(wù)能力、交付的速度、質(zhì)量的控制都會(huì)得到提升，但也會(huì)造成系統(tǒng)復(fù)雜度、運(yùn)維復(fù)雜度的提升，這是我們?cè)诓煌５剡M(jìn)行軟件開發(fā)解耦的過程中所帶來的副作用。
為解決這些副作用，這兩年軟件工程出現(xiàn)了一個(gè)明星項(xiàng)目——Docker，它到底解決什么問題？時(shí)間回溯到1995年，那時(shí)候經(jīng)常提到一個(gè)詞：web service，當(dāng)時(shí)的系統(tǒng)都是單體架構(gòu)，甚至于整個(gè)架構(gòu)里都只能用同一個(gè)開發(fā)商的同一種技術(shù)，比如C++，那就從上到下都只能用C++，沒辦法選擇其他的開發(fā)商產(chǎn)品，也沒辦法選擇另外的產(chǎn)品，原因是不同的技術(shù)棧之間的互操作性非常差，互相之間難以交互。
web service的出現(xiàn)就是為了解決不同技術(shù)棧之間的互操作性問題。因?yàn)閺囊粋�(gè)IT投資者的角度來說，他不希望自己被某個(gè)技術(shù)棧綁定，比如說你是一個(gè)技術(shù)管理人員，你肯定不希望說我只能招聘C++人，因?yàn)槲业南到y(tǒng)是C++寫的，你當(dāng)然希望市面上流行的開發(fā)語言開發(fā)的程序都能與自己的系統(tǒng)融合，甚至說我現(xiàn)在買過來一個(gè)系統(tǒng)，我希望不管這個(gè)系統(tǒng)是用什么語言開發(fā)的，都可以和我現(xiàn)在的程序一起工作。這在現(xiàn)在的你看來可能覺得不是個(gè)問題，但在那個(gè)時(shí)候是個(gè)非常大的問題，企業(yè)IT決策者、投資者沒辦法這么自由地選擇技術(shù)棧，所以才希望通過web service去進(jìn)行解耦。
這個(gè)解耦的過程一直持續(xù)到2015年，到現(xiàn)在你會(huì)發(fā)現(xiàn)不管采用什么技術(shù)棧，應(yīng)用都可以進(jìn)行互相操作，我們可以用很多方式去進(jìn)行跨進(jìn)程、跨服務(wù)、跨系統(tǒng)間的通訊，沒有任何障礙，這會(huì)給IT管理者很大的自由度，不再受制于技術(shù)棧，但也造成了另一個(gè)非常大的問題。
當(dāng)我們選擇了很多的技術(shù)棧去開發(fā)系統(tǒng)，當(dāng)這些系統(tǒng)被部署到我們的環(huán)境，你會(huì)發(fā)現(xiàn)這些系統(tǒng)是可以互相操作，從業(yè)務(wù)的角度沒有問題，但是IT運(yùn)維人員或開發(fā)人員會(huì)發(fā)現(xiàn)已經(jīng)陷入一個(gè)非常復(fù)雜的N*N的問題矩陣。
以前我們只需要處理同一個(gè)技術(shù)棧的同一類型應(yīng)用的開發(fā)、測試、部署，而現(xiàn)在我們需要同時(shí)處理很多不同的技術(shù)棧的開發(fā)、測試、部署。如果你用過一些開源的組件就會(huì)發(fā)現(xiàn)，當(dāng)你在一個(gè)項(xiàng)目里開始引用開源組件的時(shí)候，可能你的主程序是用Java開發(fā)的、服務(wù)是另一種語言開發(fā)的、消息隊(duì)列又是另一種語言開發(fā)的，這些程序都需要被部署到IT的運(yùn)維環(huán)境才能一起工作。
Docker就是用來解決這個(gè)問題的，它可以幫助你使用同樣的方式來運(yùn)行不同技術(shù)棧的不同應(yīng)用，這些不同應(yīng)用又可以在統(tǒng)一的硬件和操作系統(tǒng)環(huán)境下被運(yùn)行、被部署、被測試、被發(fā)布。解決了我們?cè)诓煌５慕怦钸^程中帶來的副作用：系統(tǒng)架構(gòu)復(fù)雜度和系統(tǒng)運(yùn)維復(fù)雜度提升的問題，解決了N*N矩陣的難題。
因此，在進(jìn)行軟件研發(fā)過程改進(jìn)或效率提升的過程中，容器技術(shù)對(duì)于我們來說是非常有價(jià)值的。
Docker對(duì)DevOps的價(jià)值有很多，如圖所示，最重要的我認(rèn)為是：為不同職能/技能的人員各司其職提供了條件。
我們有很多自動(dòng)化部署發(fā)布的工具，也提出來很多解決辦法，但是這些解決辦法其實(shí)都沒有Docker解決得順暢，原因在于所有這些工具的解決方式都是在采取一個(gè)更復(fù)雜的方式來解決復(fù)雜問題，試圖用復(fù)雜適配復(fù)雜，Docker是用簡單來解決復(fù)雜問題，所以它解決問題的效率會(huì)很高。
如圖是來自Google的一個(gè)統(tǒng)計(jì)，Docker和DevOps的發(fā)展趨勢非常匹配，DevOps效率提升的過程就是在不停解耦，解耦到一定程度后，如果不解決運(yùn)維復(fù)雜度，解耦過程中產(chǎn)生的效率提升都會(huì)被運(yùn)維復(fù)雜度吃掉，最終達(dá)不到效率提升的目的。
DevOps實(shí)施落地的總體策略
DevOps三步工作法：建立全局觀、建立反饋、持續(xù)改進(jìn)。
這三步從可操作性的角度需要做什么？從建立全局觀到建立反饋的過程中，要做的是：
首先要建立端到端的軟件全生命周期管理的體系，這個(gè)體系就如軟件研發(fā)管理過程全景圖所示；
接下來把圖中所有的點(diǎn)適配到自己的環(huán)境中，識(shí)別出對(duì)于我來說到底是什么，同時(shí)對(duì)這個(gè)體系的管理能力必須通過一些工具來實(shí)現(xiàn)，這個(gè)過程就是識(shí)別管理單元；
識(shí)別了管理單元之后要做的下一步是減小管理粒度；
減少管理粒度的結(jié)果就是建立了流動(dòng)性。對(duì)于看板有了解的人知道，看板最重要的原則是拉動(dòng)原則，拉動(dòng)原則的目的是讓進(jìn)入到研發(fā)環(huán)節(jié)的內(nèi)容盡快出去，所以要做的就是建立流動(dòng)性。建立看板的第一步是建立管理流程可視化，這就是全局觀，看到整個(gè)過程是什么、問題在哪里，做所有這些事情的目的就是讓進(jìn)入到研發(fā)環(huán)節(jié)的內(nèi)容盡快出去，怎么才能盡快出去？很簡單，把這個(gè)東西變小就可以更快地流動(dòng)。
有了正向的流動(dòng)之后，下一步要知道流動(dòng)的東西是好是壞，這就是在建立反饋，而配置管理、持續(xù)解耦（包括持續(xù)集成、CI/CD）真正在做什么？持續(xù)交付真正在做的也是建立反饋，從具體落地的策略來說，實(shí)際上是在解耦，但解耦的目的是在環(huán)節(jié)中不停地建立回答“這個(gè)東西到底做的好不好？”、“可以不可以繼續(xù)往下走？”等問題的反饋。
有了這些反饋以后，就已經(jīng)形成了整個(gè)研發(fā)過程的閉環(huán)，現(xiàn)在要做的就是讓這個(gè)閉環(huán)不停地流動(dòng)起來，這就得靠人。所以持續(xù)改進(jìn)最后一步的關(guān)鍵是：人+流程。
我們的研發(fā)過程改進(jìn)永遠(yuǎn)不是一個(gè)項(xiàng)目，而只是一個(gè)起點(diǎn)。開始做這件事以后就沒有盡頭，我?guī)湍憬⑵疬@樣一個(gè)體系以后，你要做的是不聽地改進(jìn)這個(gè)體系，怎么能讓這件事情落地，要建立起這樣一個(gè)自我驅(qū)動(dòng)的改進(jìn)過程。
核心關(guān)注：拓步ERP系統(tǒng)平臺(tái)是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊(yùn)涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務(wù)管理理念，功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴品牌。
轉(zhuǎn)載請(qǐng)注明出處：拓步ERP資訊網(wǎng)http://m.lukmueng.com/
本文標(biāo)題：DevOps實(shí)施落地的2大法寶：粒度&解耦
本文網(wǎng)址：http://m.lukmueng.com/html/solutions/14019321047.html
相關(guān)文章
