DevOps是敏捷在軟件開(kāi)發(fā)團(tuán)隊(duì)的另一應(yīng)用。那么相比之下，哪個(gè)更勝一籌?

一邊，有業(yè)界認(rèn)可的scrum master，它的朋友極限編程者，以及由其衍生的 LeSS、SAFe、DAD等，是敏捷。

另一邊，有精益文化機(jī)器，用代碼持續(xù)交付其基礎(chǔ)架構(gòu)，它的名字左邊是開(kāi)發(fā)，右邊是運(yùn)維，合起來(lái)就是DevOps。

[[273415]]

雖然我已盡我所能在普及這兩個(gè)概念，但人們關(guān)于敏捷和DevOps的爭(zhēng)論依然讓它們聽(tīng)起來(lái)完全不同。更糟糕的是，盡管他們都已經(jīng)有了各自的行業(yè)術(shù)語(yǔ)和口號(hào)，但兩者的概念還是沒(méi)辦法準(zhǔn)確定義。鑒于敏捷誕生早于DevOps ，所以它的定義也相對(duì)清晰一些，但DevOps五花八門(mén)的定義仍然讓很多人都很困惑。而正是因?yàn)槎叨既狈?zhǔn)確的定義，所以導(dǎo)致人們經(jīng)常會(huì)有一些誤解。

很多人認(rèn)為敏捷等于scrum，DevOps等于持續(xù)交付。過(guò)度簡(jiǎn)化的理解讓敏捷和DevOps之間形成了不必要的對(duì)峙，但最終你會(huì)驚訝地發(fā)現(xiàn)二者其實(shí)是非常好的朋友!

毫無(wú)疑問(wèn)DevOps和敏捷之間的聯(lián)系由來(lái)已久。在2008敏捷大會(huì)上，Patrick DuBois和Andrew Clay Schafer嘗試建立二者之間的關(guān)系并提出“敏捷架構(gòu)”這一概念，這時(shí)，敏捷與DevOps之間的關(guān)系就已初現(xiàn)端倪。盡管Patrick后來(lái)提出了“DevOps”一詞，但敏捷大會(huì)依然被追溯為DevOps的起點(diǎn)。所以我們不妨透過(guò)Scrum和持續(xù)交付的表面，深入了解二者的歷史，來(lái)思考一下敏捷和DevOps之間還存在哪些關(guān)聯(lián)。

一、敏捷絕不僅僅是Scrum

某些團(tuán)隊(duì)中，scrum讓團(tuán)隊(duì)工作介于一成不變、苦苦掙扎和量產(chǎn)、高回報(bào)之間。還有一些團(tuán)隊(duì)，scrum用客觀和聚焦代替主觀和過(guò)度承諾。我們也可以把它視為一種教條。當(dāng)業(yè)務(wù)收到限制或工作本身需要做出改變的時(shí)候，敏捷團(tuán)隊(duì)將利用scrum的基本原則，審視自身的工作并做出更有效的調(diào)整。尤其是當(dāng)scrum應(yīng)用于軟件開(kāi)發(fā)環(huán)境之外的業(yè)務(wù)時(shí)，這點(diǎn)尤為重要。

提前規(guī)劃計(jì)劃外的工作

在DevOps社區(qū)，有敏捷經(jīng)驗(yàn)的人都覺(jué)得scrum能夠有效追蹤計(jì)劃中的工作。一些正在運(yùn)行中的工作可以被計(jì)劃：如發(fā)布一個(gè)重大系統(tǒng)變更、切換數(shù)據(jù)中心或系統(tǒng)升級(jí)等。但在運(yùn)行中大多數(shù)事情是沒(méi)辦法計(jì)劃的：如性能到達(dá)峰值、系統(tǒng)中斷或安全問(wèn)題等。這些突發(fā)事件都需要快速做出反應(yīng)。沒(méi)時(shí)間等到把這些事項(xiàng)在backlog中確定優(yōu)先級(jí)后再做或放到下個(gè)sprint規(guī)劃會(huì)議中處理。正因如此，很多團(tuán)隊(duì)開(kāi)始慢慢接受DevOps思想，Scrum之外再引入Kanban。這樣使得團(tuán)隊(duì)可以同時(shí)追蹤兩種類(lèi)型的工作，幫助他們理解兩者之間的聯(lián)系?；蛘撸麄儾扇×艘环N綜合方法，叫做Scrumban 或 Kanplan (也就是有backlog的看板)。

