軟件工程理論與實踐 課件 第2章 敏捷軟件開發(fā)-1

第2章敏捷軟件開發(fā)

目錄22.1敏捷方法2.2Scrum2.3看板2.4極限編程（XP）2.5CI／CD2.1敏捷方法概念與價值觀原則與方法概述敏捷軟件開發(fā)是軟件開發(fā)行業(yè)的一個大流行語，它是管理軟件開發(fā)項目的一種不同方式。它不是一種特定的軟件開發(fā)方法，而是一組基于敏捷軟件開發(fā)宣言中表達(dá)的價值和原則的方法和實踐的總稱。4概念及價值觀敏捷軟件開發(fā)開始于“敏捷軟件開發(fā)宣言”。在2001年2月，17位軟件開發(fā)方法學(xué)家在美國猶他州召開了長達(dá)兩天的會議，制訂并簽署了“敏捷軟件開發(fā)宣言”，該宣言給出了4個價值觀：個體與交互高于過程和工具可運行軟件高于詳盡的文檔與客戶協(xié)作高于合同（契約）談判對變更及時響應(yīng)高于遵循計劃5“敏捷聯(lián)盟”制定的12條原則可工作的軟件是進(jìn)度的首要度量標(biāo)準(zhǔn)敏捷過程提倡可持續(xù)的開發(fā)速度。不斷地關(guān)注優(yōu)秀的技能和良好的設(shè)計會增強(qiáng)敏捷能力。盡量使工作簡單化。

好的架構(gòu)、需求和設(shè)計來源于自身組織團(tuán)隊。每隔一定時間,團(tuán)隊?wèi)?yīng)該反省如何才能有效地工作,并相應(yīng)地調(diào)整自己的行為。6通過盡早和持續(xù)交付有價值的軟件來讓客戶滿意需求變更可以發(fā)生在整個軟件的開發(fā)過程中經(jīng)常交付可工作的軟件

業(yè)務(wù)人員和開發(fā)人員應(yīng)該天天在一起工作圍繞受激勵的個人構(gòu)建項目在團(tuán)隊的內(nèi)部,最有效果和效率的信息傳遞方法是面對面交談。不同的敏捷方法最廣泛使用的敏捷方法包括：Scrum極限編程（XP）看板（Kanban）特征驅(qū)動開發(fā)精益軟件開發(fā)水晶（Crystal）動態(tài)系統(tǒng)開發(fā)方法7敏捷軟件開發(fā)方法如左圖，是敏捷開發(fā)流程的舉例。82.2Scrum概述Sprint每日站會用戶故事Backlog結(jié)對編程2.2.1概述Scrum中的三種角色產(chǎn)品經(jīng)理：產(chǎn)品經(jīng)理負(fù)責(zé)規(guī)劃產(chǎn)品，并將研發(fā)這種產(chǎn)品的愿景傳達(dá)給團(tuán)隊。敏捷主管（ScrumMaster）：ScrumMaster幫助團(tuán)隊盡其所能地完成工作。ScrumMaster對團(tuán)隊成員在做的事情沒有指揮權(quán)，但對這一過程擁有指揮權(quán)。Scrum團(tuán)隊：Scrum團(tuán)隊由5~7名成員組成。與傳統(tǒng)的開發(fā)團(tuán)隊不同，成員們沒有固定角色。團(tuán)隊成員間相互幫助、共享成果，旨在完成全部的工作。Scrum團(tuán)隊需要做好整體規(guī)劃，并為每次迭代劃分合適的工作量。10Scrum有一套其獨特且固定的管理方式，從角色、工件和不同形式的會議三個維度出發(fā)，來保證執(zhí)行過程更高效。例如在每次Sprint開始前會確立整個過程：迭代規(guī)劃、每日站會、迭代演示和回顧，并在Sprint期間用可視化工件確認(rèn)進(jìn)度和收集客戶反饋。2.2.1概述11Scrum的會議步驟整理產(chǎn)品需求清單確定迭代規(guī)劃梳理產(chǎn)品需求清單每日站會迭代演示迭代回顧2.2.1概述Scrum項目所需的常用工件Scrum任務(wù)板：用戶可以用Scrum任務(wù)板使Sprint任務(wù)清單形象化。任務(wù)板可以用不同的形式來呈現(xiàn)，比較傳統(tǒng)的做法有索引卡，便利貼或白板。Scrum任務(wù)板通常分為三列：待辦事項，正在進(jìn)行中和已完成。團(tuán)隊需要在整個Sprint過程中不斷更新。用戶故事：用戶故事是從客戶角度對軟件提出功能的描述。它包括用戶類型細(xì)分，他們想要什么以及他們?yōu)槭裁葱枰Ｈ急M圖：縱軸表示任務(wù)總量估計，橫軸表示迭代時間。剩下工作可以通過不同的點位或者其他的指標(biāo)來表示。122.2.2SprintSprint（沖刺）是Scrum團(tuán)隊一起完成增量工作的實際時間段。敏捷專家DaveWest建議，工作越復(fù)雜，未知數(shù)越多，沖刺應(yīng)該越短。但這實際上取決于具體的團(tuán)隊情況所有的事件——從計劃到回顧——都發(fā)生在Sprint階段。一旦一個Sprint的時長被確定，它就必須在整個開發(fā)期間保持一致。132.2.3每日站會14這是一個每天在同一時間（通常是上午）和地點舉行的超短會議，以保持會議的簡單性。每日Scrum的目標(biāo)是讓團(tuán)隊中的每個人都保持同步，與Sprint目標(biāo)保持一致，并為接下來的24小時制定計劃。一種常見的開站會的方法是讓每個團(tuán)隊成員回答如下三個關(guān)于實現(xiàn)Sprint目標(biāo)的問題：我昨天做了什么？我今天計劃做什么？有什么問題嗎？2.2.4用戶故事3C原則卡片（Card）：用戶故事一般寫在小的記事卡片上?？ㄆ峡赡軙懮瞎适碌暮喍堂枋觯ぷ髁抗浪愕?。交談（Conversation）：用戶故事背后的細(xì)節(jié)來源于和客戶或者產(chǎn)品負(fù)責(zé)人的交流溝通。確認(rèn)（Confirmation）：通過驗收測試確認(rèn)用戶故事被正確完成。15實際開發(fā)流程中，最為重要的是做好用戶故事的劃分。用戶故事是從用戶的角度來描述用戶渴望得到的功能。用戶的三個要素：角色：誰要使用這個功能活動：需要完成什么樣的功能商業(yè)價值：為什么需要這個功能，這個功能帶來什么樣的價值INVEST原則獨立性（Independent）

