敏捷開發(fā)

1.1 什么是敏捷?

       敏捷是用于描述軟件開發(fā)方法的術語，強調(diào)增量交付、團隊協(xié)作、持續(xù)規(guī)劃和持續(xù)學習。"敏捷"一詞源于2001年《敏捷宣言》。宣言旨在確立指導軟件開發(fā)更優(yōu)方法的原則。其核心是宣布代表敏捷運動基礎的4項價值觀：

• 個體和交互 勝過 過程和工具
• 可以工作的軟件 勝過 面面俱到的文檔
• 客戶合作 勝過 合同談判

• 響應變化 勝過 遵循計劃

      依據(jù)以上四條價值觀，衍生出來更具體的十二大原則，作為對敏捷宣言更具實操性的解釋，其具體原則內(nèi)容如下：

      1) 最重要的是通過盡早和不斷交付有價值的軟件滿足客戶需要。

      2) 我們歡迎需求的變化，即使在開發(fā)后期。敏捷過程能夠駕馭變化，保持客戶的競爭優(yōu)勢。

      3) 經(jīng)常交付可以工作的軟件，從幾星期到幾個月，時間尺度越短越好。

      4) 業(yè)務人員和開發(fā)者應該在整個項目過程中始終朝夕在一起工作。

      5) 圍繞斗志高昂的人進行軟件開發(fā)，給開發(fā)者提供適宜的環(huán)境，滿足他們的需要，并相信他們能夠完成任務。

      6) 在開發(fā)小組中最有效率也最有效果的信息傳達方式是面對面的交談。

      7) 可以工作的軟件是進度的主要度量標準。

      8) 敏捷過程提倡可持續(xù)開發(fā)。出資人、開發(fā)人員和用戶應該總是維持不變的節(jié)奏。

      9) 對卓越技術與良好設計的不斷追求將有助于提高敏捷性。

    10) 簡單——盡可能減少工作量的藝術至關重要。

    11) 最好的架構(gòu)、需求和設計都源自自我組織的團隊。

    12) 每隔一定時間，團隊都要總結(jié)如何更有效率，然后相應地調(diào)整自己的行為。

1.2 敏捷開發(fā)概念與特點

      敏捷開發(fā)是一種從1990年代開始逐漸引起廣泛關注的新型軟件開發(fā)方法，是一種應對快速變化的需求的一種軟件開發(fā)能力。它們的具體名稱、理念、過程、術語都不盡相同，相對于“非敏捷”，更強調(diào)程序員團隊與業(yè)務專家之間的緊密協(xié)作、面對面的溝通、頻繁交付新的軟件版本、緊湊而自我組織型的團隊、能夠很好地適應需求變化的代碼編寫和團隊組織方法，也更注重軟件開發(fā)中人的作用。

敏捷開發(fā)是用于描述迭代軟件開發(fā)的術語。敏捷開發(fā)通常與傳統(tǒng)或瀑布開發(fā)形成對比，在傳統(tǒng)或瀑布開發(fā)中，大型項目是按照該計劃進行規(guī)劃和執(zhí)行的。

      敏捷開發(fā)以用戶的需求進化為核心，采用迭代、循序漸進的方法進行軟件開發(fā)。在敏捷開發(fā)中，軟件項目在構(gòu)建初期被切分成多個子項目，各個子項目的成果都經(jīng)過測試，具備可視、可集成和可運行使用的特征。換言之，就是把一個大項目分為多個相互聯(lián)系，但也可獨立運行的小項目，并分別完成，在此過程中軟件一直處于可使用狀態(tài)。迭代軟件開發(fā)縮短了軟件開發(fā)生命周期。

1.3 敏捷開發(fā)流程

      敏捷開發(fā)團隊以較小的增量執(zhí)行整個軟件開發(fā)生命周期，通常稱為沖刺（sprint）。沖刺通常有1-4周長。每次沖刺交付產(chǎn)品級代碼都需要敏捷的開發(fā)團隊來應對加速的步伐。所有編碼、測試和質(zhì)量驗證都必須在每個沖刺階段完成。各團隊間應密切協(xié)作，否則可能會導致失敗甚至慘敗。

