一年前的高管們決定開始一個新項目——創(chuàng)建一款旗艦產(chǎn)品，作為解決方案組合的一部分。高管們對產(chǎn)品開發(fā)方式提出了挑戰(zhàn)，并希望探索快速推出產(chǎn)品的新方法。經(jīng)過內(nèi)部討論，決定嘗試一種開發(fā)產(chǎn)品的新方法。決定與 DevOps 團(tuán)隊合作。在本文中的 SCRUM 大師 Peter Borg 解釋了過渡到 DevOps 文化的必要步驟和要克服的挑戰(zhàn)。

過渡到 DevOps 的步驟

從歷史上看，該公司在傳統(tǒng)的敏捷設(shè)置中遇到了一些問題，這導(dǎo)致了項目交付的延遲。如果 SCRUM 團(tuán)隊正在全速運(yùn)行以實(shí)現(xiàn)目標(biāo)，但基礎(chǔ)設(shè)施尚未準(zhǔn)備好，則交付會延遲。部門隔離可能會造成支持團(tuán)隊可能沒有資源來支持 SCRUM 團(tuán)隊的情況。僅一個部門并不能交付軟件產(chǎn)品，而這正是我們希望通過過渡到 DevOps 來改變的。

1. 創(chuàng)建自給自足的團(tuán)隊

為了啟動新的 DevOps 文化變革，我們組建了一個新團(tuán)隊，其職位描述對公司來說是獨(dú)一無二的。我們從全棧開發(fā)人員轉(zhuǎn)向 DevOps 軟件工程師，從系統(tǒng)管理員轉(zhuǎn)向站點(diǎn)可靠性工程師 (SRE)。

通過這樣做，我們能夠組建一個自給自足的團(tuán)隊，其目標(biāo)是交付手頭的項目。除了在新技術(shù)堆棧的特定方面擁有專業(yè)知識外，雇用合適的人也至關(guān)重要，他們可以在不依賴團(tuán)隊外部人員的情況下交付產(chǎn)品。

SRE 的任務(wù)是對基礎(chǔ)架構(gòu)進(jìn)行編碼，軟件工程師負(fù)責(zé)開發(fā)應(yīng)用程序，QA 工程師負(fù)責(zé)建立自動化測試框架，軟件和系統(tǒng)架構(gòu)師負(fù)責(zé)設(shè)計解決方案。

盡管人們根據(jù)他們的知識領(lǐng)域被指定用于特定任務(wù)，但我們促進(jìn)了知識的交叉授粉。SRE 為軟件代碼做出了貢獻(xiàn)，軟件工程師參與了我們的 基礎(chǔ)設(shè)施即代碼 (IaC)，QA 參與了我們的測試驅(qū)動開發(fā) (TDD) 策略和持續(xù)集成 (CI) 管道，架構(gòu)師幫助開發(fā)和故障排除。

2. 擁抱測試驅(qū)動開發(fā)

每個人都討厭大爆炸式發(fā)布，這會導(dǎo)致發(fā)現(xiàn)后期集成問題、重構(gòu)復(fù)雜解決方案以及可能的產(chǎn)品愿景分歧等問題。

為了不陷入這些陷阱，我們選擇了 測試驅(qū)動開發(fā) (TDD)。TDD 使我們能夠分解、實(shí)施、測試、審查和擴(kuò)展復(fù)雜的解決方案，同時在我們構(gòu)建產(chǎn)品的過程中始終從產(chǎn)品負(fù)責(zé)人 (PO) 那里獲得反饋。這種迭代方法和反饋循環(huán)使我們能夠在建立堅實(shí)的基礎(chǔ)后繼續(xù)改進(jìn)功能，這是敏捷宣言中的第一條原則（Kent Beck 等人，2001）。采用 DevOps 方法時要牢記的最重要的考慮因素是確保團(tuán)隊不會在情感上將自己與他們的實(shí)施聯(lián)系在一起，因為它可能有一天會在那里，但第二天就會消失。

通過選擇 TDD 方法，我們用非過度設(shè)計的解決方案實(shí)現(xiàn)了復(fù)雜的問題。TDD 是一種迭代方法來開發(fā)功能，使重構(gòu)更容易實(shí)現(xiàn)，同時還增加了解決方案的質(zhì)量。“從某個地方開始，從經(jīng)驗中學(xué)習(xí)”（John Shook。2008 年。管理學(xué)習(xí)：使用 A3 管理流程解決問題、獲得共識、導(dǎo)師和領(lǐng)導(dǎo)）。

3. 推動 DevOps 文化變革

引入文化變革不僅很難。這令人筋疲力盡，令人沮喪和士氣低落。在多結(jié)構(gòu)組織中推動不同的思維方式比在初創(chuàng)公司中建立公司文化要困難得多。

這就是為什么我相信通過以同樣的方式對待他們可以實(shí)現(xiàn)改變。如果您試圖在一家已經(jīng)建立的公司內(nèi)構(gòu)建不同的實(shí)施方法，那么只有創(chuàng)建一個小型組織生態(tài)系統(tǒng)才能實(shí)現(xiàn)。形成公司在實(shí)施新項目時將其視為初創(chuàng)公司的團(tuán)隊結(jié)構(gòu)。

您將面臨限制，例如“這不是我們做事的方式”或“我們已經(jīng)為此提供了不同的工具”。如果你聽到這些陳述，你就走在了正確的軌道上。提出文化變革時，首先需要做的就是質(zhì)疑公司的流程和工具。考慮現(xiàn)有的工具和方法是否完全相關(guān)。

