第五章 敏捷開發
敏捷的概念：
敏捷軟體工程是哲學理念和一系列開發指南的綜合。這種哲學理念推崇:讓客戶滿意且盡早的增量發布;小而高度自主的專案團隊;非正式的方法;最小化軟體工程工作產品以及整體精簡開發。開發的指導方針強調超越分析和設計(儘管並不排斥這類活動)的發布，以及開發人員和客戶之間主動和持續的溝通。
敏捷的步驟：
步驟:對敏捷開發的恰當稱呼應當是「軟體工程精簡版」，它保留了基本的框架活動:客戶溝通、策劃、建模、構建和部署，但將其縮減到乙個推動專案組朝著構建和交付發展的最小任務集（有人認為這種方法是以犧牲問題分析和方案設計為代價而實現的)。
敏捷的質量保證措施:
如果敏捷團隊認為過程可行，並且開發出的可交付軟體增量能使客戶滿意，則軟體質量就是沒有問題的。
1. 什麼是敏捷？
敏捷已經成為當今描述現代軟體過程的時髦用詞。每個人都是敏捷的。敏捷團隊是能夠適當響應變更的靈活團隊。
變更就是軟體開發本身，軟體構建有變更、團隊成員在變更、使用新技術會帶來變更，各種變更都會對開發的軟體產品以及專案本身造成影響。我們必須接受「支援變更」的思想，它應當根植於軟體開發中的每一件事中，因為它是軟體的心臟與靈魂。敏捷團隊意識到軟體是團隊中所有人共同開發完成的，這些人的個人技能和合作能力是專案成功的關鍵所在。
但是，敏捷不僅僅是有效地響應變更，它還包含著對本章開頭的宣言中提及哲學觀念的信奉。它鼓勵能夠使溝通（團隊成員之間、技術和商務人員之間、軟體工程師和經理之間)更便利的團隊結構和協作態度。它強調可執行軟體的快速交付而不那麼看重中間產品(這並不總是好事情);它將客戶作為開發團隊的一部分開展工作，以消除持續、普遍存在於多數軟體專案中的「區分我們和他們」的態度;它意識到在不確定的世界裡計畫是有侷限性的,專案計畫必須是可以靈活調整的。
敏捷可以應用於任何軟體過程。但是，為了實現這一目標，非常重要的一點是:過程的設計應使專案團隊適應於任務，並且使任務流水線化，在了解敏捷開發方法的流動性的前提下進行計畫的制定，保留最重要的工作產品並使其保持簡潔，強調這樣乙個增量交付策略─—根據具體的產品型別和執行環境，盡可能快地將可工作的軟體交付給客戶。
2. 敏捷變更
變更成本是開發時間的函式
3.什麼是敏捷過程？
任何敏捷軟體過程的特徵都是以某種方式提出若干關鍵假設，這些假設可適用於大多數軟體專案。
3.1 提前**哪些需求是穩定的以及哪些需求會變更是非常困難的。同樣,**專案進行中客戶優先順序的變更也很困難。
3.2 對很多軟體來說，設計和構建是交錯進行的。也就是兩種活動應當順序開展以保證通過構建實施來驗證設計模型，而在通過構建驗證之前很難估計應該設計到什麼程度。
3.3 分析、設計、構建和測試並不像我們所設想的那麼容易**（從制定計畫的角度來看)。
4. 12條敏捷原則
4.1 我們最優先要做的是通過盡早、持續交付有價值的軟體來使客戶滿意。
4.2 即使在開發的後期，也歡迎需求變更。敏捷過程利用變更為客戶創造競爭優勢。
4.3 經常交付可執行軟體,交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。
4.4 在整個專案開發期間,業務人員和開發人員必須天天都在一起工作。
4.5 圍繞有積極性的個人構建專案。給他們提供所需的環境和支援,並且信任他們能夠完成工作。
4.6 在團隊內部,最富有效果和效率的資訊傳遞方法是面對面交談。
4.7 可執行軟體是進度的首要度量標準。
4.8 敏捷過程提倡可持續的開發速度。責任人( sponsor)、開發者和使用者應該能夠長期保持穩定的開發速度。
4.9 不斷地關注優秀的技能和好的設計會增強敏捷能力。
4.10 簡單——使不必做的工作最大化的藝術——是必要的。
4.11 最好的架構、需求和設計出自於自組織團隊。
4.12 每隔一定時間，團隊會反省如何才能更有效地工作，並相應調整自己的行為。
5. 極限程式設計（extreme programming xp）過程
如圖：
6.工業極限程式設計
工業極限程式設計（ixp)是xp的一種有機進化。它由xp的最低限要求、以客戶為中心和測試驅動精神組成。ixp與原來xp的主要差別在於其管理具有更大的包容性，它擴大了使用者角色，公升級了技術實踐。ixp合併了六個新實踐，這些新實踐的設計是為了有助於確保在大型組織內的—些重要專案中，xp工作能夠成功地實施。
六個新實踐分別是：準備評估、專案社群、專案特許、測試驅動管理、回顧、持續學習。其中回顧是指ixp團隊在乙個軟體增量交付之後要實施特定的技術評審。這種評審稱為回顧,評審通過軟體增量或者全部軟體的發布過程複查「問題、事件以及經驗教訓。
7. 其他敏捷過程模型
四種常見的敏捷方法:scrum、dssd、敏捷建模（am)以及敏捷統一過程
7.1 scrum
scrum原則與敏捷宣言是一致的，應用scrum原則指導過程中的開發活動，過程由「需求、分析、設計、演化和交付」等框架性活動組成。scrum強調使用一組「軟體過程模式」，這些過程模式被證實在時間緊張的需求變更的和業務關鍵的專案中是有效的。每乙個過程模式定義一系列開發活動。如圖：
7.2 動態系統開發方法(dynamic system development method，dsdm)
動態系統開發方法是一種敏捷軟體開發方法，該方法提供一種框架，使其「通過在可控專案環境中使用增量原型開發模式以完全滿足對時間有約束的系統的構建和維護。這種情況下，如果交付整個應用系統需用100%時間，那麼80%的應用系統可以用20%的時間交付。
dsdm使用迭代軟體過程，每乙個迭代都遵循80%原則，即每個增量只完成能夠保證順利進入下一增量的工作，剩餘的細節則可以在知道更多業務需求或者提出並同意變更之後完成。
dsdm定義了以下三個不同的迭代週期
7.2.1 功能模型迭代功：客戶開發一系列可證明其功能的增量原型（注意:所有dsdm原型都傾向於逐漸演化為可交付的應用系統)。這一迭代週期的意圖是在使用者使用原型系統時引導出反饋資訊以獲取補充的需求。
7.2.2 設計和構建迭代：功能模型迭代中，重新構建原型以確保每乙個原型都以工程化方式實現，並能為終端使用者提供可操作的業務價值。有些情況下，功能模型迭代、設計和構建迭代可同步進行。
7.2.3 實現：最終軟體增量(乙個可操作的原型）置於執行環境中。應當注意:(1）增量不見得100%完成;(2）增量置於執行環境以後可能需要變更。在這兩種情況下，dsdm開發轉向功能模型迭代活動繼續進行。
7.3 敏捷建模（agile modeling）
am是一種基於實踐的方法學，用於對基於軟體的系統實施有效建模和文件編制。在軟體開發專案中，am是可以有效並以輕量級方式用於軟體建模的標準、原則和實踐。由於敏捷模型只是大致完善，而不要求完美，因此敏捷模型比傳統的模型更有效。
am採納了與敏捷宣言一致的全部標準。敏捷建模的指導思想認為，敏捷團隊必須有做出決定的勇氣，哪怕這些決定可能否決當前的設計並導致重新構建。
am的建模原則：有目的的模型、使用多個模型、輕裝上陣、內容重於表述形式、理解模型及工具、適應本地需要。
7.4 敏捷統一過程（agile unified process，aup）
敏捷統一過程(（agile unified process，aup)採用了乙個「在大型上連續」以及「在小細化構建和轉換——aup提供了一系列活動(例如軟體工程活動的乙個線性序列)，能夠使團隊為軟體專案構想出乙個全面的過程流。每個aup執行以下活動：
建模、實現、測試、部署、配置及專案管理、環境管理。其中實現就是編譯源**。
軟體工程之軟體過程模型
軟體過程模型,也稱為軟體生存週期模型或軟體開發模型,是描述軟體過程中各種活動如何執行的模型.他確立了軟體開發中各階段的次序限制,以及各階段活動的準則.便於各個活動的協調與人員的有效通訊,有利於活動重用和活動管理.目前常用的軟體工程模型有 瀑布模型,增量模型,螺旋模型,噴泉模型,智慧型模型等.瀑布模型...
軟體工程之軟體過程模型
軟體過程模型習慣上也稱為軟體開發模型，它是軟體開發全部過程 活動和任務的結構框架。瀑布模型是將軟體生存週期中的各個活動規定為依線性連線的若干階段的模型，包括需求分析 設計 編碼 測試 執行與維護。由前至後 相互銜接的固定次序，如同瀑布流水逐級下落。瀑布模型是以文件作為驅動 適合於軟體需求很明確的軟體...
軟體工程 過程模型 敏捷開發
軟體的概念 軟體是在計算機系統支援下能夠完成特定功能和效能的程式 資料和相關文件 軟體 知識 程式 資料 文件 軟體危機 軟體危機是指落後的生方式無法滿足迅速增長的計算機需求，從而導致軟體開發和過程維護出現一系列嚴重問題的現象。軟體工程的概念 軟體工程定義的第一部分內容要求，軟體開發 維護 和執行的...