在很大程度上，scrum得以廣泛應(yīng)用的關(guān)鍵可能在于它不對(duì)技術(shù)方法設(shè)限。Scrum作為輕量級(jí)管理方法，往往能為團(tuán)隊(duì)帶來(lái)巨大變化。之前，可能會(huì)有來(lái)自多個(gè)master的優(yōu)先事項(xiàng)互相競(jìng)爭(zhēng)，但在scrum中，backlog中只會(huì)存在一組優(yōu)先事項(xiàng)。之前，團(tuán)隊(duì)中可能會(huì)存在同時(shí)推進(jìn)很多工作的情況，而現(xiàn)在取而代之的是一個(gè)在限定時(shí)間內(nèi)可以完成的工作計(jì)劃。綜合來(lái)看，這些都可以將團(tuán)隊(duì)的生產(chǎn)率帶到一個(gè)新的水平。然而，團(tuán)隊(duì)可能會(huì)因技術(shù)實(shí)踐的缺乏而受到限制，如代碼審查、自動(dòng)化驗(yàn)收測(cè)試、持續(xù)集成。

其他敏捷方法如極限編程，也對(duì)技術(shù)如何使團(tuán)隊(duì)保持可持續(xù)交付節(jié)奏并向管理層和利益相關(guān)者提供透明度和可見(jiàn)性提出了明確要求。一些Scrum團(tuán)隊(duì)傾向于將研發(fā)任務(wù)放在backlog中。雖然這在scrum的指導(dǎo)下適應(yīng)得很好，但很快就會(huì)遇到Product Owner對(duì)產(chǎn)品功能的偏向性問(wèn)題。除非Product Owner的技術(shù)能力很強(qiáng)，否則TA可能無(wú)法評(píng)估技術(shù)的成本或收益。尤其是當(dāng)技術(shù)任務(wù)延伸到運(yùn)維、可靠性支持、性能、安全性等方面時(shí)，對(duì)Product Owner來(lái)說(shuō)更加困難。

Product Owner 和Service Owner

在Worktile，我們認(rèn)識(shí)到，為我們運(yùn)營(yíng)的產(chǎn)品設(shè)置兩個(gè)不同角色很有必要。Product Owner善于理解用戶(hù)的功能性需求，但可能并不擅長(zhǎng)權(quán)衡產(chǎn)品功能與性能、可靠性和安全性等非功能性功能之間的優(yōu)先級(jí)。因此，一些SaaS產(chǎn)品也配備了Service Owner角色，負(fù)責(zé)確定前述非功能性功能的優(yōu)先級(jí)。盡管兩個(gè)角色經(jīng)常需要討價(jià)還價(jià)，但大部分情況下，獨(dú)立的團(tuán)隊(duì)都可以自行完成這兩個(gè)角色的任務(wù)。雖然這并不是“強(qiáng)化反饋”的唯一方法，但確實(shí)能夠克服Product Owner對(duì)產(chǎn)品功能中比較常見(jiàn)的偏見(jiàn)問(wèn)題。但設(shè)置‘兩個(gè)Owner’并非實(shí)現(xiàn)DevOps的唯一途徑。重要的是將非功能性特征理解為“功能”，并將它們像功能性的用戶(hù)故事一樣，進(jìn)行規(guī)劃和優(yōu)先級(jí)排序。

• 在DevOps成為主流前，不能確定scrum自然發(fā)展的結(jié)果一定是DevOps。

敏捷方法中，Scrum有一個(gè)內(nèi)在的“過(guò)程改進(jìn)”機(jī)制，叫做回顧會(huì)議。因此，我們有理由相信一些scrum團(tuán)隊(duì)會(huì)想用DevOps作為靈感來(lái)源，用scrum回顧會(huì)議作為向DevOps方向調(diào)整的契機(jī)。然而，事實(shí)讓我們意識(shí)到大多數(shù)團(tuán)隊(duì)需要注入外部思想。在DevOps成為主流前(哪怕成為學(xué)校必學(xué)內(nèi)容)，我們不能確定scrum自然發(fā)展的結(jié)果一定是DevOps。團(tuán)隊(duì)到底是有敏捷教練還是DevOps教練參與并不重要，只要他能給團(tuán)隊(duì)帶來(lái)在構(gòu)建、測(cè)試、部署等方面的自動(dòng)化經(jīng)驗(yàn)即可。

二、DevOps也不僅限于持續(xù)交付

如果應(yīng)用得當(dāng)，持續(xù)交付的規(guī)則可以有效限制在制品數(shù)量，而部署的自動(dòng)化有助于打破工作局限。通過(guò)這樣的方式，持續(xù)交付讓軟件開(kāi)發(fā)團(tuán)隊(duì)頻繁交付更高質(zhì)量的產(chǎn)品，而不必在二者之間抉擇。然而，正如僅專(zhuān)注于scrum的團(tuán)隊(duì)可能會(huì)忽視更廣泛的敏捷環(huán)境那樣，僅專(zhuān)注于持續(xù)交付的團(tuán)隊(duì)也會(huì)錯(cuò)過(guò)更廣泛的DevOps環(huán)境。

