【正文】 ，Agile過程利用變化作為動力 （ 3） 以幾周到幾個月為周期 ， 盡快 、 不斷地發(fā)布可運行軟件 （ 4） 在整個項目過程中 ， 業(yè)務人員和開發(fā)人員必須天天一起工作 （ 5） 以積極向上的員工為中心建立項目組 ，給予他們所需的環(huán)境和支持 ， 對他們的工作予以充分的信任 （ 6） 項目組內效率最高 、 最有效的信息傳遞方式是面對面的交流 （ 7） 測量項目進展的首要依據(jù)是可運行的軟件 （ 8） 敏捷過程提倡可持續(xù)的開發(fā) ， 項目發(fā)起者 、 開發(fā)者和用戶應能長期保持恒定的速度 （ 9） 應時刻關注技術上的精益求精和好的設計 ， 以增強敏捷性 （ 10） 簡單化是必不可少的 ， 這是盡可能減少不必要工作的藝術 （ 11） 最好的構架 、 需求和設計出自于自我組織的團隊 （ 12） 團隊要定期反思怎樣才能更有效 ， 并據(jù)此調整自己的行為 Agile方法的適用范圍 Martin Fowler認為：新方法不是到處可適用的 適合采用 Agile方法的情況： ? 需求不確定、易揮發(fā)（ Volatile,意指今天的要求明天就不需要了） ? 有責任感和積極向上的開發(fā)人員 ? 用戶容易溝通并能參與 Agile的典型方法 ? Extreme Programming (簡稱 XP) ? SCRUM ? Crystal Methodologies (簡稱 Crystal) ? Feature Driven Development(簡稱 FDD) ? Dynamic Systems Development Methodology(簡稱 DSDM) ? Adaptive Software Development(簡稱ASD) ? Pragmatic Programming等 XP方法 ? 由 Kent Beck提出，是 Agile方法中最引人注目的一個 ? XP最初實踐于 1997年 Crysler公司的 C3項目 (Smalltalk開發(fā)） ? 適用于 10人以下項目組、開發(fā)地點集中的場合 ? 廣泛用于需求模糊和揮發(fā)性強的場合 ? IONA公司的 Obix技術支持小組在采用了 XP方法后，軟件生產(chǎn)率提高了 67% XP方法的 4個價值觀 ? 交流（ Communication） ? 實踐表明，項目失敗的重要原因之一是交流不暢，使得客戶的需求不能準確地傳遞給開發(fā)人員，造成開發(fā)人員不能充分理解需求；模型或設計的變動未能及時告知相關人員，造成系統(tǒng)的不一致和集成的困難 ? 所有項目相關人員之間充分的有效的交流是軟件開發(fā)成功所必不可少的 ? XP方法提倡面對面的交流，這是一種有效的也是效率最高的交流方式 ? 簡單（ Simplicity） ? 指在確保得到客戶滿意的軟件的前提下，做最簡潔的工作（簡單的過程、模型、文檔、設計和實現(xiàn)） ? 在開發(fā)中不斷優(yōu)化設計，時刻保持代碼簡潔、無冗余 ? 體現(xiàn)了敏捷開發(fā)的“剛剛好 (Just enough)”思想，即開發(fā)中的活動及制品既不要太多也不要太少，剛好即可 ? 反饋（ Feedback） 及時有效的反饋能確定開發(fā)工作是否正確，及時發(fā)現(xiàn)開發(fā)工作的偏差并加以糾正。 強調各種形式的反饋，如非正式的評審（走查， Walkthrough）、小發(fā)布等 ? 勇氣（ Courage） 采用敏捷軟件開發(fā)需要勇氣 ： ? 信任合作的同事，也相信自己 ? 做能做到的最簡單的事 ? 只有在絕對需要的時候才創(chuàng)建文檔 ? 讓業(yè)務人員制定業(yè)務決策，技術人員制定技術決策 ? 用可能的最簡單的工具，例如白板和紙，只有在復雜建模工具能提供可能的最好價值時才去使用它們 ? 相信程序員能制定設計決策，不需要給他們提供過多的細節(jié) ? 需要勇氣來承認自己是會犯錯誤的，需要勇氣來相信自己明天能克服明天出現(xiàn)的問題。 XP方法的 12個核心實踐 （ Whole Team） ? 所有的小組成員應在同一個工作地點工作 ? 成員中必須有一個現(xiàn)場用戶（ Onsite User）由他提出需求，確定開發(fā)優(yōu)先級 ? 通常還設一個“教練”（ Coach）角色 教練指導 XP方法的實施，以及與外部的溝通和協(xié)調 （ Planning Game） 包括兩類：發(fā)布計劃和迭代（ Iteration）計劃 3. 系統(tǒng)比喻 （ Metaphor） 系統(tǒng)比喻是待開發(fā)軟件的一個每個成員都熟悉的形象化比喻，相當于一個粗略的軟件體系結構 4. 小發(fā)布（ Small release） 經(jīng)常、不斷地發(fā)布可運行的、具有商業(yè)價值的小軟件版本，供現(xiàn)場用戶評估或最終使用 5. 測試（ testing） XP方法提倡測試優(yōu)先，即先寫測試后編代碼（ testing then coding） 6. 簡單設計（ Simple Design） ? 設計只考慮當前定義的功能而不考慮以后需求的變化 ? 該設計是完成目前功能所需的最簡潔的設計 7. 結對編程（ Pair Programming） 一個程序員編程的同時，另一個程序員負責檢查程序的正確性和可讀性 結對的伙伴 可以動態(tài)調整 8. 設計改進（ Design Improvement） 在不影響程序的外部可見行為的情況下，按高內聚低耦合的原則對程序結構進行改進，保持代碼簡潔、無冗余 9. 持續(xù)集成（ Continuous Integration） 每完成一個模塊的開發(fā)（包括該模塊的單元測試）后，立即將其組裝到系統(tǒng)中，并進行集成測試，完成該集成測試后才能進行下一次集成 10. 代碼全體共有（ Collective code Ownership） 團隊中的任何人可以在任何時候修改系統(tǒng)任何位置上的任何代碼 團隊的成員都可以參加模型的開發(fā)，又有系統(tǒng)比喻、結對編程、編碼標準、持續(xù)集成等實踐，這些都為代碼全體共有提供了支持 11. 編碼標準（ Coding Standard） XP方法強調制訂一個統(tǒng)一的編碼標準，包括命名、注釋、格式等編程風格 12. 可持續(xù)步調（ Sustainable Pace） 每周 40小時工作制 XP方法的開發(fā)過程 最新版本 發(fā)布計劃 用戶認可 用戶 故事 (user stories) 下一迭代 Bugs 新用戶故事 測試用例 迭代 開發(fā) 體系結 構骨架(spike) 系統(tǒng)比喻 制訂交 付計劃 驗收 測試 小發(fā)布 需求 不確定的估計 確定的估計 難點 骨架 探索階段 計劃階段 迭代與發(fā)布階段 產(chǎn)品化階段 維護階段 探索階段 ? 探索階段的主要工作是開發(fā)初始的用戶故事（ User Stories ）和體系結構骨架（ architecture spike）。 ? 用戶故事描述了系統(tǒng)高層的需求，它是制訂發(fā)布計劃的輸入。 ? 在探索階段，試探找到系統(tǒng)中固定不變的部分（體系結構骨架），并找出一種形象的比喻，這種比喻描述了你打算如何構建系統(tǒng)，起到概念框架的作用。 ? 探索階段還應根據(jù)用戶故事編制相應的測試用例，供以后驗收測試時使用。 計劃階段 ? 計劃階段的任務是根據(jù)用戶故事描述的需求、系統(tǒng)體系結構骨架和系統(tǒng)比喻來制訂迭代計劃和發(fā)布計劃。 ? 使用你最熟悉的形式為用戶故事建模，這個模型描述了用戶故事的任務以及這些任務之間的關系。 ? 通常圖形方式（可以是草圖）比文字描述更直觀。 ? 盡可能精確地估算工作量，這是制訂計劃的重要依據(jù)。對于那些不能確切估算其工作量的難點部分，要進一步作分析，直至能確定其工作量估算。 迭代到發(fā)布階段 ? 迭代到發(fā)布階段根據(jù)迭代和發(fā)布計劃，開發(fā)滿足指定用戶故事需求的軟件，并與前面已完成的軟件版本集成，得到軟件的一個新版本。 ? 根據(jù)在探索階段編寫的測試用例，進行驗收測試。一旦發(fā)現(xiàn)錯誤或者通過驗收測試想進入下一輪迭代時，就重復迭代開發(fā)的工作。 ? 在這一階段當客戶提出新的用戶故事，或者根據(jù)項目的進展情況認為有必要時，可以回到計劃階段，對迭代和發(fā)布計劃做出修改或調整。 產(chǎn)品化階段 ? 產(chǎn)品化階段的工作主要是確認迭代開發(fā)的軟件已經(jīng)做好進入產(chǎn)品化的準備。 ? 在此階段可進行更多的測試，如系統(tǒng)測試、負載測試、安裝測試等。 ? 另一個工作就是整理文檔。雖然敏捷軟件開發(fā)的價值觀中強調 “ 可運行軟件高于詳盡的文檔 ” ，但是，必要的文檔仍是需要的。 可能要寫的文檔： ? 系統(tǒng)文檔 系統(tǒng)文檔的目的在于為系統(tǒng)提供一個總覽，來幫助人們理解它。主要包括：系統(tǒng)技術體系結構和業(yè)務體系結構的總覽、高層次的系統(tǒng)需求、關鍵設計決策的總結、體系結構圖以及重要的設計模型（如果有的話）等。 ? 操作文檔 操作文檔的內容包括：系統(tǒng)涉及的依賴關系，與其他系統(tǒng)、數(shù)據(jù)庫以及文件文互的特性，對備份流程的參考引用，系統(tǒng)的聯(lián)系人列表以及聯(lián)系方法，系統(tǒng)的適用性及可靠性需求的總結，系統(tǒng)預期負載情況概況，以及排錯指導原則。 ? 支持文檔 支持 文檔的內容包括：支持人員專用的培訓教材，解決問題時作為參考的用戶文檔，排錯指導原則，解決疑難問題時的上報流程，以及維護團隊的聯(lián)系列表。 ? 用戶文檔 參考手冊用于快速查詢；用戶指南用于指明系統(tǒng)的工作方式；支持指南用于指導如何獲取其他的幫助；培訓資料則主要用于培訓。 維護階段 ? 維護階段涵蓋了計劃階段、迭代到發(fā)布階段和產(chǎn)品化階段 ? 通常這個階段主要包括面向產(chǎn)品的活動，如系統(tǒng)的運行和支持。 內容摘要 ? 計算機軟件 ? 軟件工程 ?軟件過程 ? 軟件過程模型 ? 敏捷軟件開發(fā) ? CASE工具與環(huán)境 在軟件工程活動中，軟件工程師和管理人員按照軟件工程的方法和原則，借助于計算機及其軟件工具的幫助，開發(fā)、維護、管理軟件產(chǎn)品的過程稱為計算機輔助軟件工程 計算機輔助軟件工程 （ CASE） Computer Aided Software Engineering ? 軟件工具 是用來輔助計算機軟件的開發(fā)、運行、維護、管理、支持過程中的活動或任務的軟件 ? 按支持的軟件過程活動分類： ? 開發(fā)過程： 需求分析工具，設計工具，編碼工具，測試工具 它們還可按支持的開發(fā)方法分為： 結構化 XX工具 ， 面向對象 XX工具 CASE工具 ? 維護過程： 版本控制工具，文檔分析工具，逆向工程 （ reverse engineering） 工具，再工程 （ reengineering） 工具 ? 管理過程： 項目管理工具，配置管理工具，軟件評價工具 ? 應用類工具 ? 集成型開發(fā)環(huán)境是一種把支持 多種軟件開發(fā)方法 和 過程模型 的軟件工具集成到一起的軟件開發(fā)環(huán)境 ? 集成型開發(fā)環(huán)境由 環(huán)境集成機制 和 工具集 組成 集成型軟件開發(fā)環(huán)境 ? 環(huán)境集成機制包括： ? 數(shù)據(jù)集成機制 ：為各種相互協(xié)作的工具提供統(tǒng)一的數(shù)據(jù)接口規(guī)范 ? 控制集成機制 ：支持各個工具或開發(fā)活動之間的通信、切換、調度和協(xié)同工作，并支持軟件開發(fā)過程的描述、執(zhí)行與轉接 ? 界面集成機制 ：支持工具界面的集成和應用系統(tǒng)的界面開發(fā)，統(tǒng)一界面風格