敏捷視角下的過程

敏捷視角下的過程第1頁，共24頁，2023年，2月20日，星期五4.1敏捷是什么和許多管理方法概念不同，“敏捷”是從整體能力或表現(xiàn)的角度著眼的，它昭示了一種經(jīng)營方式，這是理解其意義的要點。敏捷性有兩個基本對象：整個企業(yè)（或組織）及對企業(yè)中的人：對于公司，敏捷是有利于在顧客機會持續(xù)而不可預測地變化的競爭環(huán)境中運作的能力。

對于個人，敏捷是對公司底線的作用能力，這個底線就是為響應不可預測地變化的顧客機會經(jīng)常地重組其人與技術(shù)資源。

敏捷軟件開發(fā)不是一個具體的過程，而是一個涵蓋性術(shù)語（umbrellaterm），用于概括具有類似基礎(chǔ)的方式和方法。這些方法，其中包括極限編程（ExtremeProgramming）、動態(tài)系統(tǒng)開發(fā)方法（DynamicSystemDevelopmentMethod）、SCRUM、Crystal和Lean等，都著眼于快速交付高質(zhì)量的工作軟件，并做到客戶滿意。第2頁，共24頁，2023年，2月20日，星期五敏捷原則：1.優(yōu)先級最高的是，通過早期和持續(xù)交付有價值的軟件來滿足客戶。

2.歡迎變更需求，即使在開發(fā)的后期提出。敏捷過程為客戶的競爭優(yōu)勢而控制變更。

3.以兩周到兩月為周期，頻繁地交付可運行的軟件，首推較短的時間定量。

4.在整個項目過程中，每一天開發(fā)人員都要和業(yè)務人員合作。

5.由個體推動項目的建設，為個體提供所需的環(huán)境，支持和信任。

6.在開發(fā)團隊中或開發(fā)團隊間傳遞信息的最為有效和高效的方法是面對面的交談。

7.衡量進展的重要尺度是可運行的軟件。

8.敏捷過程提介可持續(xù)的開發(fā)。

9.發(fā)起人，開發(fā)者和用戶應該步調(diào)一致。

10.不斷地關(guān)注技術(shù)上優(yōu)越的設計會提高敏捷性。

11.簡潔是最重要的，簡潔就是盡量減少工作量的藝術(shù)。

12.最佳的架構(gòu)，需求和設計來自于自組織的團隊。

13.團隊要定期反省如何使工作更有效，然后相應地調(diào)整行為。第3頁，共24頁，2023年，2月20日，星期五4.2敏捷過程是什么任何一個敏捷過程都可以由所強調(diào)的三個關(guān)鍵假設而識別出來：提前預測哪些需求是穩(wěn)定的以及哪些需求會變化非常困難。同樣，預測項目進行中客戶優(yōu)先級的變化也很困難。對很多軟件來說，設計和構(gòu)建是交錯進行的。事實上兩種活動應當順序開展。從制定計劃的角度來看，分析、設計、構(gòu)建和測試并不像我們所設想的那么容易預測。4.2.1敏捷開發(fā)的立場將敏捷軟件開發(fā)作為許多傳統(tǒng)軟件工程的對立面，它們在優(yōu)越性和適用性方面存在著許多爭論。沒有人反對敏捷，真正問題在于“什么是最佳實現(xiàn)途徑”。敏捷學派內(nèi)部，針對敏捷問題，也提出了很多有細微差異的過程模型。第4頁，共24頁，2023年，2月20日，星期五4.2.2人的因素敏捷軟件開發(fā)的擁護者花費了很多精力強調(diào)“人的因素”在成功敏捷開發(fā)中的重要性。敏捷開發(fā)團隊及成員必須具備以下一些特點：基本能力共同目標精誠合作決策能力模糊問題解決能力相互信任和尊重自我組織第5頁，共24頁，2023年，2月20日，星期五4.3敏捷過程模型4.3.1極限編程（eXtremeProgramming）

XP（eXtremeProgramming）方法是最引人注目的一種輕型開發(fā)方法。它規(guī)定了一組核心價值和方法，消除了大多數(shù)重量型過程的不必要產(chǎn)物，建立了一個漸進型開發(fā)過程。該方法將開發(fā)階段的4個活動（分析、設計、編碼和測試）混合在一起，在全過程中采用迭代增量開發(fā)、反饋修正和反復測試。它把軟件生命周期劃分為用戶故事、體系結(jié)構(gòu)、發(fā)布計劃、交互、接受測試和小型發(fā)布6個階段。