持續(xù)交付實(shí)踐并不能直接解決業(yè)務(wù)部門(mén)和開(kāi)發(fā)團(tuán)隊(duì)之間的溝通問(wèn)題。如果業(yè)務(wù)部門(mén)設(shè)定了一個(gè)為期一年的預(yù)算驅(qū)動(dòng)計(jì)劃，那么產(chǎn)品交付團(tuán)隊(duì)每次交付產(chǎn)品后都需要等待數(shù)月才能得到業(yè)務(wù)部門(mén)給的反饋。而這些反饋通常都是一些影響后續(xù)工作的步驟性功能，像取消項(xiàng)目或者更糟糕的是需要擴(kuò)充項(xiàng)目團(tuán)隊(duì)(因?yàn)榇罅坑咳胄氯藭?huì)影響團(tuán)隊(duì)已有的穩(wěn)定性)。

敏捷流暢度模型將“價(jià)值聚焦”視為流暢度的第一層級(jí)，即團(tuán)隊(duì)需要注重透明度和一致性。如果價(jià)值不聚焦，持續(xù)交付很容易陷入技術(shù)改進(jìn)的無(wú)限死循環(huán)而無(wú)法向業(yè)務(wù)交付可觀的價(jià)值。團(tuán)隊(duì)可能擅長(zhǎng)快速高質(zhì)量的交付，但就產(chǎn)品本身而言，可能對(duì)終端用戶(hù)或者企業(yè)來(lái)說(shuō)幾乎沒(méi)有價(jià)值。即使很多用戶(hù)給出了較好的評(píng)價(jià)，但從較大的業(yè)務(wù)組合層面來(lái)看可能就會(huì)評(píng)估為低價(jià)值。因此，沒(méi)有價(jià)值聚焦這一重要流暢度，團(tuán)隊(duì)很難在技術(shù)和功能之間權(quán)衡取舍。

這點(diǎn)對(duì)于有遺留代碼庫(kù)的團(tuán)隊(duì)來(lái)說(shuō)尤為重要，因?yàn)檫z留代碼庫(kù)可能沒(méi)有自動(dòng)化測(cè)試或適合頻繁部署的設(shè)計(jì)。在一個(gè)遺留環(huán)境中，持續(xù)交付轉(zhuǎn)換可能需要數(shù)年的時(shí)間。因此，證明產(chǎn)品的商業(yè)價(jià)值就顯得尤為重要。

三種方法

DevOps不僅僅是自動(dòng)化部署流水線。換句話說(shuō)，DevOps方法要求“運(yùn)維人員(Ops)能夠像開(kāi)發(fā)人員(Devs)那樣思考，而開(kāi)發(fā)人員(Devs)也要像運(yùn)維人員(Ops)那樣思考。” 以下是這一觀點(diǎn)的進(jìn)一步闡述以及可作為DevOps原則的三種方法：

• 第一種：系統(tǒng)思維 強(qiáng)調(diào)整個(gè)系統(tǒng)的性能，而不是特定的工作孤島或部門(mén)的性能——這個(gè)系統(tǒng)可以大到涵蓋整個(gè)業(yè)務(wù)部門(mén)，小到僅包括單個(gè)工作項(xiàng)。
• 第二種：擴(kuò)大反饋循環(huán) 創(chuàng)建全流程的反饋循環(huán)。幾乎所有過(guò)程改進(jìn)計(jì)劃的目的都是為了縮短并強(qiáng)化反饋循環(huán)，以確?？梢圆粩噙M(jìn)行必要的修正。
• 第三種：不斷實(shí)踐和學(xué)習(xí)的文化 塑造一種聚焦在這兩件事上的文化：不斷實(shí)踐、勇于冒險(xiǎn)并從失敗中學(xué)習(xí)經(jīng)驗(yàn);要明白重復(fù)和實(shí)踐是熟練掌握的先決條件。

持續(xù)交付側(cè)重于第一種方法： 即實(shí)現(xiàn)從開(kāi)發(fā)到運(yùn)維的自動(dòng)化流程。自動(dòng)化在加快系統(tǒng)部署上的作用非常明顯，但系統(tǒng)思維絕不止于自動(dòng)化。

第二種方法的突出特點(diǎn)是實(shí)踐， 即“開(kāi)發(fā)人員也要隨身攜帶傳呼機(jī)”。雖然開(kāi)發(fā)人員不一定真的要隨身攜帶傳呼機(jī)做到隨叫隨到，但他們也需要積極參與到運(yùn)維工作中。這樣能讓開(kāi)發(fā)人員了解到他們開(kāi)發(fā)過(guò)程中所做選擇帶來(lái)的后續(xù)影響。例如，這樣做能讓開(kāi)發(fā)人員將自己的日志消息存放到更好的位置讓它們發(fā)揮更大的作用。開(kāi)發(fā)人員不僅僅要了解運(yùn)維工作，還要結(jié)合自己對(duì)系統(tǒng)的理解做一些故障排除的工作，這樣可以更快地找到并實(shí)施解決方案。

