作者 | Christopher Lee&Sean D. Mack
譯者 | 溫馨
如果您曾經對敏捷或DevOps的歷史、結構、原則或好處有過疑問，那麼您將在這篇文裏找到答案，本文被拆分兩篇，上篇主要介紹敏捷和DevOps的歷史、差異和好處。
敏捷和DevOps從表面上看可能是不同的，但如果關注他們的目標，會發現它們其實非常相似。兩者的目標都是更快地爲客戶創造價值並更快地改變市場需求。DevOps採用敏捷中介紹的原則，並將其擴展使用到代碼以外的部署和運維操作中。
敏捷和DevOps的目標是一致的，因此在實踐過程中會發現它們有所重疊。在許多方面，DevOps和敏捷的交叉關係到協作文化以及從這種文化中產生的現代技術實踐和過程。連續測試和小批量生產等過程中更容易看到了這一點，在使工作儘量可見化的過程中，公開工作流和系統遙測，有助於確保向客戶快速交付工作產品，能加速向客戶傳遞價值。
敏捷和DevOps專注於提供客戶價值，這不是爲了提供更多功能，而是爲了儘可能快速有效地向最終客戶提供正確的增值功能。DevOps使用敏捷的概念並對其進行了擴展延伸，因此您可以通過實現DevOps實踐來增強敏捷性。
什麼是DevOps？什麼是敏捷？
在開始研究DevOps和敏捷之間的關係之前，首先要對這些術語的含義有一個共同的理解。雖然有許多定義，但它們可以從根本上理解爲一套原則，從中可以衍生出工程師文化和實踐。
敏捷的存在時間比DevOps長，定義也更爲成熟。首次定義於2001年2月的《敏捷宣言》，該宣言包含了以下幾條定義：
- 個人和交互重於流程和工具
- 工作軟件重於公共文檔
- 與客戶協作重於合同談判
- 響應變化勝過遵循計劃
儘管已經有了對DevOps宣言的嘗試，但還沒有哪一個宣言能夠獲得敏捷宣言所具有的那種廣泛接受度。作爲一個一般概念，DevOps重視協作，特別關注開發和運營團隊之間的交叉功能以及這兩個方面的責任。敏捷教練Anthony Gardiner說，“我測試，我編碼，我部署，我在週末起牀並修復錯誤——我讓我的代碼更好，所以我不必在週末起牀。”DevOps可以被認爲是一種爲客戶提供價值的方法，專注於協作和小批量，聚焦持續集成，自動化，持續測試和持續交付。
雖然沒有單一的定義，Gene Kim、Kevin Behr和George Spafford在他們的開創性書籍《鳳凰計劃》中介紹了DevOps的“三種方法”。這三種方法是許多DevOps實踐的核心。
Kim後來在《DevOps Handbook》中對這些方法進行了擴展，他與Jez Humble和Patrick Debois合著了這本手冊。
這三種方法包括：
| 方法一 | 系統思維 | 強調整個系統的性能，而不是特定工作或部門的性能——大到可以是一個部門，小到可以是單個貢獻者。 |
|---|---|---|
| 方法二 | 增強反饋循環 | 創建從右到左的反饋循環。以縮短和增強反饋爲流程改進計劃的目標，以便持續進行必要的修正。 |
| 方法三 | 持續實踐和學習的文化 | 創造一種能促進兩件事的文化：一是持續實踐、冒險和從失敗中學習；二是理解重複和實踐是精通某件事的先決條件。 |
歷史
追溯到20世紀90年代，敏捷已存在的時間比DevOps長得多，後者在將近20年後纔出現。然而，這兩套原則都源於精益製造，其歷史可以追溯到20世紀40年代。雖然DevOps的流行度持續增長，但敏捷仍然比DevOps更廣爲人知。谷歌趨勢表示“敏捷”一詞的搜索量大約是“DevOps”一詞的三倍。
敏捷的根源可以追溯到20世紀40年代的精益流程，其中包括看板，一種可視化豐田生產系統一部分工作流程的方法。限制理論也是後來發展起來的。然而，敏捷的軟件開發方法在20世紀90年代真正起步，當時一羣軟件開發人員常受到瀑布式開發方法中涉及的高度嚴格的流程的困擾。這些常導致軟件項目花費了數月甚至數年才導致失敗。在20世紀80年代和90年代，誕生了幾種軟件迭代開發方法作爲瀑布方法的替代，包括極限編程（XP）和看板。1995年，引入了敏捷開發的Scrum實踐。然後，在2001年Snowbird山度假村的著名會議上，一羣思想領袖齊聚一堂，共同編寫敏捷宣言。敏捷發展至今，其中許多變化和實踐都是從最初的宣言演變而來的，包括現代敏捷。雖然敏捷制定了總體原則，但實踐敏捷原則的方法有很多，Scrum和看板是最受歡迎的兩種（關於它們的區別，可閱讀《Kanban VS Scrum：哪個是最好的敏捷項目管理框架》）。
DevOps是一套更爲新的原則，它源於精益製造中的一些相同概念。“DevOps”一詞於2009年首次推出，當時Patrick Debois在比利時舉辦了“Devopsdays”活動。2013年，Gene Kim（作者），Kevin Behr（作者）和George Spafford（作者）撰寫了他們的書《鳳凰計劃》，其中提出的許多內容構成了DevOps的基礎概念。2014年，隨着DevOps企業峯會的啓動，DevOps不斷擴展到企業環境中。今天，DevOps繼續與敏捷一起成長和發展。
關鍵差異
雖然敏捷和DevOps具有很多一致性，但需要注意的是它們的側重點不同。敏捷主要關注應用程序的構建，而DevOps則將這一重點擴展到構建和運營應用程序。DevOps採用了敏捷的許多概念，並將這些概念擴展到構建過程之外並帶入生產。正是這個擴展導致了真正的差異。
如果說存在不同，那麼主要在於聚焦點的不同。敏捷教練Martin Corbett表示，“敏捷專注於分解工作，以儘快爲客戶提供更多價值，而DevOps專注於將代碼從構建擴展到部署的項目，例如持續部署。”此外，敏捷專注於構建工作軟件以及開發和QA之間的協作，而DevOps則專注於開發、QA和運營之間的協作。
雖然許多人都在尋找敏捷與DevOps之間的差異，但實際情況是，這兩種方法具有非常相似的目標和基礎原則，並且最終具有比差異更多的相似性。
DevOps是敏捷的延伸
在許多方面，DevOps可以被視爲敏捷的延伸，甚至是敏捷的自然演變。在瀑布開發流程中，有一個明確的交接（它是強制執行的過程）。敏捷作爲一個持續的過程，需要一種新的方法，DevOps有助於實現這種方法。
爲了實現精益和敏捷最佳實踐的核心小批量發佈，在DevOps中普及的全棧工程師的概念是這種需求的最佳答案。爲了減少交接，工程師必須悉知系統的所有部分，以便團隊中的任何成員都能理解操作要求，而無需交付給其他團隊。同樣，跨職能團隊必須成爲常態，以便小型，獨立的團隊可以提供功能齊全的產品，而無需向運營團隊進行額外的交接。
此外，敏捷的持續流程需要一定程度的構建和部署自動化。其中大部分都是在DevOps的CI / CD實踐和工具中提供的。CI / CD需要快速部署經過全面測試並且功能齊全的代碼給客戶。因此，很容易看出CI /CD是敏捷實踐所必需的自然演化。這些做法持續發展，使發佈週期時間進一步縮短，從數週到數天甚至數小時。
從另一個角度考慮，如果您有一個只有在開發完成後才能開始的爲期兩週的QA週期，那麼在一兩週內就很難將代碼推出。同樣，諸如變更審批、釋放資源、硬件購買和安裝等需要耗費時間的事情，都會影響你按時推出代碼。更不用說，您可能還有很多的交接工作，或者有一個週期長又繁重的發佈過程。如何進行爲期兩週的迭代並進行爲期兩個月的發佈過程？對此的明顯答案是DevOps。
這並不是說沒有DevOps就無法實現敏捷。敏捷在DevOps之前很久就存在，並且肯定有敏捷團隊不遵循許多DevOps實踐。正如Noah Cantor所說，“你可以做敏捷實踐和DevOps實踐，但你不能採用敏捷原則或DevOps原則，因爲它們太相似而不能分開。”並不是說它們不可分割，只是敏捷作爲DevOps的前身，同時激發了DevOps的影響力。
好處
精益一直是DevOps的核心，就像敏捷是從精益中生長出來的一樣。DevOps也是如此，所以這兩者有很大的共同點並不奇怪。DevOps採用Agile中的概念，並將其擴展到代碼部署之外。DevOps採用這些概念並將其應用於應用程序和服務的管理。它利用並優化了敏捷的原則，並且沿用了敏捷組織早已意識到的長處。
並不是說爲DevOps而做DevOps，或者說爲敏捷而做DevOps。2017年DevOps狀態報告顯示，高性能DevOps團隊的部署速度提高了46倍，交付時間縮短了44倍，更改失敗率降低了5倍，平均恢復時間縮短了96倍（MTTR）。在具有成熟DevOps實踐的組織中，這些數字顯然被低估了。
當我們查看敏捷和DevOps重疊的每個區域時，DevOps放大了敏捷實踐，我們希望您能夠採取一些具體措施來推動組織的發展。構建協作的最關鍵步驟之一是制定共同目標。有了共同的目標，您可以確保開發，運營，QA都一致朝着同一目標努力。
小批量交付爲推動DevOps實踐加速組織提供了另一個絕佳機會。在Scrum或看板等流程中，要將操作任務和操作思想集成到工作中。如果您正在使用Scrum，您也可以考慮使用看板，它更容易適應操作流程。
無論使用哪種方法進行小批量交付，您都可能希望確保使用相同的系統來跟蹤整個團隊的工作。通過統一跟蹤系統，您可以確保不積壓工作，並真實反應所有計劃內和計劃外工作，讓您更容易地使工作可見。作爲敏捷的一個關鍵原則，我們還可以擴展使工作可見的概念，以顯示運營工作、系統操作和架構支持等工作。組織還可以通過信息輻射體（比如看板）跨團隊分享這些信息。
當您着眼於構建更具協作性的文化時，要把每一次失敗都當作組織學習的機會。在這個文化中建立一些儀式，比如無可指責的事後反思、黑客馬拉松和失敗獎勵等。
對於本文中討論的重疊，存在組織上的含義。在敏捷和DevOps中包含QA意味着我們必須開始構建跨職能團隊，並培養具有廣泛知識技能的人員。這種重疊是隨着“全堆棧工程師”的概念而發展起來的。雖然每個人都知道一切可能不現實，但我們當然可以努力確保團隊中的每個人都有共同的責任和目標，包括質量和運營，如果他們樂於負責和學習的話。
有許多方式可以採用敏捷原則並使用DevOps強化它們，但最重要的是組織文化的一致性。如果團隊在目標上沒有保持一致，那麼敏捷中規定的團隊方法將不能擴展到部署以外的操作中使用。如果所有技術交付團隊都遵循相同的目標，即可立即開始打破這些組織之間的孤島。如果我們可以通過敏捷開始打破組織孤島並通過DevOps強化這項工作，我們將擁有真正的高性能組織。
『由於篇幅原因，本文被拆分兩篇，下一篇主要將介紹DevOps和敏捷之間的幾個共性，歡迎大家持續關注。』
關於Choerodon豬齒魚
Choerodon豬齒魚是一個開源多雲技術平臺，是基於開源技術Kubernetes，Istio，knative，Gitlab，Spring Cloud來實現本地和雲端環境的集成，實現企業多雲/混合雲應用環境的一致性。平臺通過提供精益敏捷、持續交付、容器環境、微服務、DevOps等能力來幫助組織團隊來完成軟件的生命週期管理，從而更快、更頻繁地交付更穩定的軟件。
Choerodon豬齒魚已開通官方微信交流羣，歡迎大家添加Choerodon豬齒魚微信(ID:choerodon-c7n)入羣
大家也可以通過以下社區途徑瞭解豬齒魚的最新動態、產品特性，以及參與社區貢獻：