20 世紀 60 年代，軟體開始脫離硬體，逐漸成為一個獨立産業。至今，軟體開發過程從瀑布模型、CMM/CMMI，到 20 年前靈活的誕生，再到今天 DevOps 的火熱，一代代軟體人在思考和探索，如何避開“焦油坑”，試圖尋找軟體傳遞的“銀彈”。
焦油坑：複雜且讓人感覺束縛，越陷越深難以擺脫。常被軟體開發者形容軟體産品的複雜度成倍增長；銀彈：比喻詞，形容解決問題的捷徑。 圖源網絡
DevOps 作為目前軟體工程界的集大成者，備受關注，業界也有很多讨論。近年來包括博雲在内的很多廠商，也投身于 DevOps 之中，希望将更好的軟體研發管理方法與工程實踐通過産品和服務帶給客戶。
20 世紀 60 年代以後，硬體技術快速發展，第三、四代計算機陸續産生，軟體從計算機實驗室逐漸走向更廣闊的的軍工、商業、民用場景。在這個轉變的過程中，軟體也逐漸開始脫離硬體獨立銷售，軟體的重要性逐漸提升超過硬體，其複雜性也愈發凸顯。
靈活方法是需要用實踐方法來解決這些問題。比如響應變化這一點，XP 方法中，如果（疊代中的）一個使用者故事還沒有實作，允許可以考慮用另外的使用者故事替換，替換的前提的工作量是相等的；而 Scrum 強調一旦開工會定下來，需求就不允許被添加進來，并且需要 ScrumMaster 來把關。
● 從軟體産品（軟體開發的産物）次元來看，研發成本過高、品質不可靠、難以維護、開發效率/産能跟不上硬體的發展及使用者需求的增長，成為核心的難題；
● 從軟體項目（軟體開發的過程）次元來看，成本超預算、計劃嚴重延期成為常态。1975 年 Brooks 的《人月神話》，提出了“焦油坑”和“銀彈”的說法。時至今日，軟體工業仍然在尋找“銀彈”的路上。
在此等複雜性的背景下，這個階段軟體開發技術與方法的發展卻沒有跟上。愈發複雜的需求、場景與環境倒逼着軟體開發技術與方法的交織發展。
軟體工程第一次被提出是什麼時候呢？1968 年，北約的計算機科學家第一次提出了軟體工程的概念，希望通過系統化、規範化、數量化等工程原則和方法來實作複雜軟體系統的開發和維護。
以下為《nota1968》中的部分描述摘錄，五十年前的觀點，如今看來仍然鮮活：
關于軟體項目管理：
軟體開發管理将繼續背負目前的在成本和計劃有效性上的壞名聲，直到有朝一日，人們對軟體設計工程有了更全面的了解和認識。
我們開發軟體系統就像萊特兄弟制造飛機——造好整個系統，把它推下懸崖，讓它墜毀，然後重新開始。
管理工作方面，大型軟體的開發是一個令人恐怖的事情。人們的認識中，這種工作通常會成為血本無歸的泥潭，耗費财力，永無止境。人們的這種認識也許并不是偏見。
關于使用者需求：
使用者感興趣的是對系統提需求，而且按照需求購買系統。但這裡的潛台詞是使用者能說出他們想要什麼。而大部分的使用者說不清楚。
我們應該在設計過程中盡早的擷取使用者回報。
軟體工程的本質性難點到底在哪裡？讓我們引用轉述一下《人月神話》作者 Brooks 在 1986 年的論文《No Silver Bullet》中的觀點。布魯克斯認為，附加性的困難會随着工具的改善而逐漸淡化，反而是本質性的困難最難以解決，因為大部分的活動是發生在人們的腦海裡，缺乏有效的輔助工具。依照布魯克斯的說法有下列幾項：
● 複雜性（complexity）：軟體要解決的問題，通常牽扯到計算步驟，這是一種人為、抽象化的智能活動，多半是複雜的。
● 隐匿性（invisibility）：尚未完成的軟體是看不見的，即使利用圖示說明，也常無法充分呈現其結構，使得人們在溝通上面臨極大的困難。
● 配合性（conformity）：在大型軟體環境中，各子系統的接口必須協同一緻。由于時間和環境的演變，要維持這樣的一緻性通常十分困難。
● 易變性（changeability）：軟體所應用的環境常是由人群、法規、硬體裝置、應用領域等，各因素所彙集而成，而這些因素皆會快速變化。
Brooks 在他的論文《No Silver Bullet》中表示：不存在任何一個單一的開發技術或管理技術能夠解決軟體工程所面臨的所有問題。因而軟體工程是一個包括一系列概念、理論、模式、語言、方法以及工具的綜合性學科。
是以，軟體工程，或者說軟體的實作過程，實際上是一個綜合性的學科。涉及到技術手段、管理方法和内外部環境等因素。
洛克希德軟體技術中心的 Winston W. Royce，在其 1970 年的論文“Managing the Development of Large Software System”中提出了一個長得很像瀑布（waterfall）的流程。
按照科學管理的理念，隻要按照标準流程、标準動作來，就能産出高品質軟體、解決軟體危機，這就是最佳實踐。然而真的是這樣嗎？舊世界的軟體工程并沒有給出答案：
● 很多軟體工程著作并沒有對軟體開發的日常實踐給出具體的指導，結果到實際工作中就變成了“邊做邊改、邊改邊做”；
● CMM 評估流于形式，例如評估小組隻詢問文檔在哪裡而并不真正關注文檔的内容是否恰當以及文檔本身的價值；
● CMM 所關注的“成熟度”與軟體開發過程的“有效性”脫節，通過了 CMM5 級認證的團隊照樣會開發出沒人買單的糟糕軟體。
說到這裡不得不提的是科學管理之父泰勒和他的科學管理理論。科學管理、泰勒主義的理念是：
少數精英負責制定标準的工作流程、工具操作、工藝品質，再由管理層完成監督和管理工作，大量的藍領勞工可以不用動腦子、不思考地就可以完成符合品質标準的工作，進而産生合格的産品。我想大家一定都記得 K12 課本裡出現過的一句話：“我需要的是一雙手，而不是一個人”。
客觀上來講，科學管理的提出和應用确實帶動了工業制造的發展提速，解決了生産力不足、無法滿足市場需求的問題，這也是工業革命後不可逆的趨勢。但科學管理也并非永遠是萬能的。
20 世紀以後，行業面臨的挑戰從“生産力不足、無法滿足市場的功能性需求”逐漸轉變為“靈活性不足，無法滿足消費者對創新和定制需求”。“快速、殘酷與不确定性的變化”将是未來制造業面對的常态挑戰。每個行業都開始強調變化，這個問題的本質直到今天仍然适用。
而對于軟體工程領域來說，Agile/靈活，就是關于企業如何在一個動蕩的、競争激烈的經營環境中獲得利潤。跟“科學時代的軟體”的差別在于：
● 對市場的需求和認知。承認變化、接受變化，不認為客戶需求可以一次性集中研究然後完全擷取。
● 對生産的态度和工作方法。接受錯誤、願意試錯、快速調整、持續優化。
● 對生産資料的态度。承認個人的能力與價值，“讓一線呼喚炮火“，而不是“精英定規則，生産線上隻要一雙雙手”。
當然，以上并不是完全否定瀑布與 CMM 的價值和意義。隻是，在現下的世界與環境中，CMM 與瀑布并不能完全解決我們的問題，是以我們仍然不得不繼續尋找“銀彈”。
衆所周知，2001 年 2 月，在鹽湖城外 25 公裡的雪鳥城（Snowbird），一個滑雪勝地，17 位業界先鋒聚在一起，制定并簽署了行業曆史上最重要的檔案之一：靈活宣言。随後，他們共同商讨出 12 個靈活原則，對宣言進行進一步的解讀。
方法論，是關于“如何開發一個軟體系統”的行為架構，包含如何組建團隊、如何做項目計劃、團隊成員及跨團隊如何交流、如何管控項目進度與品質。
在“雪鳥會議”之前，已經存在了很多這種被稱為“輕量級（Lightweight）”的軟體開發方法，雪鳥會議的結果是正式地将這些方法統稱為“靈活（Agile）”軟體界開發方法。
不同的新方法有着一些共同的特征。例如，強調适應性而非預見性。是以靈活主義者會說“擁抱變化”，靈活宣言中也有那句“響應變化重于遵循計劃”。
可能有人會說，既然這樣，那充滿變化、不按計劃、沒有邊界，那項目還怎麼做？靈活方法是需要用實踐方法來解決這些問題。比如響應變化這一點，XP 方法中，如果（疊代中的）一個使用者故事還沒有實作，允許可以考慮用另外的使用者故事替換，替換的前提的工作量是相等的；而 Scrum 強調一旦開工會定下來，需求就不允許被添加進來，并且需要 ScrumMaster 來把關。
再比如，強調面向人，而非面向過程。強調人的作用與價值。是以靈活宣言中會說“個體和互動重于過程和工具”。
也可能有人會說，那是不是靈活就可以不寫文檔了？其實并不是完全不寫文檔了，而是為了減少浪費，減少準備文檔、溝通傳遞資訊、了解文檔這個過程話費的時間和人力。不在對客戶沒有價值的東西上面浪費時間，這是“靈活不寫文檔”的真實含義。用這個原則指導，使用者故事/需求、架構圖、複雜業務/計算邏輯等都是無法從代碼中看出來的，這就是需要寫的。而高保真設計、資料庫表結構、僞代碼等就可以精簡或者不寫。
靈活方法的出發點，是運用一些更有效的方法（工程實踐），傳遞高價值、高品質的軟體。
什麼是高價值的軟體？産生商業價值的能力更強。是以在使用使用者故事這一工具時，它的描述規格是“可以實作 xxx 商業價值”。
什麼是高品質的軟體？更穩定、更靈活、易維護、易擴充。
靈活實踐的總結：通過可落地的、緊密配合的一系列靈活實踐，來産生高價值、高品質的軟體。
什麼是緊密配合？舉例來說，簡單設計後如何進行進一步的優化？那就必須使用重構。如何能讓重構成為一種經常性的、快速有效的開發方法？單元測試代碼的開發就是必不可少的步驟，而測試驅動開發就是其最佳實踐。如何讓持續內建跑的順利？必須推廣統一的編碼規範，并且還得有自動化測試用例集。
靈活軟體開發方法的需求梳理工作，一般是通過使用者故事的形式來開展的。
在《使用者故事實戰》一書中，将 US 的特性概括為”3 個 C”：Card、Conversation、Confirmation。後面兩個 C 展現的就是 US 作為一種寫作方式的定位（而非傳統需求檔案試圖去描述完整需求）。
另外，從需求的傳遞與跟蹤來看，Story Backlog 和 Kanban 都是常用的工具，但各有其應用場景。從最初産生的場景來看，Kanban 更适合連續性的、源源不斷的工作項跟蹤，而使用者故事 Backlog 是以疊代為機關，分批去消化不同的需求。
重構是靈活軟體開發方法裡非常核心的實踐之一，強調的是在不改變軟體行為的前提下優化軟體的内部結構。一個小小的重命名工作，通過“如烹小鮮”般的一系列動作來完成。看似瑣碎，卻嚴謹、小巧、可控。通過這一系列的操作，使得重構的難度（對原有代碼可觀察行為的影響）大大降低。特别是在複雜的軟體項目中，這種極高的可操作性會展現它的巨大價值。
在 IDE 高度進化的今天，類似這種重構的場景，甚至更多複雜的重構場景，都可以借由現代 IDE 的内置功能去完成，重構變得更加簡單、快捷、好用。
重構可以在保持行為不變的前提下改善軟體内部品質。但如何檢驗軟體的行為是否變化，隻能靠測試。試想一下，如果你在通過重構來完成代碼的開發，這個過程如何檢驗軟體在修改前後是否真的“行為不變”？隻有通過測試。而高頻重構/修改，則意味着需要高頻的測試。高頻的測試，自動化是必然。
那是否自動化了就夠了，或者說如何更好的做自動化測試、單元測試、契約測試等等自動化測試工作，它們之間又有什麼差別與聯系？這又是另外關于自動化測試的靈活實踐方法。
如何保障軟體品質？XP 的方法是，從可觀察性區分，外部品質靠自動化測試，内部品質靠重構。但對于一個中大性項目團隊，在通常為期數月甚至以年計的傳遞過程中，如何堅持下來？這就要靠持續內建。持續內建的工程實踐包括一系列的工具和方法：
● 通過代碼/配置管理工具，将代碼集中版本化管理起來；
● 通過代碼分支管理政策，建立起适配項目特點的分支/版本管理方法；
● 通過 CI 工具，完成建構過程的自動化，建立持續內建流水線；
● 通過單元測試、自動化測試工具和方法，保證持續內建的品質和可靠性；
● 通過将 CI/CD 過程中的非代碼部分的必要産物（如 Shell 腳本）也版本化，來保證整個持續內建過程的自動化、穩定性和可重制性。
團隊需要在指定的時間段内完成一系列工作項的過程稱為疊代。疊代的持續時間一般由團隊和産品所有者決定。
在 Scrum 架構中，疊代被稱為 Sprint（沖刺）。而 Scrum 的項目過程有一系列的 Sprint 組成。Sprint 的長度一般控制在 2-4 周，通過固定的周期保持良好的節奏。産品的設計、開發、測試都在 Sprint 期間完成。在 Sprint 結束時傳遞可以工作的軟體。整個 Sprint 的過程中（計劃會議确定下工作項内容後）不允許發生變更。
一般意義來講，CMM 更多的是一種預定義的、固化的模型。而 Agile 是一種經驗性的、彈性的模型。軟體開發，本質上是一種解決複雜未知問題的過程，解決這種問題用經驗性過程會更加有效。
但在 CMMI 目前較新的版本中，也增加了對使用靈活方法的組織的指南。以下 為 CMMI V1.3 中對于靈活的描述片段。
XP
從研發管理的視角來說，Agile 已經涵蓋了流程、方法、實踐、文化，甚至一部分工具。Scrum 架構其實就是一些輕量級的流程方法的集合。而 XP 則更多的強調了很多好的工程實踐。靈活宣言本身就是靈活文化的展現，甚至自帶靈活先驅們的浪漫主義情懷。而持續內建這一工程實踐不可能脫離工具而存在。但 Agile 的各家言論并沒有真正把“盡快傳遞業務價值”的最後一公裡走完，是以完整的工具鍊，以及生産環境管理要到 DevOps 中去尋找答案。
而從應用管理的視角來看，我們在實踐 DevOps 的時候，多半也會去使用很多 Agile 中的流程、方法、實踐。比如我們做需求的時候經常會用到使用者故事、看闆；做設計的時候也會強調簡單設計，避免過度設計；整個開發過程使用疊代的方式去管理、測試和部署時會使用持續內建并遵循一定的分支及流水線管理政策等等。而在上線包括上線之後，則會多出一些 Agile 中 沒有說的特别清楚的重要内容，Ops。
通過上面的觀察，我們會發現 Agile 和 DevOps 是密不可分的，并且他們本質上都是在做一件事情，就是軟體工程。
當然，對于不同的行業，DevOps 還是可能會有很多不一樣的地方。比如在強監管的金融機構，測試環境和生産環境之間難以逾越的高牆可能一直會存在。而這在很多網際網路公司或普通企業來講就不是一個特别要命的問題。
無論有什麼樣的差異性，無論我們把正在做的事情是叫 Agile 還是 DevOps ，甚至未來又出現什麼新的名字，其實我們都在解決軟體工程領域的問題，品質、效率、成本鐵三角是這個領域永遠的命題。
工具鍊的內建建構是 DevOps 落地過程中非常重要的一項工作。整個工具鍊的串聯會涉及到很多工具。我們可以從兩個次元列舉一些常見的工具：
研發工程次元（軟體傳遞過程）：
項目協同：Jira、BeyondDevOps Synergy；
代碼托管：GitLab、Bitbucket；
制品管理：Artifactory、Nexus、Harbor；
建構管理：Maven、Docker、NPM；
代碼品質：Sonar、Junit；
自動化測試：JMeter、Selenium；
流水線工具：Jenkins、JFrog。
基礎設施次元（周邊配套系統）：
IaaS 平台：VMware、Openstack、BeyondCube；
容器管理：Kubernetes、BeyondContainer；
部署平台：Ansible、Python、Shell、BeyondStage；
ITSM：CMDB、CMP、BeyondCMP、BeyondCMDB；
日志平台：ELK、EFK；
自動化監控：Zabbix、Prometheus。
如果沒有流水線，就無法完成自動化的 CI/CD 過程，“持續”二字也就無從談起。以博雲的 BeyondDevOps 産品來說，基于 Jenkins 提供了産品、服務兩級流水線自定義編排能力。
同時通過任務模闆，通過“流水線、步驟、任務”多級模闆、提供“樂高”式的流水線搭建體驗。并且平台已經内置各種常用模闆：從代碼建構、代碼掃描、制品/鏡像拉取、自動化測試、到制品部署各個環節。如果已有模闆并不滿足使用，也可以通過自定義模闆功能來實作新模闆的開發和接入。
代碼分支政策及分支管理規範，是 DevOps 中 SCM 領域的核心實踐。常見的代碼分支政策包括 Git Flow、GitHub Flow、TBD Flow 等等。不同類型的公司、産品、系統、項目，适用的分支政策也未必完全相同。好的 DevOps 平台，可以适配不同的代碼分支管理政策，幫助客戶通過平台和工具鍊完成 SCM 的整體管理，比如在某些場景下，可以将某種分支管理規範形成一個 Template 固化到平台中，幫助研發團隊降低複雜分支政策的使用門檻。
制品是軟體開發過程的核心輸出物，也是産生最終業務價值的載體。對于企業來說，建立組織級的統一制品管理體系是非常必要的。其中包括制品的命名标準、二方包管理規範、三方包管理規範、生産/非生産制品包管理規範，還包括制品如何晉級，以及相應的安全政策等。
生産環境的釋出和運維，是一個非常嚴謹的工作。相對于大多數企業和網際網路公司來說，金融機構對于生産釋出的要求會更高。包括上線申請單、資源協同開通、制品管理、可定義的自動化釋出過程、應用配置中心等。特别是在很多傳統金融機構中，生産環境釋出還意味着多部門配合、多系統調用、多網絡環境協同等等工作。博雲的 BeyondDevOps 整體解決方案就是在這種複雜的業務場景中産生的。
DevOps 作為目前軟體工程界最佳實踐的集大成者，确實是炙手可熱的研發管理方法。但隻要是管理，就有萬千不同。對于向落地 DevOps 的團隊群組織來說，所處行業、組織文化、軟體形态、團隊現狀、内部環境等等因素的不同，都會導緻其研發管理和工程實踐的不同。
如何在充分考慮現實因素（目标、時間、成本、資源）的情況下，去選擇一個切實有效的路徑和方案，是落地 DevOps 項目成功的關鍵。是以對于一個 DevOps 項目來說，并非買一套産品就萬事大吉。博雲基于自身在金融、工業、企業、政務等行業的經驗，總結了一套可以為不同行業客戶落地的傳遞方案，願意與各個行業的朋友持續交流切磋。
羅馬不是一天建成的，DevOps 作為研發管理之重器，也并非一朝一夕就可以建設好、運用好。對于大多數的組織來說，完整 DevOps 體系的建設和應用之路需要做好規劃，特别是有一些企業對于 DevOps 除了實踐應用之外還有過信通院能力成熟度模型的需求，還要為過級評估工作留出充分的時間。
在目前很多企業年度預算制的開支架構下，DevOps 項目需要做好規劃與路徑，做到有明确的短期、場景的目标與實作路徑，才能更好地完成項目，達成預期。
博雲 BeyondDevOps 平台開放試用，歡迎通路bocloud.com.cn，或掃描下方二維碼或點選文末閱讀原文申請試用。