第三種方法強(qiáng)調(diào)在整個(gè)系統(tǒng)中進(jìn)行增量實(shí)驗(yàn)，而不僅僅是應(yīng)用程序在流水線中移動(dòng)的變化。 換句話說(shuō)，看出自動(dòng)化所需的時(shí)間并用日益強(qiáng)大的基礎(chǔ)設(shè)施來(lái)不斷改進(jìn)它相對(duì)來(lái)說(shuō)是比較容易的。而要清楚的知道角色或企業(yè)之間的交接如何導(dǎo)致延期是比較困難的。這意味著團(tuán)隊(duì)要“檢查和調(diào)整”整個(gè)交付工作流，尋找可以提升人員協(xié)作效率的點(diǎn)。對(duì)于這個(gè)問(wèn)題，持續(xù)交付要求團(tuán)隊(duì)養(yǎng)成不斷適應(yīng)和改進(jìn)的習(xí)慣。如果團(tuán)隊(duì)從來(lái)不去思考如何變得更高效，并付諸行動(dòng)去調(diào)整和改善，那么持續(xù)交付也無(wú)法持續(xù)發(fā)展和完善。團(tuán)隊(duì)要相信自己有能力解決自己的問(wèn)題。

在scrum中，每次回顧會(huì)議都是一次改進(jìn)實(shí)踐和工具的機(jī)會(huì)。但如果團(tuán)隊(duì)沒(méi)有抓住這些機(jī)會(huì)解決短期和長(zhǎng)期的技術(shù)問(wèn)題，他們就無(wú)異于坐等Product Owner將持續(xù)交付任務(wù)放到他們的backlog中，而事實(shí)上，Product Owner永遠(yuǎn)不會(huì)這么做。

DevOps是敏捷在軟件開(kāi)發(fā)團(tuán)隊(duì)之外的應(yīng)用

Scrum主要遵循“欣然面對(duì)需求變化，哪怕變更出現(xiàn)在開(kāi)發(fā)后期。敏捷過(guò)程正是利用變化來(lái)幫助客戶(hù)取得競(jìng)爭(zhēng)優(yōu)勢(shì)”這一敏捷原則。

而持續(xù)交付遵循的敏捷原則是：“我們的首要任務(wù)是通過(guò)盡早、持續(xù)地交付有價(jià)值的軟件，來(lái)滿(mǎn)足客戶(hù)的需求”。

這意味著敏捷更強(qiáng)調(diào)輸入和輸出的變化，而不是每日站會(huì)和sprint規(guī)劃會(huì)等儀式。事實(shí)上，《敏捷宣言》中還有另外10條原則。我們應(yīng)該將它們視為一個(gè)整體，而不是從中選擇某些原則。因?yàn)檫@些原則合起來(lái)代表的是敏捷和DevOps對(duì)變更的態(tài)度。

• DevOps旨在將敏捷關(guān)于變更的態(tài)度應(yīng)用到新的領(lǐng)域：IT運(yùn)維。

這些人一直在運(yùn)行對(duì)于企業(yè)來(lái)說(shuō)非常重要但同時(shí)又非常脆弱的系統(tǒng)。也正是因?yàn)樗闹匾?，所以也最迫切需要得以改進(jìn)。因此，這里敏捷強(qiáng)調(diào)的變化并不是“為了改變而改變”。是為了讓開(kāi)發(fā)對(duì)其變更質(zhì)量負(fù)責(zé)，同時(shí)提高整體交付商業(yè)價(jià)值。而這種對(duì)商業(yè)價(jià)值的關(guān)注是敏捷和DevOps的另一個(gè)共通點(diǎn)。

最后，敏捷和DevOps本身并不是業(yè)務(wù)指標(biāo)。它們都是可以激勵(lì)組織用更好的方法實(shí)現(xiàn)目標(biāo)的企業(yè)文化。將敏捷和DevOps結(jié)合起來(lái)使用能取得更好的效果。而避免這兩種文化發(fā)生沖突的訣竅就是要理解構(gòu)成它們的更深層次的價(jià)值觀和原則。武斷而狹隘的定義會(huì)禁錮思維。相信看完本文，你已經(jīng)知道敏捷不僅限于scrum，而DevOps也不僅限于持續(xù)交付。那么接下來(lái)，你就可以嘗試強(qiáng)大的Agile + DevOps組合了。