敏捷開發
1.1 什么是敏捷?
敏捷是用于描述軟件開發方法的術語，強調增量交付、團隊協作、持續規劃和持續學習。"敏捷"一詞源于2001年《敏捷宣言》。宣言旨在確立指導軟件開發更優方法的原則。其核心是宣布代表敏捷運動基礎的4項價值觀：
- 個體和交互 勝過 過程和工具
- 可以工作的軟件 勝過 面面俱到的文檔
- 客戶合作 勝過 合同談判
-
響應變化 勝過 遵循計劃
依據以上四條價值觀，衍生出來更具體的十二大原則，作為對敏捷宣言更具實操性的解釋，其具體原則內容如下：
1) 最重要的是通過盡早和不斷交付有價值的軟件滿足客戶需要。
2) 我們歡迎需求的變化，即使在開發后期。敏捷過程能夠駕馭變化，保持客戶的競爭優勢。
3) 經常交付可以工作的軟件，從幾星期到幾個月，時間尺度越短越好。
4) 業務人員和開發者應該在整個項目過程中始終朝夕在一起工作。
5) 圍繞斗志高昂的人進行軟件開發，給開發者提供適宜的環境，滿足他們的需要，并相信他們能夠完成任務。
6) 在開發小組中最有效率也最有效果的信息傳達方式是面對面的交談。
7) 可以工作的軟件是進度的主要度量標準。
8) 敏捷過程提倡可持續開發。出資人、開發人員和用戶應該總是維持不變的節奏。
9) 對卓越技術與良好設計的不斷追求將有助于提高敏捷性。
10) 簡單——盡可能減少工作量的藝術至關重要。
11) 最好的架構、需求和設計都源自自我組織的團隊。
12) 每隔一定時間，團隊都要總結如何更有效率，然后相應地調整自己的行為。
1.2 敏捷開發概念與特點
敏捷開發是一種從1990年代開始逐漸引起廣泛關注的新型軟件開發方法，是一種應對快速變化的需求的一種軟件開發能力。它們的具體名稱、理念、過程、術語都不盡相同，相對于“非敏捷”，更強調程序員團隊與業務專家之間的緊密協作、面對面的溝通、頻繁交付新的軟件版本、緊湊而自我組織型的團隊、能夠很好地適應需求變化的代碼編寫和團隊組織方法，也更注重軟件開發中人的作用。
敏捷開發是用于描述迭代軟件開發的術語。敏捷開發通常與傳統或瀑布開發形成對比，在傳統或瀑布開發中，大型項目是按照該計劃進行規劃和執行的。
敏捷開發以用戶的需求進化為核心，采用迭代、循序漸進的方法進行軟件開發。在敏捷開發中，軟件項目在構建初期被切分成多個子項目，各個子項目的成果都經過測試，具備可視、可集成和可運行使用的特征。換言之，就是把一個大項目分為多個相互聯系，但也可獨立運行的小項目，并分別完成，在此過程中軟件一直處于可使用狀態。迭代軟件開發縮短了軟件開發生命周期。
1.3 敏捷開發流程
敏捷開發團隊以較小的增量執行整個軟件開發生命周期，通常稱為沖刺（sprint）。沖刺通常有1-4周長。每次沖刺交付產品級代碼都需要敏捷的開發團隊來應對加速的步伐。所有編碼、測試和質量驗證都必須在每個沖刺階段完成。各團隊間應密切協作，否則可能會導致失敗甚至慘敗。
圖1：敏捷開發流程示意圖
敏捷開發團隊幾個關鍵的成功因素：
1. 細化需求列表
2. 早期并高頻集成
3. 盡量避免技術缺陷
1.4 敏捷方法與最佳實踐
敏捷是一種尋找軟件開發方法的態度。敏捷方法中沒有一種方法適用于所有情況，而"敏捷"一詞已經代表與宣言中的價值陳述一致的各種敏捷方法與最佳實踐。
敏捷方法是一個囊括了各種框架和方法的涵蓋性術語，它指的是符合《敏捷宣言》價值觀和原則的任何方法、技術、框架、手段或實踐。敏捷方法（通常稱為敏捷框架）是軟件開發生命周期階段（規劃、執行和交付）的綜合方法。它規定了一套在明確的指導和原則下完成工作的方法。
敏捷方法主要包括SCRUM方法、DSDM 方法、水晶方法、特性驅動方法和 SCRUMBAN 等。例如Scrum是最常見的敏捷框架。持續集成（Continuous Integration，CI）是常見的敏捷工程實踐方法。
需要說明的是，敏捷方法與最佳實踐并不承諾解決每一個問題，但他們確實承諾建立一個文化和環境，通過協作，不斷的規劃和學習，并快速迭代交付高質量的軟件，最終滿足客戶需求。
2.
SCRUM方法
2.1 SCRUM綜述
Scrum 是團隊用于管理其工作的框架，將敏捷原則作為一套具體的工件、實踐和角色，通常用于敏捷軟件開發。具體來說，Scrum 是用于開發、交付和持續支持復雜產品的一個框架，是一個增量的、迭代的開發過程。Scrum起源于軟件開發項目，Scrum包括了一系列實踐和預定義角色的過程骨架。Scrum中的主要角色包括同項目經理類似的Scrum主管角色負責維護過程和任務，產品負責人代表利益所有者，開發團隊包括了所有開發人員。雖然Scrum是為管理軟件開發項目而開發的，它同樣可以用于運行軟件維護團隊，或者作為計劃管理方法，適用于任何復雜的或是創新性的項目。如Scrum 目前已被用于開發軟件、硬件、嵌入式軟件、交互功能網絡、自動駕駛、學校、政府、市場、管理組織運營，以及日常生活中更廣泛的產品開發領域。
2.2 SCRUM流程
Scrum整個開發流程(見圖2) 由若干個短的迭代周期組成，一個短的迭代周期稱為一個Sprint，每個Sprint的建議長度是一至四周。在Scrum中，使用產品Backlog來管理產品的需求，產品backlog是一個按照商業價值排序的需求列表，列表條目的體現形式通常為用戶故事。Scrum團隊總是先開發對客戶具有較高價值的需求。在Sprint中，Scrum團隊從產品Backlog中挑選最高優先級的需求進行開發。挑選的需求在Sprint計劃會議上經過討論、分析和估算得到相應的任務列表，我們稱它為Sprint backlog。在每個迭代結束時，Scrum團隊將提交潛在可交付的產品增量。
圖2 Scrum流程圖
2.3 SCRUM框架
Scrum框架包括3個角色、3個工件、5個事件、5個價值：3個角色：產品負責人（Product Owner）、Scrum Master、開發團隊3個工件：產品Backlog（Product Backlog）、SprintBacklog、產品增量（Increment）5個事件：Sprint（Sprint本身是一個事件，包括了如下4個事件）、Sprint計劃會議（Sprint Planning Meeting）、每日站會（Daily Scrum Meeting）、Sprint評審會議（Sprint Review Meeting）、Sprint回顧會議（Sprint Retrospective Meeting）5個價值：承諾 – 愿意對目標做出承諾、專注– 把你的心思和能力都用到你承諾的工作上去、開放– Scrum 把項目中的一切開放給每個人看、尊重– 每個人都有他獨特的背景和經驗、勇氣– 有勇氣做出承諾，履行承諾，接受別人的尊重
3.
DevOps
3.1 DevOps 定義
DevOps 是開發 (Dev) 和運營 (Ops) 的復合詞，是一組過程、方法與系統的統稱，用于促進開發（應用程序/軟件工程）、技術運營和質量保障（QA）部門之間的溝通、協作與整合。
3.2 DevOps 發展背景
傳統的軟件組織將開發、IT運營和質量保障設為各自分離的部門。在這種環境下如何采用新的開發方法（例如敏捷軟件開發），這是一個重要的課題：按照從前的工作方式，開發和部署不需要IT支持或者QA深入的、跨部門的支持，而卻需要極其緊密的多部門協作。然而DevOps考慮的還不止是軟件部署。它是一套針對這幾個部門間溝通與協作問題的流程和方法[9]。
以下幾方面因素可能促使一個組織引入DevOps：
1、使用敏捷或其他軟件開發過程與方法
2、業務負責人要求加快產品交付的速率
3、虛擬化和云計算基礎設施（可能來自內部或外部供應商）日益普遍
4、數據中心自動化技術和配置管理工具的普及
5、有一種觀點認為，占主導地位的“傳統”美國式管理風格（“斯隆模型 vs 豐田模型”）會導致“煙囪式自動化”，從而造成開發與運營之間的鴻溝，因此需要DevOps能力來克服由此引發的問題。
DevOps經常被描述為“開發團隊與運營團隊之間更具協作性、更高效的關系”。由于團隊間協作關系的改善，整個組織的效率因此得到提升，伴隨頻繁變化而來的生產環境的風險也能得到降低。
在云計算、大數據等技術顛覆性趨勢繼續在應用經濟下發揮作用的同時，DevOps也已經穩健地在業務思維方式中占有一席之地，并將扮演主要角色。在應用驅動、云連接、移動化的大環境下，對于很多公司來說DevOps是助力業務增值戰略的第一步。
緊跟行業趨勢、進行新的技術變革往往會帶來發展的陣痛，DevOps也同樣要經歷這一過程。中國及全球各地的企業正在認識到DevOps可以助力軟件開發速度加快，軟件應用質量提升，更重要的是與業務目標更完美地結合。
3.3 DevOps 文化
1) 協作、可見性和一致性
健康的 DevOps 文化的一個標志是團隊間能夠協作，首要的便是可見性。開發和 IT 運營等不同團隊必須能夠相互分享 DevOps 流程、優先級和關注點。這些團隊還必須能夠共同規劃工作，并統一與業務相關的成功目標和衡量標準。
2) 范圍和責任的轉變
當團隊統一時，他們擁有所有權并參與其他生命周期階段，而不僅僅是他們的角色對應的階段。例如，開發人員不僅要對開發階段的創新和質量負責，還要對他們的改變在運營階段帶來的性能和穩定性負責。同時，IT 操作員一定要在規劃和開發階段中考慮治理、安全性和符合性。
3) 縮短發布周期
DevOps 團隊通過短周期發布軟件保持敏捷。因為進度是漸進式的，縮短發布周期可以讓計劃和風險管理更容易，同時也減少了對系統穩定性的影響。縮短發布周期還可以讓組織適應和應對不斷變化的客戶需求和競爭壓力。
4) 持續學習
高績效的 DevOps 團隊形成了一種成長思維。他們快速失敗，然后將經驗教訓融入到他們的流程中，不斷改進，提高客戶滿意度，加速創新和適應市場。DevOps 是一個旅程，所以總有成長的空間。
3.4 DevOps 和應用程序生命周期
DevOps 影響應用程序生命周期的規劃、開發、交付和運營階段。每個階段都依賴于其他階段，并且這些階段并非特定于角色。在真正的 DevOps 文化中，每個角色在某種程度上說都涉及各個階段如圖 4。
圖 4 DevOps 和應用程序生命周期
3.5 DevOps 做法
除了形成 DevOps 文化之外，團隊還通過在整個應用程序生命周期中實施特定做法，以充分利用 DevOps。- 持續集成和持續交付 (CI/CD)
- 版本控制
- 敏捷軟件開發
- 基礎結構即代碼
- 配置管理
-
持續監控
其中一些做法有助于加速、自動化和改進特定階段。有的跨越幾個階段，幫助團隊創建提高生產效率的無縫進程。
3.6 DevOps 工具
無論是縱向集成還是橫向集成，DevOps都需要通過工具鏈與持續集成、交付、反饋與優化進行端到端整合。如華為的軟件開發云服務, 基于二十幾年的研發實踐，融合DevOps理念方法，為企業提供一站式的云上開發工具平臺。華為軟件開發云提供項目管理、配置管理、代碼檢查、編譯構建、測試、部署、發布等端到端地覆蓋全軟件生命周期的相關服務。類似的DevOps 工具數不勝數，常見的DevOps 生態圈工具如圖 5。
3.7 DevOps 與Agile 的關聯
DevOps 和 Agile 都是用于生產產品、進行發布或發行的現代軟件開發框架。DevOps 是一種文化，促進軟件開發和維護中所有角色之間的協作。Agile 是一種開發方法，在需求不斷變化的常見現實中保持工作效率和促進發布。DevOps 和 Agile 并不是相互排斥的，而是經常搭配使用。
4.
持續集成
4.1 持續集成背景
集成軟件的過程不是新問題，如果項目開發的規模比較小，比如一個人的項目，如果它對外部系統的依賴很小，那么軟件集成不是問題，但是隨著軟件項目復雜度的增加（即使增加一個人），就會對集成和確保軟件組件能夠在一起工作提出了更多的要求-要早集成，常集成。早集成，頻繁的集成幫助項目在早期發現項目風險和質量問題，如果到后期才發現這些問題，解決問題代價很大，很有可能導致項目延期或者項目失敗。
4.2 持續集成定義
大師Martin Fowler對持續集成是這樣定義的:
持續集成是一種軟件開發實踐，即團隊開發成員經常集成它們的工作，通常每個成員每天至少集成一次，也就意味著每天可能會發生多次集成。每次集成都通過自動化的構建（包括編譯，發布，自動化測試)來驗證，從而盡快地發現集成錯誤。許多團隊發現這個過程可以大大減少集成的問題，讓團隊能夠更快的開發內聚的軟件。
4.3 持續集成的價值
-
減少風險
一天中進行多次的集成，并做了相應的測試，這樣有利于檢查缺陷，了解軟件的健康狀況，減少假定。
-
減少重復過程
減少重復的過程可以節省時間、費用和工作量。說起來簡單，做起來難。這些浪費時間的重復勞動可能在我們的項目活動的任何一個環節發生，包括代碼編譯、數據庫集成、測試、審查、部署及反饋。通過自動化的持續集成可以將這些重復的動作都變成自動化的，無需太多人工干預，讓人們的時間更多的投入到動腦筋的、更高價值的事情上。
-
任何時間、任何地點生成可部署的軟件
持續集成可以讓您在任何時間發布可以部署的軟件。從外界來看，這是持續集成最明顯的好處，我們可以對改進軟件品質和減少風險說起來滔滔不絕，但對于客戶來說，可以部署的軟件產品是最實際的資產。利用持續集成，您可以經常對源代碼進行一些小改動，并將這些改動和其他的代碼進行集成。如果出現問題，項目成員馬上就會被通知到，問題會第一時間被修復。不采用持續集成的情況下，這些問題有可能到交付前的集成測試的時候才發現，有可能會導致延遲發布產品，而在急于修復這些缺陷的時候又有可能引入新的缺陷，最終可能導致項目失敗。
-
增強項目的可見性
持續集成讓我們能夠注意到趨勢并進行有效的決策。如果沒有真實或最新的數據提供支持，項目就會遇到麻煩，每個人都會提出他最好的猜測。通常，項目成員通過手工收集這些信息，增加了負擔，也很耗時。持續集成可以帶來兩點積極效果：
(1)有效決策：持續集成系統為項目構建狀態和品質指標提供了及時的信息，有些持續集成系統可以報告功能完成度和缺陷率。
(2)注意到趨勢：由于經常集成，我們可以看到一些趨勢，如構建成功或失敗、總體品質以及其它的項目信息。
建立團隊對開發產品的信心
持續集成可以建立開發團隊對開發產品的信心，因為他們清楚的知道每一次構建的結果，他們知道他們對軟件的改動造成了哪些影響，結果怎么樣。
4.4 持續集成的要點
- 統一的代碼庫
- 自動構建
- 自動測試
- 每個人每天都要向代碼庫主干提交代碼
- 每次代碼遞交后都會在持續集成服務器上觸發一次構建
-
保證快速構建
-
模擬生產環境的自動測試
-
每個人都可以很容易的獲取最新可執行的應用程序
-
每個人都清楚正在發生的狀況
-
自動化的部署
4.5 持續集成的原則
-
所有的開發人員需要在本地機器上做本地構建，然后再提交到版本控制庫中，從而確保他們的變更不會導致持續集成失敗。
-
開發人員每天至少向版本控制庫中提交一次代碼。
-
開發人員每天至少需要從版本控制庫中更新一次代碼到本地機器。
-
需要有專門的集成服務器來執行集成構建,每天要執行多次構建。
-
每次構建都要100%通過。
-
每次構建都可以生成可發布的產品。
-
修復失敗的構建是優先級最高的事情。
-
測試是未來，未來是測試。
4.6 持續集成的工作流程
持續集成（Continuous integration，簡稱CI）是軟件的開發和發布標準流程中最重要的部分。作為一種開發實踐，在CI中可以通過自動化等手段高頻率地去獲取產品反饋并響應反饋的過程。簡單來說，就是持續不斷地（一天多次）將代碼合并（集成）到主干源碼倉庫，讓產品可以快速迭代，同時保持高質量。
持續集成強調對于開發人員的每個提交，立刻進行構建、掃描、（單元）測試。根據結果，我們可以確定新代碼和原有代碼能否正確地集成在一起。如一個完整的CI系統應該包含3個基本模塊：
一個可以自動構建的過程，自動編譯代碼，可以自動分發，部署和測試。
一個代碼倉庫，例如Git。
一個持續集成的服務器。
如圖 3是典型的持續集成流程圖。
圖3持續集成流程圖
正如圖3持續集成流程所示，通用的持續集成（CI）流程主要包括：
-
簽出代碼：
從源碼管理系統里簽出或者克隆最新的代碼到本地開發環境
-
提交（commit）：
基于主干分支創建一個新的功能分支，并在此分支編寫代碼，并向倉庫提交代碼
-
測試（第1輪）：代碼倉庫對commit操作配置了鉤子（hook）， 每一次提交代碼都會觸發測試。單元測試（針對函數或模塊的測試）和功能測試（集成測試）將會被執行、根據需要設置是否執行端對端測試。一般來說，這些測試也會被打包到代碼里。
-
構建（build）：通過測試（第1輪）后，將源碼轉換為可以運行的實際代碼，比如安裝依賴，配置各種資源等。
-
測試（第2輪）：以自動化為主的全面測試，包括單元測試和集成測試，必要時做端對端測試，確保新版本的每一個更新點都必須測試到。
-
合并：通過測試（第2輪）后，將代碼更新集成到主干。
-
回滾：如果當前版本發生問題，就回滾到上一個版本的構建結果一般來說，CI服務器會配置成在遇到故障時發送郵件相關人員，可以快速知曉故障并且盡快采取更正措施。
4.7 持續集成注意事項
當需要代碼變更并集成時，開發者會從基礎代碼庫復制以進行作業，其他開發者提交代碼的變更至來源代碼庫，并透過副本的方式取代來源代碼庫的代碼。不只變更目前的代碼庫，新的代碼也可以新增成為程序庫、其它共享資源與潛在沖突。
當分支代碼開發者進行主線重新集成時，當分支代碼保持在取出狀態時間越長，就愈容易遭遇集成多重沖突的風險以及集成失敗。因為他們拿到的是副本，所以當開發者將代碼提交到代碼庫時，首先必須更新代碼以反映他們在代碼庫中的更改。代碼庫包含的更改越多，開發人員在提交自己的更改前必須運行的基礎工作就越多。
最終，該程序庫也許變成非常不同于開發者的目標代碼，他們進入有時候被稱為合并地獄或集成地獄的階段，這時候開發者所花費的集成時間，將超過最初代碼開發的時間。
持續集成涉及預先集成與預先與經常性的集成，借此來避免掉入集成地獄的陷阱，實踐的目標是減少重工、減少成本與時間。
持續集成補充的實踐是在提交代碼之前，每個開發人員必須運行一個完整的構建并通過所有的單元測試、集成測試。當持續集成服務器偵測到代碼有新的提交時，必須經常性與自動化的進行此類單元測試或集成測試任務。代碼每次集成到主干之前，必須通過自動化測試，以便快速發現和定位錯誤。值得注意的是，持續集成并不能消除錯誤，而是讓它們非常容易發現和改正。
轉載汽車電子相關文章
轉自汽車電子與軟件
