汽車產業(yè)經歷百年發(fā)展，已經走過了“機械定義汽車”、“電氣定義汽車”、“電子定義汽車”現(xiàn)在到了“軟件定義汽車”的發(fā)展階段。豐田汽車成立軟件子公司W(wǎng)oven，大眾將成為一家軟件驅動的公司，特斯拉軟件人才密度是傳統(tǒng)主機廠的4到10倍，上汽零束軟件分公司成立，長城設立數(shù)字化中心等，這些行業(yè)的重大調整和布局表明“軟件定義汽車”已成為行業(yè)的戰(zhàn)略共識，軟件將是未來汽車智能化的基礎和競爭力的核心。軟件定義的汽車將通過OTA的方式升級汽車軟件，可以持續(xù)為用戶提供新功能，持續(xù)改善駕乘體驗。為了及時響應用戶對新功能以及功能修復的需求，汽車行業(yè)需要為此建立合適的軟件開發(fā)模式。IT軟件行業(yè)已經相對成熟，因此，本文介紹軟件行業(yè)的三種軟件開發(fā)模式（瀑布型開發(fā)、敏捷開發(fā)和DevOps），希望通過對軟件行業(yè)的軟件開發(fā)模式和發(fā)展規(guī)律的介紹，能為汽車行業(yè)建立軟件開發(fā)模式提供參考。
瀑布型開發(fā)，也就是傳統(tǒng)開發(fā)模式。瀑布型模型式是最典型的預見性的方法，嚴格遵循預先計劃的需求、分析、設計、編碼、測試的步驟順序進行。例如需求規(guī)格，設計文檔，測試計劃和代碼審閱等等。
瀑布型開發(fā)模式具有以下不足：
1).需求分析占比很重，對客戶想要的產品進行詳細分析，明確指定產品結果。但是由于需求人員的考慮的方面可能有疏漏，客戶的需求的變化，行情的變化等等因素存在，需求文檔會不斷變更，開發(fā)人員產生抵觸心理。
2). 開發(fā)人員按照需求文檔嚴格開發(fā)，限制思維，參與不到需求的設計。
3). 需求與客戶溝通存在障礙，可能導致最終產物不是客戶想要的。重新開始項目，很費事費力。
所謂的瀑布，很形象的表達了這一開發(fā)模式，就是留下去了，就回不去了。當然程序開發(fā)的時候可以重新開始，但是就相當于之前作廢，重立項目。但是市場在變，科技在變，一切都在不斷改變，擁抱變化才能更快的適應環(huán)境的變化。因此瀑布型開發(fā)模式逐漸被敏捷開發(fā)所取代。
敏捷開發(fā)(Agile Development)是一種以人為核心、迭代、循序漸進的開發(fā)方法。它不是一門技術，它是一種開發(fā)方法，也就是一種軟件開發(fā)的流程，它會指導我們用規(guī)定的環(huán)節(jié)去一步一步完成項目的開發(fā)；而這種開發(fā)方式的主要驅動核心是人；它采用的是迭代式開發(fā)。
敏捷開發(fā)只寫有必要的文檔，或盡量少寫文檔，敏捷開發(fā)注重的是人與人之間，面對面的交流，所以它強調以人為核心。而瀑布開發(fā)模型，它是以文檔為驅動的。因為在瀑布型的整個開發(fā)過程中，要寫大量的文檔，把需求文檔寫出來后，開發(fā)人員都是根據(jù)文檔進行開發(fā)的，一切以文檔為依據(jù)。
迭代是指把一個復雜且開發(fā)周期很長的開發(fā)任務，分解為很多小周期可完成的任務，這樣的一個周期就是一次迭代的過程；同時每一次迭代都可以生產或開發(fā)出一個可以交付的軟件產品。
Scrum是一種流行的敏捷開發(fā)流程構架，也可以說是一種套路。Scrum框架中包含三個角色，三個工件，四個會議，聽起來很復雜，其目的是為了有效地完成每一次迭代周期的工作。
Scrum工作流程如下圖所示。在學習Scrum工作流程之前，我們先要了解幾個基本術語：
Sprint：沖刺周期，通俗的講就是實現(xiàn)一個“小目標”的周期。一般需要 2-6 周時間。
User Story：用戶的外在業(yè)務需求。拿銀行系統(tǒng)來舉例的話，一個 Story 可以是用戶的存款行為，或者是查詢余額等等。也就是所謂的小目標本身。
Task：由 User Story 拆分成的具體開發(fā)任務。
Backlog：需求列表，可以看成是小目標的清單。分為 Sprint Backlog 和 Product Backlog。
Daily meeting：每天的站會，用于監(jiān)控項目進度。有些公司直接稱其為 Scrum。
Sprint Review meeting: 沖刺評審會議，讓團隊成員們演示成果。
Sprint burn down：沖刺燃盡圖，說白了就是記錄當前周期的需求完成情況。
Release：開發(fā)周期完成，項目發(fā)布新的可用版本。
如上圖所示，在項目啟動之前，會由團隊的產品負責人（Product owner）按照需求優(yōu)先級來明確出一份 Product Backlog，為項目做出整體排期。
隨后在每一個小的迭代周期里，團隊會根據(jù)計劃（Sprint Plan Meeting）確定本周期的 Sprint Backlog，再細化成一個個 Task，分配給團隊成員，進行具體開發(fā)工作。每一天，團隊成員都會進行 Daily meeting，根據(jù)情況更新自己的 Task 狀態(tài)，整個團隊更新 Sprint burn down chart。
當這一周期的 Sprint backlog 全部完成，團隊會進行 Spring review meeting，也就是評審會議。一切順利的話，會發(fā)布出這一版本的 Release，并且進行 Sprint 回顧會議（Sprint Retrospective Meeting），也稱為總結會議，以輪流發(fā)言方式進行，每個人都要發(fā)言，總結并討論改進的地方，放入下一輪Sprint的產品需求中。
從上述工作流程可以看出，敏捷開發(fā)并沒有將運維也納入進來，有可能需求，開發(fā)，測試很快做出了很多版本，但是沒有部署，或者部署很慢。也拖延產品的進程。這就需要開發(fā)，測試，運維的相互溝通。為了加快這些環(huán)節(jié)的溝通問題，出現(xiàn)了DevOps開發(fā)理念。
DevOps是Development與Operations的縮寫。DevOps就是要打破開發(fā)與運維之間的隔閡，提高了各個團隊的協(xié)作，通過自動化流程來使得軟件構建、測試、發(fā)布更加快捷、頻繁和可靠。
DevOps是為了填補開發(fā)端和運維端之間的信息鴻溝，改善團隊之間的協(xié)作關系。不過需要澄清的一點是，從開發(fā)到運維，中間還有測試環(huán)節(jié)。DevOps其實包含了三個部分：開發(fā)、測試和運維。
DevOps希望做到的是軟件產品交付過程中IT工具鏈的打通，使得各個團隊減少時間損耗，更加高效地協(xié)同工作。專家們總結出了下面這個DevOps能力圖，良好的閉環(huán)可以大大增加整體的產出。
下圖是以Jira為源的DevOps工具鏈。整個DevOps流程包括：需求管理、持續(xù)集成&測試、配置&部署、監(jiān)控&運營，各個環(huán)節(jié)的任務均有相應的工具來完成。
下面給出了一個通用的邏輯流程，在這個流程中所有內容都將自動進行無縫交付。但是此流程也會因不同組織的不同需求而導致一些差異。
1). 開發(fā)人員開發(fā)代碼，源代碼由Git等版本控制系統(tǒng)工具管理。
2). 開發(fā)人員將此代碼提交到Git，并且對代碼所做的任何更改都將提交到此代碼倉庫。
3). Jenkins通過Git插件從倉庫中提取此代碼，并使用Ant或Mave 等工具構建它。
4). 配置管理工具（如Puppet）部署和提供測試環(huán)境，然后Jenkins在使用Selenium等工具進行測試的測試環(huán)境上發(fā)布此代碼。
5). 代碼測試結束后，Jenkins 就會將其發(fā)送到生產服務器上進行部署（甚至生產服務器也由 Puppet 等工具進行配置和維護）。
6). 部署后，Nagios 等工具會進行持續(xù)監(jiān)控。
7). Docker容器提供測試環(huán)境來測試構建功能。
DevOps和敏捷開發(fā)有以下區(qū)別：
市場對軟件行業(yè)的開發(fā)需求，促使其軟件開發(fā)模式不斷演進，從瀑布型開發(fā)模型發(fā)展到目前流行的DevOps開發(fā)模式，其核心在于通過自動化工具提高軟件團隊的溝通效率，改善軟件功能可持續(xù)部署和交付的能力。軟件行業(yè)開發(fā)模式的演變必定會給汽車行業(yè)制定軟件開發(fā)模式帶來啟發(fā)。
參考文獻：
1.
1.一篇文全面了解DevOps：從概念、關鍵問題、興起到實現(xiàn)需求，作者：木環(huán).
聯(lián)系客服