XP開發(fā)模型與傳統(tǒng)模型相比具有很大的不同，其核心思想是交流（Communication）、簡單（Simplicity）、反饋（Feedback）和進?。ˋggressiveness）。XP開發(fā)小組不僅包括開發(fā)人員，還包括管理人員和客戶。該模型強調(diào)小組內(nèi)成員之間要經(jīng)常進行交流，在盡量保證質(zhì)量可以運行的前提下力求過程和代碼的簡單化；來自客戶、開發(fā)人員和最終用戶的具體反饋意見可以提供更多的機會來調(diào)整設計，保證把握正確的開發(fā)方向。第6頁，共24頁，2023年，2月20日，星期五策劃設計編碼測試重構(gòu)用戶故事權(quán)值驗收測試準則迭代計劃簡單設計CRC卡Spike解決方案原型結(jié)對編程連續(xù)集成單元測試驗收測試軟件增量項目速度估算發(fā)布極限編程過程第7頁，共24頁，2023年，2月20日，星期五XP有四個核心價值是我們應該注意溝通：問題往往是由于開發(fā)人員與設計人員、設計人員與客戶之間的溝通不暢造成的簡單：應該盡量保持代碼的簡單，只要它能工作就可以與其實現(xiàn)一個復雜的的系統(tǒng)，不如設計一個能夠滿足目前需要的、簡單的系統(tǒng)，因為你所考慮的情況可能永遠都不會發(fā)生。反饋：盡快獲得用戶的反饋，并且越詳細越好，使得開發(fā)人員能夠保證自己的成果符合用戶的需要。勇氣：這是最重要的核心價值。因為XP強調(diào)要"擁抱變化"，因此對于用戶的反饋，要勇于對自己的代碼進行修改，丟掉壞的代碼。第8頁，共24頁，2023年，2月20日，星期五

XP的適用環(huán)境：

XP弱化針對未來需求的設計，非常注重當前的簡化.它的實踐，有一個非常關(guān)鍵的假設就是：開發(fā)人員只注重眼前需求，依賴重構(gòu)來適應需求的變動，這樣所帶來的風險、開銷要小于需求變化使得事先充分設計失效的代價；反之，實施XP就是不明智的.因此,XP適合規(guī)模小、進度緊、需求變化大、質(zhì)量要求嚴的項目。它希望以最高的效率和質(zhì)量來解決用戶目前的問題，以最大的靈活性和最小的代價來滿足用戶未來的需求，XP在平衡短期和長期利益之間做了巧妙的選擇。第9頁，共24頁，2023年，2月20日，星期五策劃：策劃活動開始于建立一毓描述待開發(fā)軟件必要特征與功能的“故事”（用戶故事），每個故事標明優(yōu)先級。并評估每個故事的成本，若成本超個3個開發(fā)周期，則要求進一步細分。故事的排序：所有故事將在幾周之內(nèi)盡快實現(xiàn)具有最高價值的故事將移到進度表的前面并首先實現(xiàn)高風險故事將首先實現(xiàn)項目速度用于：幫助建立后續(xù)發(fā)行版本的發(fā)布日期和進度安排確定是否對整個開發(fā)項目中的所有故事有過分承諾第10頁，共24頁，2023年，2月20日，星期五簡單設計

(SimpleDesign)：XP的設計嚴格遵循KIS（keepitsimple)傳統(tǒng)的軟件工程要求：

前提是需求不變化，或者很少變化；而XP認為：

需求是會經(jīng)常變化的，因此設計不能一蹴而就而應該是一項持續(xù)進行的過程。

XP鼓勵使用CRC卡

XP鼓勵使用既是構(gòu)建技術(shù)又是設計技術(shù)的“重構(gòu)”。

XP設計實際上不使用符號并且?guī)缀醪划a(chǎn)生工作產(chǎn)品。

