【正文】 則（ Principle）。這批業(yè)界專家自稱為敏捷聯(lián)盟（ Agile Alliance）。 2022年 8月 27日星期六 第 93頁 敏捷軟件開發(fā)宣言 ? 個體和交互 勝過 過程和工具 ? 可以工作的軟件 勝過 面面俱到的文檔 ? 客戶合作 勝過 合同談判 ? 響應(yīng)變化 勝過 遵循計(jì)劃 ? 雖然右項(xiàng)也有價值，但是我們認(rèn)為左項(xiàng)具有更大的價值。 2022年 8月 27日星期六 第 94頁 敏捷開發(fā)技術(shù)基本概念 ? 概念 39：原則 ? 從宣言的價值觀中引出了下面的十二條原則，它們是敏捷實(shí)踐與重型過程相區(qū)別的特征所在。 2022年 8月 27日星期六 第 95頁 敏捷開發(fā)技術(shù)基本概念 ? (1) 盡早地、不斷地交付有價值的軟件來滿足客戶需要。 ? (2) 團(tuán)隊(duì)努力保持軟件結(jié)構(gòu)的靈活性，敏捷過程能夠駕馭變化，保持客戶的競爭優(yōu)勢。 ? (3) 要經(jīng)常交付可以工作的軟件，周期越短越好，從幾星期到幾個月。 ? (4) 業(yè)務(wù)人員和開發(fā)人員必須在整個項(xiàng)目過程中頻繁交互，并一起工作。 2022年 8月 27日星期六 第 96頁 敏捷開發(fā)技術(shù)基本概念 ? (5) 圍繞被激勵起來的個人來構(gòu)建項(xiàng)目。給開發(fā)者提供適宜的環(huán)境和支持，滿足他們的需要，并信任他們能夠完成任務(wù)。 ? (6) 在開發(fā)團(tuán)隊(duì)內(nèi)部，最有效率也最有效果的信息傳達(dá)方式是面對面的交談。 ? (7) 可以工作的軟件是進(jìn)度的主要度量標(biāo)準(zhǔn)。 ? (8) 敏捷過程提倡可持續(xù)的開發(fā)速度。責(zé)任人、開發(fā)人員和用戶應(yīng)該總是維持不變的節(jié)奏。 2022年 8月 27日星期六 第 97頁 敏捷開發(fā)技術(shù)基本概念 ? (9) 不斷追求卓越技術(shù)與良好設(shè)計(jì)將有助于提高敏捷性。 ? (10) 簡單。 ? (11) 最好的架構(gòu)、需求和設(shè)計(jì)都源自于自組織的團(tuán)隊(duì)。 ? (12) 每隔一段時間，團(tuán)隊(duì)會總結(jié)如何才能更有效率，然后相應(yīng)地調(diào)整自己的行為。 2022年 8月 27日星期六 第 98頁 敏捷開發(fā)技術(shù)基本概念 ? 概念 310：敏捷開發(fā)與其他方法的比較 ? 敏捷方法有時候被誤認(rèn)為是無計(jì)劃性和紀(jì)律性的方法，實(shí)際上敏捷方法更強(qiáng)調(diào)適應(yīng)性而非預(yù)見性。適應(yīng)性的方法集中在快速適應(yīng)現(xiàn)實(shí)的變化。當(dāng)項(xiàng)目的需求發(fā)生變化，團(tuán)隊(duì)?wèi)?yīng)該迅速響應(yīng)，但這個團(tuán)隊(duì)可能很難確切描述未來將會如何變化。 2022年 8月 27日星期六 第 99頁 敏捷開發(fā)技術(shù)基本概念 ? (1) 與迭代、增量式方法的比較 ? (2) 與瀑布式開發(fā)的比較 2022年 8月 27日星期六 第 100頁 敏捷開發(fā)技術(shù)基本概念 ? 敏捷方法強(qiáng)調(diào)溝通，當(dāng)項(xiàng)目觃模較大、參與人員較多時，團(tuán)隊(duì)成員面對面的溝通就變得非常困難，因此，敏捷方法適用于輕量級開發(fā)，更適合 20人以下團(tuán)隊(duì)工作；另一方面，敏捷方法對開發(fā)人員要求更高，它認(rèn)為“ 代碼即是設(shè)計(jì)，代碼即是文檔 ”，因此要求程序員必須具備相當(dāng)強(qiáng)的設(shè)計(jì)能力與經(jīng)驗(yàn)。 ? 在小觃模組織中應(yīng)用敏捷方法，效果相當(dāng)顯著。 2022年 8月 27日星期六 第 101頁 極限編程 ? 極限編程（ Extreme Programming，簡稱 XP）被列入敏捷開發(fā)方法。 2022年 8月 27日星期六 第 102頁 極限編程 ? 概念 311：極限編程的起源 ? 極限編程是由 Kent Beck、 Ward Cunningham和 Ron Jeffries在 1996年提出的。 Kent Beck一直倡導(dǎo)軟件開發(fā)的模式定義。早在 1993年，他就和 Grady Booch（ UML之父）發(fā)起了一個團(tuán)隊(duì)進(jìn)行這方面的研究，希望能使軟件開發(fā)更加簡單而有效。 Kent仔細(xì)觀察和分析了各種簡化軟件開發(fā)的前提條件、可行性以及面臨的困難。 1996年三月， Kent終于在為 DaimlerChrysler所做的一個項(xiàng)目中引入了新的軟件開發(fā)觀念 —— XP。 2022年 8月 27日星期六 第 103頁 極限編程 ? 概念 312：什么是極限編程？ ? 極限編程是一種開發(fā)管理模式，是一種軟件工程方法學(xué)，是敏捷軟件開發(fā)中最富有成效的幾種方法學(xué)之一。 2022年 8月 27日星期六 第 104頁 極限編程 ? 極限編程強(qiáng)調(diào)的重點(diǎn)是： ? (1) 角色定位 ? (2) 敏捷開發(fā) ? (3) 追求價值 2022年 8月 27日星期六 第 105頁 極限編程 ? 概念 313：極限編程的目標(biāo) ? 極限編程的主要目標(biāo)在于降低因需求變更而帶來的成本增加。極限編程透過引入基本價值、原則、方法等概念來降低變更成本的目的。 ? 與傳統(tǒng)的在項(xiàng)目起始階段就定義好所有需求再費(fèi)盡心思地控制變化的方法相比，極限編程希望有能力在項(xiàng)目周期的任何階段去適應(yīng)變化。 2022年 8月 27日星期六 第 106頁 極限編程 ? 概念 314：極限編程的極致思維 ? 極限編程的“極致”思維體現(xiàn)在以下 7個方面： ? (1) 如果程序代碼檢查對我們有好處，我們應(yīng)反復(fù)地檢查（結(jié)對編程， Pair Programming）； ? (2) 如果測試對我們有好處，每個人都應(yīng)該常常做測試（單元測試， Unit Testing），即使是客戶也不例外（功能測試， Funtion Testing）； ? (3) 如果設(shè)計(jì)對我們有好處，則應(yīng)被當(dāng)作每個人每天工作的一部分（重整，Refactoring）； ? (4) 如果簡潔對我們有好處，我們應(yīng)該保持在能夠?qū)崿F(xiàn)目前所需功能的最簡單狀態(tài)（能夠運(yùn)作的最簡單架構(gòu)）； ? (5) 如果架構(gòu)對我們很重要，每個人都應(yīng)該常常反復(fù)琢磨架構(gòu)（對整個系統(tǒng)定義一個隱喻、象征或概念）； ? (6) 如果整合測試對我們很重要，我們每天都要做上好幾次（持續(xù)整合）； ? (7) 如果短的開發(fā)周期對我們有益，我們就把它縮短到非常短。 2022年 8月 27日星期六 第 107頁 極限編程 ? 根據(jù)極限編程的極致思維，可以保證兩件事： ? (1) 對程序員而言，極限編程可以保證他們每天都做些真正有意義的事。他們能做出自己最佳的決定，不必再獨(dú)自面對那些會令人驚慌的情況，他們可以自己把握每件事，成功地做出系統(tǒng)。 ? (2) 對客戶和經(jīng)理人而言，極限編程保證他們每個工作周，都可以獲得最大的利益。每隔幾周，就會看到他們所要求目標(biāo)的具體進(jìn)度。也可以在不至于引起高費(fèi)用的狀況下，在項(xiàng)目進(jìn)行到一半時改變其行進(jìn)方向。 2022年 8月 27日星期六 第 108頁 極限編程 ? 概念 315：極限編程的核心實(shí)踐 ? 極限編程把軟件開發(fā)過程重新定義為聆聽、測試、編碼、設(shè)計(jì)的反饋、迭代循環(huán)過程，確立了測試 —— 編碼 —— 重構(gòu)（設(shè)計(jì)）的軟件開發(fā)管理思路。 2022年 8月 27日星期六 第 109頁 極限編程 聆聽 測試 編碼 設(shè)計(jì) 反饋 迭代 極限編程的過程模型 2022年 8月 27日星期六 第 110頁 極限編程 ? 結(jié)合極限編程的過程模型，我們把極限編程的核心實(shí)踐劃分成四個部分。 2022年 8月 27日星期六 第 111頁 極限編程 ? 第一部分 小觃模反饋（ Fine Scale Feedback） ? (1) 測試 ? (2) 結(jié)對設(shè)計(jì) ? (3) 客戶（現(xiàn)場客戶）作為團(tuán)隊(duì)成員 ? (4) 策劃游戲 2022年 8月 27日星期六 第 112頁 極限編程 ? 第二部分 反復(fù)持續(xù)性過程（ Continuous Process） ? (1) 持續(xù)整合 ? (2) 軟件重構(gòu) ? (3) 小型發(fā)布 2022年 8月 27日星期六 第 113頁 極限編程 ? 第三部分 達(dá)成共識 ? (1) 簡單設(shè)計(jì) ? (2) 代碼集體所有 ? (3) 程序設(shè)計(jì)標(biāo)準(zhǔn) 2022年 8月 27日星期六 第 114頁 極限編程 ? 第四部分 程序員的福利 ? 可持續(xù)的開發(fā)速度，即每周 40小時工作制。開發(fā)團(tuán)隊(duì)?wèi)?yīng)該長期可持續(xù)發(fā)展。他們以能夠長期維持的速度努力工作。他們保存精力，把項(xiàng)目看作是馬拉松長跑，而不是全速短跑。 XP認(rèn)為編程是愉快的工作，不輕易加班，今天的工作今天做。 2022年 8月 27日星期六 第 115頁 極限編程 ? XP針對的是中小型團(tuán)隊(duì)和中小型項(xiàng)目，但世界上畢竟還有大型項(xiàng)目跟超大型項(xiàng)目，究竟這種重視人甚于重視軟件工程方法論，能不能跟其它重視軟件工程方法論抗衡呢？XP如何應(yīng)用在大型或超大型項(xiàng)目中的問題，還有待研究。 2022年 8月 27日星期六 第 116頁 總結(jié) ? 軟件生命周期包括制定計(jì)劃、需求分析、設(shè)計(jì)、編碼、測試、運(yùn)行及維護(hù)等六個階段。每個階段由多個活動組成，用來完成各個階段的任務(wù)。 ? 每種軟件生命周期模型都代表了一種軟件項(xiàng)目開發(fā)、管理與支持的組織過程。 ? 不同項(xiàng)目有不同的生命周期模型，主要有瀑布模型、演化模型、增量模型、螺旋模型、 V過程模型、原型實(shí)現(xiàn)模型、快速應(yīng)用開發(fā)、極限編程等。根據(jù)項(xiàng)目的實(shí)際情況，如規(guī)模的大小、需求是否明確等，選擇適當(dāng)?shù)纳芷谀Ｐ汀? 2022年 8月 27日星期六 第 117頁 總結(jié) ? 傳統(tǒng)軟件開發(fā)方法的特點(diǎn)是：以模塊作為基本的構(gòu)造單元，自頂向下逐步細(xì)分功能，不同模塊之間的信息傳遞通過函數(shù)的調(diào)用來完成，堅(jiān)持嚴(yán)格的階段性評審。正因?yàn)閭鹘y(tǒng)軟件開發(fā)方法有這些特點(diǎn)，所以，傳統(tǒng)軟件開發(fā)方法的缺點(diǎn)有：重用性差、難以維護(hù)、不能很好地表示現(xiàn)實(shí)世界等。 ? 面向?qū)ο筌浖_發(fā)方法可以很好地解決現(xiàn)實(shí)世界的問題，使用這種方法開發(fā)的軟件系統(tǒng)重用性好、可維護(hù)性好。 ? RUP統(tǒng)一開發(fā)過程是一個通用的過程框架，是一個演化的開發(fā)過程，包括開發(fā)過程、管理過程和支撐過程。常與面向?qū)ο筌浖_發(fā)方法相結(jié)合，適用于開發(fā)大型、復(fù)雜的軟件系統(tǒng)。 ? 敏捷開發(fā)方法是一種新興的軟件開發(fā)方法，它的價值觀認(rèn)為：個體和交互勝過過程和工具、可以工作的軟件勝過面面俱到的文檔、客戶合作勝過合同談判、響應(yīng)變化勝過遵循計(jì)劃。目前的敏捷開發(fā)方法僅適用于中小規(guī)模的軟件開發(fā)。