在我們的案例中，通過質(zhì)疑，我們能夠利用 云原生技術(shù) ，而不是公司認(rèn)為“標(biāo)準(zhǔn)”的系統(tǒng)。在推動 DevOps 變革時，您不會得到所有人的支持。然而，獲得高層管理人員的支持至關(guān)重要。這將有助于激勵公司內(nèi)部不太愿意改變的人，因為愿景得到了更高管理層的支持。

4. 測試你的進(jìn)步

在各個 DevOps 過渡階段測試您的工作進(jìn)度。從測試速度開始。您希望敏捷并快速實(shí)施解決方案。通過將“啟動”項目與其他正在進(jìn)行或歷史的解決方案進(jìn)行比較，您應(yīng)該能夠了解 DevOps 團(tuán)隊是否交付得更快。衡量團(tuán)隊適應(yīng)變化的能力也很重要。如果反饋回路的變化結(jié)果是對系統(tǒng)的大修，那么在設(shè)計階段就出現(xiàn)了問題。

其次，通過分析團(tuán)隊的士氣來衡量成功。當(dāng)引入新的實(shí)施適應(yīng)時，人們應(yīng)該感到興奮和積極。你會意識到你已經(jīng)通過無意中聽到團(tuán)隊中的某個人與團(tuán)隊外部的某個人交談，解釋我們?nèi)绾问褂眯碌男膽B(tài)或技術(shù)解決問題，這對公司來說是新的。這將激發(fā)其他團(tuán)隊的興趣，并且在這一點(diǎn)上，您會意識到文化變革正在整個組織中蔓延。考慮一下成功的真正衡量標(biāo)準(zhǔn)——新的 DevOps 方法受到關(guān)注。其他團(tuán)隊成員想嘗試不同的事情，并就如何使用 DevOps 解決方案向您尋求建議。

5. 毫不妥協(xié)

當(dāng)我擔(dān)任 SCRUM Master 的角色時，我知道我必須盡快交付新產(chǎn)品和 DevOps 文化變革。必須在整個產(chǎn)品開發(fā)階段保持這兩個目標(biāo)一致。面對此類挑戰(zhàn)時，高管的認(rèn)同和信任可以成就或破壞文化變革。有時，管理層可能不會關(guān)心項目是如何實(shí)現(xiàn)的，只要它已經(jīng)交付——即使我們不得不使用過時的技術(shù)。

這讓我想到了下一點(diǎn)，從一張空白畫布開始。不要試圖將當(dāng)前的公司標(biāo)準(zhǔn)融入到 DevOps 開發(fā)軟件的方式中。從頭開始并保持精益解決方案。讓團(tuán)隊研究解決問題的最佳工具。如果他們確定了公司已經(jīng)在使用的解決方案，那就太好了。如果他們不這樣做，那么將新工具展示給支持當(dāng)前解決方案的任何人，以獲得他們的支持來改變它。確保團(tuán)隊牢記沒有什么是一成不變的，工具可以改變，有人可能有更好的想法，需求也可以改變；它是迭代的。

6. 將其他團(tuán)隊過渡到 DevOps

一旦這個微型組織內(nèi)的 DevOps 文化變革開始結(jié)出碩果，您就需要考慮下一步—— 增長。如何讓更多團(tuán)隊過渡到 DevOps？

豐田生產(chǎn)系統(tǒng) (TPS) 理念（Toshiko Narusawa 和 John Shook. 2009. Kaizen Express）似乎符合 Spotify 的敏捷擴(kuò)展模型。保持一個盡可能扁平和獨(dú)立的組織結(jié)構(gòu)是關(guān)鍵。這賦予了團(tuán)隊權(quán)力，使他們對自己的成功和失敗更加負(fù)責(zé)。與其組建由相同技能人員組成的部門，不如設(shè)立“分會”，讓這些成員組成 SCRUM 團(tuán)隊的一部分，并鼓勵他們相互聯(lián)系以幫助解決問題。促進(jìn)持續(xù)的溝通保持團(tuán)隊內(nèi)的項目優(yōu)先級。

設(shè)置知識共享活動，以告知其他部門團(tuán)隊已做出的任何技術(shù)決策。知識共享將有助于推動整個公司向 DevOps 的過渡，并在整個組織中獲得支持。在過去的一年里，我們學(xué)到了很多東西，并且我們一直在尋找通過不同迭代來改進(jìn)我們的流程和結(jié)構(gòu)的方法。保持精益和敏捷的心態(tài)并確保產(chǎn)品是成功的故事將是維持的最重要因素。

關(guān)于切換到 Devops 的最終建議

對于任何過渡到 DevOps 的人來說，最后也是最關(guān)鍵的一點(diǎn)是永遠(yuǎn)不要放棄。有時你會認(rèn)為擁抱 DevOps 文化很難實(shí)現(xiàn)，但如果你有來自團(tuán)隊、管理層和高管的正確支持系統(tǒng)，你就會成功。有一天，來自另一個團(tuán)隊的人會要求開會，想知道你是如何實(shí)施某事的。那時你會意識到公司正走在接受 DevOps 文化的正確軌道上。分階段將理念從一個團(tuán)隊傳播到另一個團(tuán)隊，并花時間將整個組織轉(zhuǎn)移到 DevOps。