可協(xié)商性（Negotiable）有價值（Valuable）

可以估算性（Estimatable）短小（Small）

可測試性（Testable）2.2.4用戶故事右圖為實際開發(fā)記錄舉例162.2.5BacklogBacklog的關(guān)鍵要點如下所述清楚地表述列表中每個需求任務(wù)給用戶帶來的價值,作為優(yōu)先級排序的重要參考動態(tài)的需求管理而非“凍結(jié)”方式需求分析的過程是可迭代的17Backlog是Scrum中經(jīng)過優(yōu)先級排序的動態(tài)刷新的產(chǎn)品需求清單，用來制定發(fā)布計劃和迭代計劃。使用Backlog可以通過需求的動態(tài)管理應(yīng)對變化，避免浪費，并且易于優(yōu)先交付對用戶價值高的需求。

2.2.6結(jié)對編程結(jié)對編程的好處程序員通?？梢愿斓亟鉀Q問題由于兩個程序員具有相同缺點和盲點的可能性要小得多,因此可出現(xiàn)更少的錯誤,可縮短測試的時間和降低測試的成本程序員之間的互相激勵、幫助和監(jiān)督,可降低編程的枯燥性和程序員懶惰的可能性個別的人員流動對項目進(jìn)展造成的影響就會相對小。概念：結(jié)對編程,即兩個程序員肩并肩地坐在同一臺計算機(jī)前合作編程,在一個程序員編程的同時,另一個負(fù)責(zé)檢查代碼的正確性和可讀性。182.3看板概述Scrum與看板的區(qū)別2.3.1概述20看板作為可視化框架可以用于敏捷方法，能夠清晰地向項目成員展示整個項目進(jìn)度。當(dāng)需要對系統(tǒng)進(jìn)行小幅度改動的時候，可以采用看板方法來輕量化解決這個問題，因為看板本身并不需要額外去制定流程。看板圖是項目中實施看板的常見工具。2.3.1概述無論用哪種形式來創(chuàng)建看板圖，看板都會有一個原則：劃分為不同列來代表其工作狀態(tài)?？窗屙椖堪ㄈ缦?條核心原則：可視化工作流程限制工作進(jìn)度管理和改進(jìn)流程制定明確的執(zhí)行策略持續(xù)改進(jìn)212.3.2Scrum與看板的區(qū)別Scrum與看板有所不同，看板對團(tuán)隊的個人能力要求較高，更靈活，適合新開發(fā)的產(chǎn)品，而Scrum適合成熟一點的產(chǎn)品和團(tuán)隊。在實際的小團(tuán)隊項目敏捷開發(fā)中，Scrum和看板都是不錯的選擇，且可視具體情況，靈活調(diào)整迭代的周期，在兩種模式上進(jìn)行自定義的微調(diào)。222.3.2Scrum與看板的區(qū)別如果團(tuán)隊需要在某特定的時間發(fā)布或推廣產(chǎn)品，以達(dá)到一定的市場預(yù)期的話，則團(tuán)隊一般會將需求進(jìn)行拆分和細(xì)化，拆分為較小的需求后，團(tuán)隊可以通過檢查每個Sprint的進(jìn)度并進(jìn)行調(diào)整，從而預(yù)測交付時間，進(jìn)而確保整個項目成功交付，這時Scrum是首選的方式。其次，由于Scrum承諾在每個Sprint內(nèi)不對計劃做修改，如果團(tuán)隊經(jīng)常會應(yīng)對緊急情況或者修改任務(wù)的優(yōu)先級，那么看板方法因其靈活的工作流程可以更好地適應(yīng)。再者，在Scrum中每個Sprint的時間長度是固定的（1~4周），并且每個Sprint結(jié)束后會交付潛在可交付產(chǎn)品的增量，如果項目需要有固定的交付時間（1~4周），那么Scrum是比較好的選擇。最后如果團(tuán)隊不足5人，在人員方面可能無法發(fā)揮Scrum的最大功效或存在一定的浪費，那么建議使用看板方法。232.3.2Scrum與看板的區(qū)別24Scrum看板開發(fā)方式要求定時迭代沒指定定時限迭代，可以分開計劃、發(fā)布、過程改進(jìn)，可以事件驅(qū)動而不是限定時限團(tuán)隊在每個迭代承諾一定數(shù)目的工作承諾不是必須的以速度（Velocity）作為計劃和過程改進(jìn)的度量數(shù)據(jù)使用開發(fā)周期作為計劃和過程改進(jìn)的度量數(shù)據(jù)指定跨功能團(tuán)隊沒有指定跨功能團(tuán)隊，也容許專門團(tuán)隊工作任務(wù)細(xì)分，可于一個迭代中完成沒有指定工作任務(wù)大小指定使用燃燒圖沒有指定任何圖表2.3.2Scrum與看板的區(qū)別25Scrum看板開發(fā)方式間接限制開發(fā)中工作（每個迭代）設(shè)定開發(fā)中工作的限制（每個工作流程狀態(tài)）規(guī)定估算過程沒有指定任何估算方式在迭代中不能加入新工作任務(wù)只要生產(chǎn)力容許，可以隨時加工作任務(wù)由單一團(tuán)隊負(fù)責(zé)SprintBacklog多個團(tuán)隊和團(tuán)員分享看板指定3個角色（產(chǎn)品經(jīng)理、ScrumMaster、Scrum團(tuán)隊）沒有指定任何團(tuán)隊角色Scrumboard在每個迭代后重設(shè)看板反映持久開發(fā)情況規(guī)定優(yōu)先化的productbacklog優(yōu)先級是非必須的2.4極限編程概述XP的四個價值觀2.4.1概述極限編程是一種實踐性較強(qiáng)的規(guī)范化的軟件開發(fā)方法，它強(qiáng)調(diào)用戶需求和團(tuán)隊工作。XP特別適用于軟件需求模糊且容易改變、開發(fā)團(tuán)隊人數(shù)少于10人、開發(fā)地點集中（比如一個辦公室）的場合。極限編程包含了一組相互作用和相互影響的規(guī)則和實踐。在項目計劃階段，需要建立合理和簡潔的用戶故事。在設(shè)計系統(tǒng)的體系架構(gòu)時，可以采用CRC（Class，Responsibility，Collaboration）卡促使團(tuán)隊成員共同努力。代碼的質(zhì)量在極限編程項目中非常重要。為了保證代碼的質(zhì)量，可以采用結(jié)對編程以及在編碼之前構(gòu)造測試用例等措施。合理的測試用例及較高的測試覆蓋率是極限編程項目測試所追求的目標(biāo)。272.4.1極限編程XP所推崇的規(guī)則和方法如右圖所示282.4.2XP的4個價值觀交流：交流不僅能使相關(guān)人員更為精確的理解需求，而是能夠盡可能避免因為需求變

