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

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

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

[[273415]]

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

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

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

一、敏捷絕不僅僅是Scrum

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

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

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

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

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

Product Owner 和Service Owner

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

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

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

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

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

持續(xù)交付實踐并不能直接解決業(yè)務(wù)部門和開發(fā)團隊之間的溝通問題。如果業(yè)務(wù)部門設(shè)定了一個為期一年的預(yù)算驅(qū)動計劃，那么產(chǎn)品交付團隊每次交付產(chǎn)品后都需要等待數(shù)月才能得到業(yè)務(wù)部門給的反饋。而這些反饋通常都是一些影響后續(xù)工作的步驟性功能，像取消項目或者更糟糕的是需要擴充項目團隊(因為大量涌入新人會影響團隊已有的穩(wěn)定性)。

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

這點對于有遺留代碼庫的團隊來說尤為重要，因為遺留代碼庫可能沒有自動化測試或適合頻繁部署的設(shè)計。在一個遺留環(huán)境中，持續(xù)交付轉(zhuǎn)換可能需要數(shù)年的時間。因此，證明產(chǎn)品的商業(yè)價值就顯得尤為重要。

三種方法

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

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

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

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

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

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

DevOps是敏捷在軟件開發(fā)團隊之外的應(yīng)用

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

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

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

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

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

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