圖1：敏捷開發(fā)流程示意圖

      敏捷開發(fā)團隊幾個關鍵的成功因素：

      1. 細化需求列表

      2. 早期并高頻集成

      3. 盡量避免技術缺陷

1.4 敏捷方法與最佳實踐

       敏捷是一種尋找軟件開發(fā)方法的態(tài)度。敏捷方法中沒有一種方法適用于所有情況，而"敏捷"一詞已經(jīng)代表與宣言中的價值陳述一致的各種敏捷方法與最佳實踐。

       敏捷方法是一個囊括了各種框架和方法的涵蓋性術語，它指的是符合《敏捷宣言》價值觀和原則的任何方法、技術、框架、手段或?qū)嵺`。敏捷方法（通常稱為敏捷框架）是軟件開發(fā)生命周期階段（規(guī)劃、執(zhí)行和交付）的綜合方法。它規(guī)定了一套在明確的指導和原則下完成工作的方法。

      敏捷方法主要包括SCRUM方法、DSDM 方法、水晶方法、特性驅(qū)動方法和 SCRUMBAN 等。例如Scrum是最常見的敏捷框架。持續(xù)集成（Continuous Integration，CI）是常見的敏捷工程實踐方法。

需要說明的是，敏捷方法與最佳實踐并不承諾解決每一個問題，但他們確實承諾建立一個文化和環(huán)境，通過協(xié)作，不斷的規(guī)劃和學習，并快速迭代交付高質(zhì)量的軟件，最終滿足客戶需求。

2. 

SCRUM方法

2.1 SCRUM綜述

       Scrum 是團隊用于管理其工作的框架，將敏捷原則作為一套具體的工件、實踐和角色，通常用于敏捷軟件開發(fā)。具體來說，Scrum 是用于開發(fā)、交付和持續(xù)支持復雜產(chǎn)品的一個框架，是一個增量的、迭代的開發(fā)過程。Scrum起源于軟件開發(fā)項目，Scrum包括了一系列實踐和預定義角色的過程骨架。Scrum中的主要角色包括同項目經(jīng)理類似的Scrum主管角色負責維護過程和任務，產(chǎn)品負責人代表利益所有者，開發(fā)團隊包括了所有開發(fā)人員。雖然Scrum是為管理軟件開發(fā)項目而開發(fā)的，它同樣可以用于運行軟件維護團隊，或者作為計劃管理方法，適用于任何復雜的或是創(chuàng)新性的項目。如Scrum 目前已被用于開發(fā)軟件、硬件、嵌入式軟件、交互功能網(wǎng)絡、自動駕駛、學校、政府、市場、管理組織運營，以及日常生活中更廣泛的產(chǎn)品開發(fā)領域。

2.2 SCRUM流程

       Scrum整個開發(fā)流程(見圖2) 由若干個短的迭代周期組成，一個短的迭代周期稱為一個Sprint，每個Sprint的建議長度是一至四周。在Scrum中，使用產(chǎn)品Backlog來管理產(chǎn)品的需求，產(chǎn)品backlog是一個按照商業(yè)價值排序的需求列表，列表條目的體現(xiàn)形式通常為用戶故事。Scrum團隊總是先開發(fā)對客戶具有較高價值的需求。在Sprint中，Scrum團隊從產(chǎn)品Backlog中挑選最高優(yōu)先級的需求進行開發(fā)。挑選的需求在Sprint計劃會議上經(jīng)過討論、分析和估算得到相應的任務列表，我們稱它為Sprint backlog。在每個迭代結(jié)束時，Scrum團隊將提交潛在可交付的產(chǎn)品增量。

圖2 Scrum流程圖

2.3 SCRUM框架

      Scrum框架包括3個角色、3個工件、5個事件、5個價值：3個角色：產(chǎn)品負責人（Product Owner）、Scrum Master、開發(fā)團隊3個工件：產(chǎn)品Backlog（Product Backlog）、SprintBacklog、產(chǎn)品增量（Increment）5個事件：Sprint（Sprint本身是一個事件，包括了如下4個事件）、Sprint計劃會議（Sprint Planning Meeting）、每日站會（Daily Scrum Meeting）、Sprint評審會議（Sprint Review Meeting）、Sprint回顧會議（Sprint Retrospective Meeting）

       5個價值：承諾 – 愿意對目標做出承諾、專注– 把你的心思和能力都用到你承諾的工作上去、開放– Scrum 把項目中的一切開放給每個人看、尊重– 每個人都有他獨特的背景和經(jīng)驗、勇氣– 有勇氣做出承諾，履行承諾，接受別人的尊重

3.

DevOps

3.1 DevOps 定義

      DevOps 是開發(fā) (Dev) 和運營 (Ops) 的復合詞，是一組過程、方法與系統(tǒng)的統(tǒng)稱，用于促進開發(fā)（應用程序/軟件工程）、技術運營和質(zhì)量保障（QA）部門之間的溝通、協(xié)作與整合。

3.2 DevOps 發(fā)展背景

      傳統(tǒng)的軟件組織將開發(fā)、IT運營和質(zhì)量保障設為各自分離的部門。在這種環(huán)境下如何采用新的開發(fā)方法（例如敏捷軟件開發(fā)），這是一個重要的課題：按照從前的工作方式，開發(fā)和部署不需要IT支持或者QA深入的、跨部門的支持，而卻需要極其緊密的多部門協(xié)作。然而DevOps考慮的還不止是軟件部署。它是一套針對這幾個部門間溝通與協(xié)作問題的流程和方法[9]。

      以下幾方面因素可能促使一個組織引入DevOps：

      1、使用敏捷或其他軟件開發(fā)過程與方法

      2、業(yè)務負責人要求加快產(chǎn)品交付的速率

      3、虛擬化和云計算基礎設施（可能來自內(nèi)部或外部供應商）日益普遍

      4、數(shù)據(jù)中心自動化技術和配置管理工具的普及

      5、有一種觀點認為，占主導地位的“傳統(tǒng)”美國式管理風格（“斯隆模型 vs 豐田模型”）會導致“煙囪式自動化”，從而造成開發(fā)與運營之間的鴻溝，因此需要DevOps能力來克服由此引發(fā)的問題。

      DevOps經(jīng)常被描述為“開發(fā)團隊與運營團隊之間更具協(xié)作性、更高效的關系”。由于團隊間協(xié)作關系的改善，整個組織的效率因此得到提升，伴隨頻繁變化而來的生產(chǎn)環(huán)境的風險也能得到降低。

      在云計算、大數(shù)據(jù)等技術顛覆性趨勢繼續(xù)在應用經(jīng)濟下發(fā)揮作用的同時，DevOps也已經(jīng)穩(wěn)健地在業(yè)務思維方式中占有一席之地，并將扮演主要角色。在應用驅(qū)動、云連接、移動化的大環(huán)境下，對于很多公司來說DevOps是助力業(yè)務增值戰(zhàn)略的第一步。

      緊跟行業(yè)趨勢、進行新的技術變革往往會帶來發(fā)展的陣痛，DevOps也同樣要經(jīng)歷這一過程。中國及全球各地的企業(yè)正在認識到DevOps可以助力軟件開發(fā)速度加快，軟件應用質(zhì)量提升，更重要的是與業(yè)務目標更完美地結(jié)合。

3.3 DevOps 文化

       1) 協(xié)作、可見性和一致性

       健康的 DevOps 文化的一個標志是團隊間能夠協(xié)作，首要的便是可見性。開發(fā)和 IT 運營等不同團隊必須能夠相互分享 DevOps 流程、優(yōu)先級和關注點。這些團隊還必須能夠共同規(guī)劃工作，并統(tǒng)一與業(yè)務相關的成功目標和衡量標準。

       2) 范圍和責任的轉(zhuǎn)變

       當團隊統(tǒng)一時，他們擁有所有權(quán)并參與其他生命周期階段，而不僅僅是他們的角色對應的階段。例如，開發(fā)人員不僅要對開發(fā)階段的創(chuàng)新和質(zhì)量負責，還要對他們的改變在運營階段帶來的性能和穩(wěn)定性負責。同時，IT 操作員一定要在規(guī)劃和開發(fā)階段中考慮治理、安全性和符合性。

       3) 縮短發(fā)布周期

       DevOps 團隊通過短周期發(fā)布軟件保持敏捷。因為進度是漸進式的，縮短發(fā)布周期可以讓計劃和風險管理更容易，同時也減少了對系統(tǒng)穩(wěn)定性的影響?？s短發(fā)布周期還可以讓組織適應和應對不斷變化的客戶需求和競爭壓力。

       4) 持續(xù)學習

       高績效的 DevOps 團隊形成了一種成長思維。他們快速失敗，然后將經(jīng)驗教訓融入到他們的流程中，不斷改進，提高客戶滿意度，加速創(chuàng)新和適應市場。DevOps 是一個旅程，所以總有成長的空間。

3.4 DevOps 和應用程序生命周期

      DevOps 影響應用程序生命周期的規(guī)劃、開發(fā)、交付和運營階段。每個階段都依賴于其他階段，并且這些階段并非特定于角色。在真正的 DevOps 文化中，每個角色在某種程度上說都涉及各個階段如圖 4。

圖 4 DevOps 和應用程序生命周期

3.5 DevOps 做法

      除了形成 DevOps 文化之外，團隊還通過在整個應用程序生命周期中實施特定做法，以充分利用 DevOps。

1. 持續(xù)集成和持續(xù)交付 (CI/CD)
2. 版本控制
3. 敏捷軟件開發(fā)
4. 基礎結(jié)構(gòu)即代碼
5. 配置管理

6. 持續(xù)監(jiān)控

      其中一些做法有助于加速、自動化和改進特定階段。有的跨越幾個階段，幫助團隊創(chuàng)建提高生產(chǎn)效率的無縫進程。

3.6 DevOps 工具

      無論是縱向集成還是橫向集成，DevOps都需要通過工具鏈與持續(xù)集成、交付、反饋與優(yōu)化進行端到端整合。如華為的軟件開發(fā)云服務, 基于二十幾年的研發(fā)實踐，融合DevOps理念方法，為企業(yè)提供一站式的云上開發(fā)工具平臺。華為軟件開發(fā)云提供項目管理、配置管理、代碼檢查、編譯構(gòu)建、測試、部署、發(fā)布等端到端地覆蓋全軟件生命周期的相關服務。類似的DevOps 工具數(shù)不勝數(shù)，常見的DevOps 生態(tài)圈工具如圖 5。

圖 5 DevOps 生態(tài)圈工具

3.7 DevOps 與Agile 的關聯(lián)

       DevOps 和 Agile 都是用于生產(chǎn)產(chǎn)品、進行發(fā)布或發(fā)行的現(xiàn)代軟件開發(fā)框架。DevOps 是一種文化，促進軟件開發(fā)和維護中所有角色之間的協(xié)作。Agile 是一種開發(fā)方法，在需求不斷變化的常見現(xiàn)實中保持工作效率和促進發(fā)布。DevOps 和 Agile 并不是相互排斥的，而是經(jīng)常搭配使用。

4.

持續(xù)集成

4.1 持續(xù)集成背景

      集成軟件的過程不是新問題，如果項目開發(fā)的規(guī)模比較小，比如一個人的項目，如果它對外部系統(tǒng)的依賴很小，那么軟件集成不是問題，但是隨著軟件項目復雜度的增加（即使增加一個人），就會對集成和確保軟件組件能夠在一起工作提出了更多的要求-要早集成，常集成。早集成，頻繁的集成幫助項目在早期發(fā)現(xiàn)項目風險和質(zhì)量問題，如果到后期才發(fā)現(xiàn)這些問題，解決問題代價很大，很有可能導致項目延期或者項目失敗。

4.2 持續(xù)集成定義

      大師Martin Fowler對持續(xù)集成是這樣定義的:

      持續(xù)集成是一種軟件開發(fā)實踐，即團隊開發(fā)成員經(jīng)常集成它們的工作，通常每個成員每天至少集成一次，也就意味著每天可能會發(fā)生多次集成。每次集成都通過自動化的構(gòu)建（包括編譯，發(fā)布，自動化測試)來驗證，從而盡快地發(fā)現(xiàn)集成錯誤。許多團隊發(fā)現(xiàn)這個過程可以大大減少集成的問題，讓團隊能夠更快的開發(fā)內(nèi)聚的軟件。

4.3 持續(xù)集成的價值

• 減少風險

        一天中進行多次的集成，并做了相應的測試，這樣有利于檢查缺陷，了解軟件的健康狀況，減少假定。

• 減少重復過程

       減少重復的過程可以節(jié)省時間、費用和工作量。說起來簡單，做起來難。這些浪費時間的重復勞動可能在我們的項目活動的任何一個環(huán)節(jié)發(fā)生，包括代碼編譯、數(shù)據(jù)庫集成、測試、審查、部署及反饋。通過自動化的持續(xù)集成可以將這些重復的動作都變成自動化的，無需太多人工干預，讓人們的時間更多的投入到動腦筋的、更高價值的事情上。

• 任何時間、任何地點生成可部署的軟件

       持續(xù)集成可以讓您在任何時間發(fā)布可以部署的軟件。從外界來看，這是持續(xù)集成最明顯的好處，我們可以對改進軟件品質(zhì)和減少風險說起來滔滔不絕，但對于客戶來說，可以部署的軟件產(chǎn)品是最實際的資產(chǎn)。利用持續(xù)集成，您可以經(jīng)常對源代碼進行一些小改動，并將這些改動和其他的代碼進行集成。如果出現(xiàn)問題，項目成員馬上就會被通知到，問題會第一時間被修復。不采用持續(xù)集成的情況下，這些問題有可能到交付前的集成測試的時候才發(fā)現(xiàn)，有可能會導致延遲發(fā)布產(chǎn)品，而在急于修復這些缺陷的時候又有可能引入新的缺陷，最終可能導致項目失敗。

• 增強項目的可見性

       持續(xù)集成讓我們能夠注意到趨勢并進行有效的決策。如果沒有真實或最新的數(shù)據(jù)提供支持，項目就會遇到麻煩，每個人都會提出他最好的猜測。通常，項目成員通過手工收集這些信息，增加了負擔，也很耗時。持續(xù)集成可以帶來兩點積極效果：

       (1)有效決策：持續(xù)集成系統(tǒng)為項目構(gòu)建狀態(tài)和品質(zhì)指標提供了及時的信息，有些持續(xù)集成系統(tǒng)可以報告功能完成度和缺陷率。

       (2)注意到趨勢：由于經(jīng)常集成，我們可以看到一些趨勢，如構(gòu)建成功或失敗、總體品質(zhì)以及其它的項目信息。

       建立團隊對開發(fā)產(chǎn)品的信心

       持續(xù)集成可以建立開發(fā)團隊對開發(fā)產(chǎn)品的信心，因為他們清楚的知道每一次構(gòu)建的結(jié)果，他們知道他們對軟件的改動造成了哪些影響，結(jié)果怎么樣。

4.4 持續(xù)集成的要點

1. 統(tǒng)一的代碼庫
2. 自動構(gòu)建
3. 自動測試
4. 每個人每天都要向代碼庫主干提交代碼
5. 每次代碼遞交后都會在持續(xù)集成服務器上觸發(fā)一次構(gòu)建

6. 保證快速構(gòu)建

7. 模擬生產(chǎn)環(huán)境的自動測試

8. 每個人都可以很容易的獲取最新可執(zhí)行的應用程序

9. 每個人都清楚正在發(fā)生的狀況

10. 自動化的部署

4.5 持續(xù)集成的原則

1. 所有的開發(fā)人員需要在本地機器上做本地構(gòu)建，然后再提交到版本控制庫中，從而確保他們的變更不會導致持續(xù)集成失敗。

2. 開發(fā)人員每天至少向版本控制庫中提交一次代碼。

3. 開發(fā)人員每天至少需要從版本控制庫中更新一次代碼到本地機器。

4. 需要有專門的集成服務器來執(zhí)行集成構(gòu)建,每天要執(zhí)行多次構(gòu)建。

5. 每次構(gòu)建都要100%通過。

6. 每次構(gòu)建都可以生成可發(fā)布的產(chǎn)品。

7. 修復失敗的構(gòu)建是優(yōu)先級最高的事情。

8. 測試是未來，未來是測試。

4.6 持續(xù)集成的工作流程

      持續(xù)集成（Continuous integration，簡稱CI）是軟件的開發(fā)和發(fā)布標準流程中最重要的部分。作為一種開發(fā)實踐，在CI中可以通過自動化等手段高頻率地去獲取產(chǎn)品反饋并響應反饋的過程。簡單來說，就是持續(xù)不斷地（一天多次）將代碼合并（集成）到主干源碼倉庫，讓產(chǎn)品可以快速迭代，同時保持高質(zhì)量。

      持續(xù)集成強調(diào)對于開發(fā)人員的每個提交，立刻進行構(gòu)建、掃描、（單元）測試。根據(jù)結(jié)果，我們可以確定新代碼和原有代碼能否正確地集成在一起。如一個完整的CI系統(tǒng)應該包含3個基本模塊：

      一個可以自動構(gòu)建的過程，自動編譯代碼，可以自動分發(fā)，部署和測試。

      一個代碼倉庫，例如Git。

      一個持續(xù)集成的服務器。

      如圖 3是典型的持續(xù)集成流程圖。

圖3持續(xù)集成流程圖

      正如圖3持續(xù)集成流程所示，通用的持續(xù)集成（CI）流程主要包括：

1. 簽出代碼：

     從源碼管理系統(tǒng)里簽出或者克隆最新的代碼到本地開發(fā)環(huán)境

1. 提交（commit）：

      基于主干分支創(chuàng)建一個新的功能分支，并在此分支編寫代碼，并向倉庫提交代碼

1. 測試（第1輪）：
   代碼倉庫對commit操作配置了鉤子（hook）， 每一次提交代碼都會觸發(fā)測試。
   單元測試（針對函數(shù)或模塊的測試）和功能測試（集成測試）將會被執(zhí)行、根據(jù)需要設置是否執(zhí)行端對端測試。
   一般來說，這些測試也會被打包到代碼里。

2. 構(gòu)建（build）：
   通過測試（第1輪）后，將源碼轉(zhuǎn)換為可以運行的實際代碼，比如安裝依賴，配置各種資源等。

      源代碼一般是自包含構(gòu)建的，即CI流程所需的構(gòu)建腳本是放在源碼倉庫里的。

1. 測試（第2輪）：
   以自動化為主的全面測試，包括單元測試和集成測試，必要時做端對端測試，確保新版本的每一個更新點都必須測試到。

2. 合并：
   通過測試（第2輪）后，將代碼更新集成到主干。

3. 回滾：
   如果當前版本發(fā)生問題，就回滾到上一個版本的構(gòu)建結(jié)果
   一般來說，CI服務器會配置成在遇到故障時發(fā)送郵件相關人員，可以快速知曉故障并且盡快采取更正措施。

4.7 持續(xù)集成注意事項

       當需要代碼變更并集成時，開發(fā)者會從基礎代碼庫復制以進行作業(yè)，其他開發(fā)者提交代碼的變更至來源代碼庫，并透過副本的方式取代來源代碼庫的代碼。不只變更目前的代碼庫，新的代碼也可以新增成為程序庫、其它共享資源與潛在沖突。

       當分支代碼開發(fā)者進行主線重新集成時，當分支代碼保持在取出狀態(tài)時間越長，就愈容易遭遇集成多重沖突的風險以及集成失敗。因為他們拿到的是副本，所以當開發(fā)者將代碼提交到代碼庫時，首先必須更新代碼以反映他們在代碼庫中的更改。代碼庫包含的更改越多，開發(fā)人員在提交自己的更改前必須運行的基礎工作就越多。

      最終，該程序庫也許變成非常不同于開發(fā)者的目標代碼，他們進入有時候被稱為合并地獄或集成地獄的階段，這時候開發(fā)者所花費的集成時間，將超過最初代碼開發(fā)的時間。

      持續(xù)集成涉及預先集成與預先與經(jīng)常性的集成，借此來避免掉入集成地獄的陷阱，實踐的目標是減少重工、減少成本與時間。

      持續(xù)集成補充的實踐是在提交代碼之前，每個開發(fā)人員必須運行一個完整的構(gòu)建并通過所有的單元測試、集成測試。當持續(xù)集成服務器偵測到代碼有新的提交時，必須經(jīng)常性與自動化的進行此類單元測試或集成測試任務。代碼每次集成到主干之前，必須通過自動化測試，以便快速發(fā)現(xiàn)和定位錯誤。值得注意的是，持續(xù)集成并不能消除錯誤，而是讓它們非常容易發(fā)現(xiàn)和改正。

轉(zhuǎn)載汽車電子相關文章

轉(zhuǎn)自汽車電子與軟件