更導(dǎo)致的不一致.簡單：簡單是XP推崇的理念，一切都使用最簡單、最小代價的方式達(dá)到目的，以及用最簡潔的達(dá)到客戶的要求。反饋：及時高效的反饋能夠確保開發(fā)工作的正確性，并能夠在發(fā)生錯誤時更及時地糾正偏差。勇氣：敏捷方法要求與其他人密切的合作，充分信任他人，也信任自己，這需要勇氣292.4.3XP的 12個核心實踐完整的團(tuán)隊

結(jié)對編程計劃策略

設(shè)計改進(jìn)系統(tǒng)隱喻

持續(xù)集成小型發(fā)布

集體所有權(quán)測試驅(qū)動

編碼標(biāo)準(zhǔn)簡單設(shè)計

工作安排302.5CI/CD概述CI/CD的優(yōu)勢2.5.1CI/CD概述CI/CD是一套使軟件開發(fā)的構(gòu)建、測試和部署階段自動化的方法。自動化可縮短交付時間，并提高整個開發(fā)生命周期的可靠性。CI/CD中的CI代表持續(xù)集成。CD是指連續(xù)交付或連續(xù)部署，具體取決于團(tuán)隊選擇如何推動代碼更改以進(jìn)行生產(chǎn)。持續(xù)集成和持續(xù)交付是CI/CD中的兩個不同流程，具有不同的用途CI完成自動構(gòu)建和測試步驟，以確保代碼更改能夠可靠合理地合并到代碼倉庫中CD提供了向最終用戶交付代碼地快速無縫方法CI／CD的目標(biāo)是幫助開發(fā)人員以速度和效率交付軟件。團(tuán)隊不斷將代碼交付到生產(chǎn)中，運行新功能和錯誤修復(fù)的持續(xù)流程。CI／CD概覽如圖所示322.5.1CI/CD概述持續(xù)集成（CI）：持續(xù)集成是不斷將更新集成到代碼庫的方法。CI提供一個一致的自動化流程，包括構(gòu)建、測試和合并新軟件。持續(xù)交付（CD）：持續(xù)交付是指持續(xù)地將各類更改(包括新功能、缺陷修復(fù)、配置變化等)安全、快速、高質(zhì)量地落實到生產(chǎn)環(huán)境或用戶手中的能力。持續(xù)交付從持續(xù)集成結(jié)束的地方開始。CD使開發(fā)人員能夠隨時向不同的環(huán)境和最終用戶部署常規(guī)軟件更改。所有進(jìn)入CD過程的代碼必須首先通過CI。持續(xù)測試：持續(xù)測試是運行自動測試的方法，而代碼更改則通過CI和CD進(jìn)行。332.5.1CI/CD概述單個CI/CD過程可以具有多種類型的測試單元測試（確保單個功能在構(gòu)建過程中正確執(zhí)行的CI測試）集成測試（檢查組件和服務(wù)是否都協(xié)同工作）功能測試（確保功能按團(tuán)隊預(yù)期執(zhí)行）驗收測試（性能、可擴(kuò)展性、應(yīng)力、容量等）靜態(tài)代碼分析（檢查語法問題和漏洞）自動測試（如API測試和安全測試）并非每個CI/CD過程都需要有所有這些測試，但持續(xù)測試的目標(biāo)始終相同。342.5.2CI/CD的優(yōu)勢更快、更可靠的版本發(fā)布更高的可見性早期錯誤檢測快速反饋循環(huán)更快樂的開發(fā)和運維團(tuán)隊352.6DevOps概述生命周期敏捷軟件開發(fā)、CI/CD和DevOps工具概述DevOps是從敏捷發(fā)展起來的。它添加了新的過程和工具，將CI/CD的持續(xù)迭代和自動化擴(kuò)展到軟件交付生命周期的其余部分。在流程的每一個步驟中，它實現(xiàn)了開發(fā)和運維之間的密切協(xié)作。37