XP中心觀念是設計在編碼開始前后同時發(fā)生。KentBeck認為對于XP來說，簡單設計應該滿足以下幾個原則：成功執(zhí)行所有的測試；不包含重復的代碼；向所有的開發(fā)人員清晰地描述編碼以及其內(nèi)在關(guān)系；盡可能包含最少的類與方法第11頁，共24頁，2023年，2月20日，星期五代碼重構(gòu)(Refactoring)XP：強調(diào)代碼重構(gòu)在其中的作用，認為應該經(jīng)常進行重構(gòu)，通常有兩個關(guān)鍵點應該進行重構(gòu)：對于一個功能實現(xiàn)前和實現(xiàn)后。代碼重構(gòu)是指在不改變系統(tǒng)行為的前提下，重新調(diào)整、優(yōu)化系統(tǒng)的內(nèi)部結(jié)構(gòu)以減少復雜性、消除冗余、增加靈活性和提高性能。重構(gòu)不是XP所特有的行為，在任何的開發(fā)過程中都可能并且應該發(fā)生。成對編程(PairProgramming)XP：認為在項目中采用成對編程比獨自編程更加有效。成對編程是由兩個開發(fā)人員在同一臺電腦上共同編寫解決同一問題的代碼，通常一個人負責寫編碼，而另一個負責保證代碼的正確性與可讀性。成對編程是一種非正式的同級評審(PeerReview)。它要求成對編程的兩個開發(fā)人員在性格和技能上應該相互匹配編碼：第12頁，共24頁，2023年，2月20日，星期五集體擁有代碼XP：認為開發(fā)小組的每個成員都有更改代碼的權(quán)利，所有的人對于全部代碼負責。評論：代碼全體擁有并不意味者開發(fā)人員可以互相推委責任，而是強調(diào)所有的人都要負責。如果一個開發(fā)人員的代碼有錯誤，另外一個開發(fā)人員也可以進行BUG的修復。持續(xù)集成(ContinuousIntegration)XP：提倡在一天中集成系統(tǒng)多次，而且隨著需求的改變，要不斷的進行回歸測試。因為，這樣可以使得團隊保持一個較高的開發(fā)速度，同時避免了一次系統(tǒng)集成的惡夢。著名的微軟公司就有每日集成(DailyBuild)的成功實踐。第13頁，共24頁，2023年，2月20日，星期五測試驅(qū)動(Test-driven)先測試，再編碼；代碼未動，測試先行XP：強調(diào)“測試先行”。在編碼開始之前，首先將測試寫好，而后再進行編碼，直至所有的測試都得以通過。注：測試的可自動化，集成化。第14頁，共24頁，2023年，2月20日，星期五小型發(fā)布(SmallRelease)XP：強調(diào)在非常短的周期內(nèi)以遞增的方式發(fā)布新版本，從而可以很容易地估計每個迭代周期的進度，便于控制工作量和風險；同時，也可以及時處理用戶的反饋。用戶在發(fā)布后兩個工作日內(nèi)，向項目小組提交“用戶接收測試報告”，由項目經(jīng)理評估測試報告，將有效的BUG提交并分配給相應的開發(fā)人員。項目小組應該在下一個迭代周期結(jié)束前修復所有用戶提交的問題。第15頁，共24頁，2023年，2月20日，星期五XP對于執(zhí)行者的要求是比較高的因為它要求開發(fā)團隊必須具備熟練的代碼設計技能和嚴格的測試保障技術(shù)了解面向?qū)ο蠛湍Ｊ?，掌握了重?gòu)和OO測試技術(shù)習慣測試先行的開發(fā)方式等第16頁，共24頁，2023年，2月20日，星期五4.3.2自適應軟件開發(fā)自適應軟件開發(fā)（AdaptiveSoftwareDevelopment）著眼于人員協(xié)作和團隊自我組織。包含思考、協(xié)作和學習三個階段。第17頁，共24頁，2023年，2月20日，星期五4.3.3動態(tài)系統(tǒng)開發(fā)方法是一種提供“通過在可控項目環(huán)境中使用增量原型開發(fā)模式完全滿足參時間有約束的系統(tǒng)的構(gòu)建和維護”的敏捷軟件開發(fā)方法。像XP和ASD一樣，建議使用迭代軟件過程?？尚行匝芯繕I(yè)務研究功能模型迭代設計和構(gòu)建迭代實現(xiàn)第18頁，共24頁，2023年，2月20日，星期五DynamicSystemsDevelopmentMethodDSDMLifeCycle(withpermissionoftheDSDMconsortium)第19頁，共24頁，2023年，2月20日，星期五4.3.4ScrumEasel公司發(fā)明，旨在尋求生產(chǎn)率突破名稱來自英式橄欖球，每個成員都明確自己角色，環(huán)繞同一目標，集體行動、奮辦拼搏公認的高生產(chǎn)率方法(6倍!)數(shù)十家公司、數(shù)百項目中應用被PIoP作為組織模式標準三個階段:定義的初始過程定義要求目標任務排序和分配最優(yōu)設計經(jīng)驗性的開發(fā)過程(Sprint階段)一連串聯(lián)1-6周的短周期沖刺目標限定明確(可演示)集中精辦最佳實現(xiàn)可多個開發(fā)組(4-7人)每天日常會議15-30分鐘回答三個問題定義的結(jié)束過程集成、系統(tǒng)測試、文檔第20頁，共24頁，2023年，2月20日，星期五第21頁，共24頁，2023年，2月20日，星期五第22頁，共24頁，2023年，2月20日，星期五FeatureDrivenDevelopment

特征驅(qū)動開發(fā)ReprintedwithpermissionofPeterCoad第23頁，共