軟件項(xiàng)目管理

1、軟件項(xiàng)目管理,第六章 軟件過程管理,本章內(nèi)容提要,軟件過程與過程管理CMMI概述CMMI的成熟度等級及其過程域CMMI的應(yīng)用PSP，TSP與CMMI敏捷軟件開發(fā)方法,第四節(jié) CMMI的應(yīng)用,實(shí)施CMMI過程改進(jìn)的兩種方法階段表示連續(xù)表示CMMI評估,實(shí)施CMMI過程改進(jìn)的兩種方法,CMMI模型支持兩種實(shí)施過程改進(jìn)的方法，一種稱為階段表示，一種稱為連續(xù)表示。階段表示（Staged Representation）為過程改進(jìn)

2、提供了一個預(yù)定義的路線圖，即從成熟度等級1到成熟度等級5逐級增加，要達(dá)到某一成熟度等級，必須滿足該等級（及其以下等級）上所有過程域的目標(biāo)。,連續(xù)表示（Continuous Representation）支持單個過程域的改進(jìn)，可理解為一個過程域接著一個過程域?qū)嵤└倪M(jìn)。在每個過程域上從能力等級0到能力等級5逐級增加。,實(shí)施CMMI過程改進(jìn)的兩種方法,階段表示和連續(xù)表示的對比,階段表示是從CMM模型繼承而來，已經(jīng)過多年的實(shí)踐檢驗(yàn)。它提供了一個

3、明確的、被證實(shí)的過程改進(jìn)路徑，遵循這條路徑不需要過多的討論和爭論。而且由于它的明確性和統(tǒng)一性，有助于進(jìn)行跨組織的比較。連續(xù)表示的優(yōu)點(diǎn)是提供了靈活性。用戶可根據(jù)具體的業(yè)務(wù)目標(biāo)來選擇需要實(shí)現(xiàn)的過程域及其實(shí)現(xiàn)次序。,CMMI評估,成熟度等級的評估由美國卡內(nèi)基梅隆大的軟件工程研究所授權(quán)的主任評估師領(lǐng)導(dǎo)一個評審小組進(jìn)行，其成員大部分來自企業(yè)內(nèi)部。評估過程包括員工培訓(xùn)（企業(yè)的高層領(lǐng)導(dǎo)也要參加）、問卷填寫和統(tǒng)計(jì)、文檔審查、數(shù)據(jù)分析、與企業(yè)的高層領(lǐng)

4、導(dǎo)討論和撰寫評估報告等。評估結(jié)束由主任評估師簽字生效。評估結(jié)果報告給SEI，但SEI不會發(fā)“認(rèn)證”證書。,CMMI評估,一般有兩種類型的評估：軟件過程評估和軟件能力評價。軟件過程評估用于確定機(jī)構(gòu)當(dāng)前過程的狀態(tài)，決定一個機(jī)構(gòu)所面臨的高優(yōu)先級的過程相關(guān)問題，并且獲得機(jī)構(gòu)對軟件過程改進(jìn)的支持。軟件能力評價用來確定合格的軟件項(xiàng)目承制方，或用來監(jiān)督在目前的軟件項(xiàng)目中正在進(jìn)行軟件過程的狀態(tài)。,軟件過程評估方法,判斷一個組織當(dāng)前的軟件過程的能力

5、狀態(tài)，并發(fā)現(xiàn)過程中的缺陷。判斷并確定一個組織面對的與軟件過程相關(guān)的改進(jìn)策略。利用組織的支持來對該組織的軟件過程進(jìn)行有效的改進(jìn)。,軟件能力評價方法,判斷有意承擔(dān)某個軟件項(xiàng)目的軟件組織（投標(biāo)者）的過程能力。利用評價結(jié)果確定選擇某一承包者的風(fēng)險。判斷已進(jìn)行的軟件過程所處的狀態(tài)是否正確或是否正常。推動承包者在工作過程中改進(jìn)他們的軟件過程。,過程評估和能力評價步驟,挑選隊(duì)伍：成員必須具有專業(yè)的軟件工程和管理方面的知識，并接受過基本CMM

6、/CMMI概念和特定評估及評價方法的訓(xùn)練。問卷調(diào)查：讓來自被評估單位的代表完成軟件過程成熟度問卷并回答評估評價組提出的診斷性問題。響應(yīng)分析：明確哪些回答與問題的答案相吻合，并確定須進(jìn)一步調(diào)查的領(lǐng)域。,現(xiàn)場調(diào)查：從響應(yīng)分析的結(jié)果出發(fā)，評估小組進(jìn)行提問、檢查、協(xié)商等，以獲取專業(yè)性的結(jié)論，說明軟件過程的 KPA是否達(dá)到了應(yīng)有的目標(biāo)。評估小組提供一個定義軟件過程優(yōu)缺點(diǎn)的結(jié)果清單。對于軟件過程評估來說，這些結(jié)果將成為過程改進(jìn)的基礎(chǔ)和參考；

7、對于軟件能力評價來說，這些結(jié)果為決策者提供風(fēng)險分析的技術(shù)基礎(chǔ)。,過程評估和能力評價步驟,評估小組完成KPA基本概況的描述文件，給出組織已經(jīng)滿足的KPA目標(biāo)和尚未滿足的KPA目標(biāo)。,過程評估和能力評價步驟,軟件過程評估和軟件能力評價之間的不同,軟件過程評估和軟件能力評價的結(jié)果可能不同（主要是因?yàn)樵u估和評價的側(cè)重點(diǎn)不一樣，而且被評估和被評價的組織、項(xiàng)目、軟件產(chǎn)品都會發(fā)生變化，因此，應(yīng)該考慮評估和評價的Context）。軟件過程評估和軟件能

8、力評價在出發(fā)點(diǎn)和目標(biāo)上是不同的（導(dǎo)致成熟度提問單的內(nèi)容組織不一樣，收集的信息不一樣，結(jié)論的評價不一樣）。,軟件過程評估是在一個開放的、互相協(xié)作的環(huán)境下進(jìn)行的。而軟件能力評價往往是在有較大阻力的環(huán)境中進(jìn)行的。（過程評估是為了提高管理者和工程師的工作水平，而能力評價是為了表明一個軟件組織的實(shí)際軟件過程能力，為選擇承包者和減少費(fèi)用服務(wù)）。,軟件過程評估和軟件能力評價之間的不同,CMMI評估的注意事項(xiàng),籌備必備機(jī)構(gòu)SEPG：負(fù)責(zé)過程的定義和策

9、劃。SQA：負(fù)責(zé)審核軟件過程的實(shí)施情況；產(chǎn)品質(zhì)量的審核和控制。確定合適的目標(biāo)對指定的KPA作評估或診斷，2級時也可要求對3級的KPA進(jìn)行評估。有些組織一開始可能并不想進(jìn)行評分和評級，而是希望評估組從其現(xiàn)有的實(shí)踐中確定最佳實(shí)踐，作為組織的標(biāo)準(zhǔn)實(shí)踐進(jìn)行推廣。,確定范圍部門：哪些部門參加。項(xiàng)目：選擇合適的項(xiàng)目。KPA：確定對那些KPA進(jìn)行評估。人數(shù)：為了保證評估取證有足夠的可信度，人數(shù)總和應(yīng)該超過組織人數(shù)的20％。約束對不

10、參加的部門，評估組無權(quán)進(jìn)行訪談或取證。,CMMI評估的注意事項(xiàng),對不參加的人員，評估組無權(quán)進(jìn)行訪談或取證。經(jīng)費(fèi)和預(yù)算不得超過某個限度。進(jìn)度安排應(yīng)該在一個適當(dāng)?shù)钠谙迌?nèi)。期望要求評估師簽署結(jié)論性證明文件。要求評估組指明每個KPA的優(yōu)缺點(diǎn)，哪些實(shí)踐有待改進(jìn)。要求評估組提出下一步過程改進(jìn)的計(jì)劃和大致的日程安排。,CMMI評估的注意事項(xiàng),承諾組織主管保證參加評估的人員不會影響評估活動的正常進(jìn)展。保證為評估工作提供相應(yīng)的后勤服務(wù)。

11、向評估組授權(quán)“開工令”（從某日起開始工作）。,CMMI評估的注意事項(xiàng),準(zhǔn)備待審文檔 -組織級文檔軟件生存期模型研發(fā)過程的各種方針項(xiàng)目遵循的規(guī)程選用的標(biāo)準(zhǔn)裁剪指南標(biāo)準(zhǔn)報表標(biāo)準(zhǔn)測量集,CMMI評估的注意事項(xiàng),-項(xiàng)目級文檔軟件開發(fā)計(jì)劃軟件質(zhì)量保證計(jì)劃軟件配置管理計(jì)劃項(xiàng)目在實(shí)施中遵循的規(guī)程測量計(jì)劃培訓(xùn)教材,CMMI評估的注意事項(xiàng),-實(shí)現(xiàn)級文檔會議概要：評審會等項(xiàng)目管理過程的狀態(tài)報告：月度報告等各類變更申請

12、測試記錄開發(fā)過程中產(chǎn)生的各類工作產(chǎn)品：設(shè)計(jì)文檔，源代碼清單等。,CMMI評估的注意事項(xiàng),影響CMMI過程改進(jìn)成敗的因素,過程改進(jìn)必須有高級主管的支持與委托，并積極地管理過程改進(jìn)的進(jìn)展。獲取中層管理的支持，以方便地獲取過程改進(jìn)的資源（人員、時間、經(jīng)費(fèi)和設(shè)備）。基層技術(shù)人員的參與和支持極端重要。利用定量的可觀察數(shù)據(jù)盡快使過程改進(jìn)的成果可見，從而激勵參與者的興趣。按照軟件過程改進(jìn)對企業(yè)文化的要求進(jìn)行變革，要求軟件過程改進(jìn)為商業(yè)利益

13、服務(wù)，并與企業(yè)其他部分協(xié)調(diào)。,第五節(jié) PSP，TSP與CMMI,PSP的產(chǎn)生CMM/CMMI只關(guān)注“做什么”，而不關(guān)注“怎么做”，未提供實(shí)現(xiàn)各過程域所需要的知識和方法。為了解決上述問題，CMU-SEI在CMM1.1基礎(chǔ)上提出了PSP/TSP。,PSP的產(chǎn)生,1995年，CMU-SEI的Watts s. Humphrey領(lǐng)導(dǎo)開發(fā)出PSP（Personal Software Processes），被認(rèn)為是由定性軟件工程走向定量軟件工程

14、的標(biāo)志。PSP是一種可用于控制、管理和改進(jìn)軟件工程師個人工作方式的自我改善過程，是一個包括軟件開發(fā)表格、指南和規(guī)程的結(jié)構(gòu)化框架。,PSP關(guān)注點(diǎn),如何制訂計(jì)劃如何控制質(zhì)量如何與其他人相互協(xié)作如何預(yù)防缺陷(PSP重點(diǎn))關(guān)鍵是如何提高設(shè)計(jì)質(zhì)量,PSP中的個人任務(wù),為每一個項(xiàng)目/模塊制訂開發(fā)計(jì)劃；記錄開發(fā)時間；跟蹤錯誤；在工程摘要報表中保留數(shù)據(jù)；使用已有的數(shù)據(jù)計(jì)劃以后的項(xiàng)目/模塊；分析已有的數(shù)據(jù)以改進(jìn)開發(fā)過程，不斷提高開發(fā)

15、水平。,PSP的使用效果,參加PSP培訓(xùn)的104位軟件人員在應(yīng)用了PSP后:軟件中總的差錯數(shù)減少了58.0％；在測試階段發(fā)現(xiàn)的差錯減少了71.9％；生產(chǎn)效率提高了20.8％,PSP過程,PSP是一個軟件過程的描述、測量和改進(jìn)方法的結(jié)構(gòu)化集合，它可以為軟件工程師帶來更少的錯誤代碼、更好的預(yù)算和計(jì)劃以及更高的生 產(chǎn)率，從而能夠幫助軟件工程師改善其個人性能。 PSP提供了幫助軟件工程師開發(fā)軟件的表格、腳本和標(biāo)準(zhǔn)，以估算和計(jì)劃軟件工程師

16、的工作，以便軟件工程師可以更加清楚自己的個人技術(shù)并且提升個人表現(xiàn)。PSP顯示了如何定義過程及如何測量其質(zhì)量和生產(chǎn)率。,PSP過程,PSP不依賴于任何技術(shù)（語言、工具和設(shè)計(jì)方法），它：示范了軟件過程原則；幫助工程師做正確的計(jì)劃；告訴工程師怎樣提高軟件質(zhì)量；建立個人軟件過程提升的度量標(biāo)準(zhǔn)；確定過程改進(jìn)在工程師表現(xiàn)中的影響。,PSP過程改進(jìn),PSP0（個人過程基線）,PSP0是過程基線，目的是為了在個人的工作中引入表格和腳本，以便工

17、程師按照測量和報告格式記錄軟件過程。 PSP0-1.目前過程：記錄軟件工程師在工程中使用的具有代表性的軟件開發(fā)方法。 PSP0-2.時間記錄：記錄軟件工程師在不同的軟件開發(fā)階段（計(jì)劃、設(shè)計(jì)、編碼、編譯和測試、維護(hù)）所花費(fèi)的時間。,PSP0-3.失誤記錄：按照一致的格式記錄軟件工程師引入軟件中的缺陷，并記錄軟件工程師嘗試解決問題的方法和步驟。 PSP0-4.錯誤分類標(biāo)準(zhǔn)：一方面為軟件工程師提供在系統(tǒng)中可觀察到的典型缺陷種類列表，有助

18、于軟件工程師把典型缺陷標(biāo)準(zhǔn)化；另一方面提供一種預(yù)定義的步驟和工具方便軟件工程師對新的缺陷進(jìn)行歸類和記錄。,PSP0（個人過程基線）,PSP0可以通過增加下列過程而擴(kuò)展到 PSP0.1。 PSP0.1-1.代碼規(guī)范：通過對設(shè)計(jì)過程、開發(fā)過程和設(shè)計(jì)語言結(jié)構(gòu)進(jìn)行規(guī)范，約束具有不同技術(shù)背景和軟件開發(fā)風(fēng)格的軟件工程師。由組織統(tǒng)一制訂設(shè)計(jì)方法和編碼標(biāo)準(zhǔn)。PSP0.1-2.代碼規(guī)模度量：測量代碼的長度、功能、復(fù)雜度、再利用數(shù)、冗余數(shù)等。一般基于某

19、種測量標(biāo)準(zhǔn)進(jìn)行，如LOC，軟件工程師應(yīng)該了解 LOC及相關(guān)測量概念。,PSP0.1（個人過程基線）,PSP0.1-3.過程優(yōu)化計(jì)劃：針對已經(jīng)記錄的軟件過程中的問題和經(jīng)驗(yàn)教訓(xùn)，幫助軟件工程師給出軟件過程能力的改進(jìn)建議，并以結(jié)構(gòu)化的方式表達(dá)軟件過程、問題、建議教訓(xùn)、改進(jìn)建議等項(xiàng)目。,PSP0.1（個人過程基線）,PSP1（個人計(jì)劃過程）,PSP1在PSP0的基礎(chǔ)上增加了計(jì)劃步驟：PSP1-1.規(guī)模估計(jì)：分為代碼規(guī)模估算、時間估算、資源估算

20、。 （1）代碼規(guī)模估算：軟件工程師可以憑借PSP0級代碼規(guī)模測量經(jīng)驗(yàn)預(yù)測他們將要寫的任務(wù)模塊或算法的可能規(guī)模。 （2）時間估算：PSP0級時間測量過程可以總結(jié)出不同復(fù)雜度模塊的編寫時間，憑借這些經(jīng)驗(yàn)，軟件工程師可以針對當(dāng)前系統(tǒng)的模塊結(jié)構(gòu)層次給出完成每個模塊的估算時間（樂觀時間、最可能時間、悲觀時間）。,（3）資源估算：對于軟件開發(fā)的一段生存期，軟件工程師預(yù)測所需要的軟件、硬件和人力資源，其中人力資源預(yù)測包括人力需求、人力成本

21、估算和項(xiàng)目管理標(biāo)準(zhǔn)。PSP1-2.狀態(tài)報告：對軟件工程師的工作進(jìn)行跟蹤，檢查規(guī)模估計(jì)與實(shí)際狀態(tài)之間的差異。,PSP1（個人計(jì)劃過程）,PSP1.1在PSP1的基礎(chǔ)上引入了任務(wù)計(jì)劃和安排。PSP1.1-1.任務(wù)計(jì)劃及安排：基于PSP1中的規(guī)模估計(jì)數(shù)據(jù)制訂軟件項(xiàng)目的需要完成的任務(wù)計(jì)劃，并將任務(wù)按時間段分配給不同的人力資源。一般采納網(wǎng)絡(luò)安排技術(shù)，如PERT(Program Evaluation and Review Techniques)

22、和CPM(Critical Path Method)，軟件工程師應(yīng)該理解網(wǎng)絡(luò)安排技術(shù)和計(jì)劃策略。,PSP1.1（個人計(jì)劃過程）,PSP2（個人質(zhì)量管理）,PSP2強(qiáng)調(diào)提高質(zhì)量，引入了缺陷管理。PSP2-1.代碼審查。對代碼進(jìn)行檢查和分析，以發(fā)現(xiàn)程序缺陷。PSP2-2.設(shè)計(jì)審查。設(shè)計(jì)審查要求提供一些評估設(shè)計(jì)質(zhì)量的指標(biāo)，如：代碼重用率、代碼冗余、代碼完整性和協(xié)作性。設(shè)計(jì)的一致性檢查主要涉及：結(jié)構(gòu)化（控制和數(shù)據(jù)）一致性、耦合一致性、可移植

23、和互用一致性。,PSP2.1（個人質(zhì)量管理）,PSP2.1在PSP2.0基礎(chǔ)上增加了設(shè)計(jì)模板。 設(shè)計(jì)模板提供了設(shè)計(jì)過程的完全標(biāo)準(zhǔn)化，并且連同缺陷預(yù)防、過程分析和過程基準(zhǔn)一起形成了各種設(shè)計(jì)檢驗(yàn)技術(shù)?？深愃频貙⒋朔椒☉?yīng)用到許多過程階段之中去，包括：需求說明、文檔和測試等。,PSP3（循環(huán)個人過程）,PSP3將個人軟件過程的應(yīng)用拓展到大規(guī)模程序開發(fā)當(dāng)中。 將開發(fā)大型程序的個體過程細(xì)分為可以應(yīng)用PSP2的片段，遵照PSP2過程循環(huán)

24、增量地開發(fā)大型程序，從而支持迭代式的開發(fā)。在任何時間點(diǎn)，只有一個PSP2級過程是活動的。,TSP,軟件開發(fā)通常是以團(tuán)隊(duì)形式進(jìn)行的，因此僅有PSP是不夠的。CMU-SEI又以PSP為基礎(chǔ)，開發(fā)了TSP（Team Software Processes），即小組軟件過程。TSP指導(dǎo)項(xiàng)目組中的成員如何有效規(guī)劃和管理所面臨的項(xiàng)目開發(fā)任務(wù)，并且使軟件開發(fā)隊(duì)伍始終以最佳狀態(tài)來完成工作。,TSP實(shí)施集體管理與自我管理相結(jié)合的原則，最終目的在于指導(dǎo)開發(fā)

25、人員如何在最少的時間內(nèi)，以預(yù)定的費(fèi)用生產(chǎn)出高質(zhì)量的軟件產(chǎn)品，所采用的方法是對小組開發(fā)過程進(jìn)行定義、度量和改進(jìn)。小組遠(yuǎn)不只是一群有才能的個人的集合。為了建立并保持高效率的工作關(guān)系，小組需要共同的目標(biāo)，大家一致同意的行動計(jì)劃和適當(dāng)?shù)念I(lǐng)導(dǎo)，小組成員要在需要的時候樂于尋求幫助。,TSP,TSP實(shí)施條件,需要有高層主管和各級經(jīng)理的支持，以取得必要的資源。整個軟件開發(fā)小組至少應(yīng)在CMM的第二級（已管理級）。全體軟件開發(fā)人員必須經(jīng)過PSP的培訓(xùn)

26、，并有按TSP工作的愿望和熱情。開發(fā)小組成員應(yīng)在2到20個人之間。經(jīng)驗(yàn)表明，4~8個人的小組工作效率最高。,TSP的管理原則,TSP遵循集體管理和自己管理自己相結(jié)合的原則。在每一項(xiàng)目階段開始要作好工作計(jì)劃。要有明確定義的目標(biāo)，努力完成已經(jīng)接受的委托任務(wù)。應(yīng)定期追蹤項(xiàng)目進(jìn)展?fàn)顟B(tài)并進(jìn)行定期匯報。按自己管理自己的原則管理軟件過程。按集體管理的原則進(jìn)行管理，全體成員都要參加和關(guān)心小組工作的規(guī)劃、進(jìn)展的追蹤和決策的制訂等項(xiàng)工作。,TS

27、P的循環(huán)開發(fā)策略,TSP通過循環(huán)開發(fā)策略完成產(chǎn)品。先在第一個周期中開發(fā)出最小的合理產(chǎn)品，再決定在接下來的每一個周期中要加進(jìn)去的功能。這樣的步驟可以保證得到一系列最終產(chǎn)品的可運(yùn)行的前期版本。每個周期包括7個步驟：決定策略、進(jìn)行計(jì)劃、考慮需求、設(shè)計(jì)、實(shí)現(xiàn)、測試和最終檢查。,TSP度量要素,對軟件開發(fā)小組進(jìn)行度量的基本要素：所編文檔頁數(shù)；所編代碼行數(shù)；花費(fèi)在各個開發(fā)階段或各個開發(fā)任務(wù)上的時間；在各個開發(fā)階段中注入和改正的差錯數(shù)目；在

28、各個階段對最終產(chǎn)品增加的價值。,TSP度量要素,TSP有關(guān)質(zhì)量度量的經(jīng)驗(yàn)原則：軟件設(shè)計(jì)時間應(yīng)大于軟件實(shí)現(xiàn)時間；設(shè)計(jì)評審時間至少應(yīng)占一半以上的設(shè)計(jì)時間；代碼評審時間應(yīng)大于編制代碼的時間；每千行源程序在編譯階段發(fā)現(xiàn)的差錯不應(yīng)超過10個；每千行源程序在測試階段發(fā)現(xiàn)的差錯不應(yīng)超過5個。,PSP、TSP與CMMI之間的關(guān)系,PSP、 TSP 和CMMI為軟件產(chǎn)業(yè)提供了一個集成化的、三維的軟件過程改革框架。,PSP注重于個人的技能，能夠指

29、導(dǎo)軟件工程師保證自己的工作質(zhì)量，估計(jì)和規(guī)劃自身的工作，度量和追蹤個人的表現(xiàn)，管理自身的軟件過程和產(chǎn)品質(zhì)量。經(jīng)過PSP的學(xué)習(xí)和實(shí)踐，軟件工程師們能夠在他們參與的項(xiàng)目中更為高效和高質(zhì)量地完成工作，從而保證了項(xiàng)目整體的進(jìn)度和質(zhì)量。,PSP、TSP與CMMI之間的關(guān)系,TSP注重團(tuán)隊(duì)的高效工作和產(chǎn)品交付能力，結(jié)合PSP的工程技能，使軟件工程師將個體過程結(jié)合進(jìn)小組軟件過程，并通過指導(dǎo)管理層如何支持和授權(quán)項(xiàng)目小組，堅(jiān)持團(tuán)隊(duì)的高質(zhì)量的工作，并且依據(jù)數(shù)

30、據(jù)進(jìn)行項(xiàng)目管理，以達(dá)到生產(chǎn)高質(zhì)量產(chǎn)品的目的。,PSP、TSP與CMMI之間的關(guān)系,CMMI注重于組織能力和成熟度的提高，它提供了評價組織的能力、改進(jìn)組織過程的管理方式，比TSP具有更高的層次。CMMI關(guān)注“做什么”，PSP和TSP則提供了“怎么做”。,PSP、TSP與CMMI之間的關(guān)系,第六節(jié) 敏捷軟件開發(fā)方法,核心思想：敏捷軟件開發(fā)方法的思想是現(xiàn)代管理理念的延伸，其核心是以人為本，發(fā)揮人的主觀能動性。敏捷軟件開發(fā)方法認(rèn)為，對項(xiàng)

31、目最重要的影響因素是人，而不是過程和技術(shù)。不能把人員當(dāng)做由過程驅(qū)動的“可插拔替換的編程單元”，而要發(fā)揮人的能動性，建立緊密協(xié)作的、自組織的團(tuán)隊(duì)。,核心思想,以過程為核心（而不是以人為核心）的軟件組織為了少犯錯誤，保證項(xiàng)目成功，而從項(xiàng)目開發(fā)經(jīng)驗(yàn)中總結(jié)和定義了許多過程，用于約束開發(fā)行為，避免重復(fù)相同的錯誤。由于項(xiàng)目的復(fù)雜性和多樣性，這種過程定義會越來越多，最終形成一個龐大的、笨重的過程集合，這樣的過程集合會降低開發(fā)效率和產(chǎn)品質(zhì)量，增加開發(fā)成

32、本。,敏捷軟件開發(fā)宣言,我們正在通過親身實(shí)踐以及幫助他人實(shí)踐，揭示更好的軟件開發(fā)方法。通過這項(xiàng)工作，我們認(rèn)為： 人和交互 重于 過程和工具 可以工作的軟件 重于 面面俱到的文檔 客戶合作 重于 合同談判 隨時應(yīng)對變化 重于 遵循計(jì)劃 雖然右項(xiàng)也有其價值，但我們認(rèn)為左項(xiàng)更加重要。,人和

33、交互重于過程和工具,只有好的過程而缺乏合格的人員，不能保證項(xiàng)目不失敗。優(yōu)秀的人員不一定是頂尖的技術(shù)人才，但一定能和其它人員良好地協(xié)作。擁有一般的技術(shù)人才，但能夠有效溝通、緊密協(xié)作的團(tuán)隊(duì)比那種雖擁有技術(shù)精英，但不能有效溝通的團(tuán)隊(duì)更有可能取得成功。,工具雖然重要，但那種最先進(jìn)的、大而復(fù)雜的工具不一定適合組織的需要，而且可能會給組織帶來負(fù)面影響。先嘗試小而靈便的工具。首先要致力于建立團(tuán)隊(duì)，然后讓團(tuán)隊(duì)根據(jù)自己的需要配置工具環(huán)境。,人和交

34、互重于過程和工具,可以工作的軟件重于面面俱到的文檔,過多的文檔會帶來許多負(fù)面影響。需花費(fèi)許多資源來產(chǎn)生這些文檔并保持它們之間的一致性（特別是文檔與編碼之間的一致性）。如果不一致，文檔將成為產(chǎn)生混亂的根源。應(yīng)該書寫一些文檔來描述系統(tǒng)的基本結(jié)構(gòu)和原理，但文檔一定要短而精煉，只用來描述總體設(shè)計(jì)原理和最高層次的系統(tǒng)結(jié)構(gòu)。代碼已包含了最豐富的、且無歧義的系統(tǒng)信息。,當(dāng)有新的成員加入項(xiàng)目團(tuán)隊(duì)，通過與他不斷地交流和密切地合作來使他熟悉當(dāng)前項(xiàng)目，而

35、不是讓他閱讀大量文檔。不要去產(chǎn)生文檔，除非有緊迫而明顯的需求。,可以工作的軟件重于面面俱到的文檔,客戶合作重于合同談判,軟件項(xiàng)目的成功依賴于客戶頻繁的反饋，而不是依賴于與客戶達(dá)成的合同或協(xié)議。合同中所規(guī)定的需求、進(jìn)度和成本很容易變得沒有意義，因?yàn)轫?xiàng)目處在持續(xù)不斷的變化中?？蛻舯仨毭刻炫c開發(fā)團(tuán)隊(duì)一起工作，對開發(fā)團(tuán)隊(duì)的工作及時提供反饋。,隨時應(yīng)對變化重于遵循計(jì)劃,由于項(xiàng)目中存在很多不確定因素，應(yīng)對變化的能力常常決定了項(xiàng)目的成敗。計(jì)劃

36、必須是靈活的，能夠適應(yīng)業(yè)務(wù)和技術(shù)的變化。一個比較好的計(jì)劃策略是：對未來兩星期的工作制定詳細(xì)的計(jì)劃；對未來3個月的工作制定很粗略的計(jì)劃；對更遠(yuǎn)的時間段，則制定最初級的計(jì)劃。,敏捷原則,由敏捷軟件開發(fā)宣言的思想衍生出敏捷軟件開發(fā)的12條原則。（1）我們最優(yōu)先要做的是通過盡早地、持續(xù)地交付有價值的軟件來滿足客戶的需要。有統(tǒng)計(jì)數(shù)字表明，越早、越頻繁地向用戶交付軟件，軟件的質(zhì)量就越好。敏捷開發(fā)方法力求項(xiàng)目開始幾周后，就向用戶交付一個最初的

37、系統(tǒng)，以后每隔兩周就交付一個增加了功能的系統(tǒng)。,對于每次交付的軟件，客戶可以將其投入應(yīng)用，如果軟件的功能還不足以滿足應(yīng)用的需要，就只對其進(jìn)行審查，并提出修改意見。,敏捷原則,敏捷原則,（2）歡迎需求的變化，即使到了開發(fā)的后期。敏捷過程能夠駕馭變化，為客戶創(chuàng)造競爭優(yōu)勢。使用敏捷過程的開發(fā)組織歡迎需求的變化，因?yàn)樗麄冋J(rèn)為需求變化可以讓它們更多地了解市場。敏捷開發(fā)組織采用各種方法和技術(shù)，使軟件的結(jié)構(gòu)高度靈活，需求的變化對系統(tǒng)的影響被最小化

38、。,敏捷原則,（3）頻繁交付可以工作的軟件，從幾個星期到幾個月，時間越短越好。敏捷開發(fā)組織不滿足于交付文檔和計(jì)劃，他們的目標(biāo)是頻繁地交付可以工作的軟件，從而滿足客戶的需要。,（4）在整個項(xiàng)目開發(fā)期間，業(yè)務(wù)人員和開發(fā)人員必須每天工作在一起。軟件項(xiàng)目必須被不斷地調(diào)整和引導(dǎo)，這要求用戶、開發(fā)者和其他利益干系人要頻繁地交流。,敏捷原則,敏捷原則,（5）圍繞斗志高昂的人構(gòu)建項(xiàng)目，給他們提供所需的環(huán)境和支持，并且信任他們能夠完成任務(wù)。在一個敏

39、捷項(xiàng)目中，人員被認(rèn)為是最重要的因素，其它所有因素（過程、環(huán)境、管理等）都被認(rèn)為是次要的，當(dāng)這些因素對人員造成不利影響時，就必須對其做出改變。例如，如果某些過程步驟對團(tuán)隊(duì)人員來說是個障礙，那么過程就必須改變。,（6）在團(tuán)隊(duì)內(nèi)部，最有效率和最有效果的信息傳達(dá)方式就是面對面的交流。在敏捷項(xiàng)目中，主要的交流方式就是交談。文檔在必要的時候會被創(chuàng)建，但不會試圖用文檔來捕獲所有項(xiàng)目信息。在敏捷項(xiàng)目組中，默認(rèn)的交流方式是交談，而不是文檔。,敏捷原

40、則,（7）可以工作的軟件是進(jìn)度的主要度量標(biāo)準(zhǔn)。對于敏捷項(xiàng)目來說，進(jìn)度的度量標(biāo)準(zhǔn)是當(dāng)前可滿足用戶需求的軟件的量，而不是當(dāng)前項(xiàng)目所處的階段、文檔數(shù)量或基礎(chǔ)代碼的數(shù)量。項(xiàng)目完成了30%的含義是30%的用戶所需功能已被實(shí)現(xiàn)。,敏捷原則,（8）敏捷過程提倡可持續(xù)開發(fā)。出資人、開發(fā)者和用戶應(yīng)該共同維持一個穩(wěn)定的開發(fā)速度。敏捷小組會在整個項(xiàng)目開發(fā)期間保持一個適當(dāng)?shù)?、可持續(xù)的開發(fā)速度，從而維持最高的質(zhì)量標(biāo)準(zhǔn)。敏捷項(xiàng)目不會使開發(fā)者感到疲憊不堪。,敏

41、捷原則,（9）對卓越技術(shù)和良好設(shè)計(jì)的不斷追求有助于提高敏捷性。敏捷開發(fā)團(tuán)隊(duì)認(rèn)為提高質(zhì)量會加快開發(fā)進(jìn)度。因此要保持軟件的精簡和健壯。敏捷開發(fā)團(tuán)隊(duì)的每個成員都要致力于開發(fā)高質(zhì)量的代碼，不能把混亂的、底質(zhì)量的代碼留到以后去修改。,敏捷原則,（10）簡單——盡量減少工作量的藝術(shù)是至關(guān)重要的。敏捷開發(fā)方法總是選擇達(dá)到目標(biāo)的最簡單途徑。敏捷開發(fā)團(tuán)隊(duì)并不花費(fèi)大量精力去預(yù)防將來可能出現(xiàn)的問題，而是專注于對當(dāng)前工作采用最簡單、最高質(zhì)量的解決方案，

42、并相信將來如果問題出現(xiàn)，可以很方便地進(jìn)行修改。,敏捷原則,（11）最好的架構(gòu)、需求和設(shè)計(jì)都出自于自組織的團(tuán)隊(duì)。敏捷開發(fā)團(tuán)隊(duì)是自組織的團(tuán)隊(duì)。職責(zé)并非是從團(tuán)隊(duì)外部加給每一個團(tuán)隊(duì)成員，而是團(tuán)隊(duì)作為一個整體接受職責(zé)并自己決定怎樣去完成它。敏捷開發(fā)團(tuán)隊(duì)成員在項(xiàng)目的各個方面（架構(gòu)、需求、測試等）都是共同負(fù)責(zé)的，不會出現(xiàn)某一人單獨(dú)負(fù)責(zé)一方面任務(wù)的情況。,敏捷原則,（12）每隔一定時間，團(tuán)隊(duì)都要總結(jié)怎樣更有效率地工作，然后相應(yīng)地調(diào)整自己的行為。敏

43、捷開發(fā)團(tuán)隊(duì)認(rèn)識到環(huán)境在不斷地改變，因此團(tuán)隊(duì)也需要不斷地對組織、規(guī)則、慣例和各種關(guān)系進(jìn)行調(diào)整，以保持自身的敏捷性。,敏捷原則,極限編程實(shí)踐,符合敏捷軟件開發(fā)思想和原則的具體實(shí)踐方法有多種，如極限編程（XP）、Scrum、Crystal Methods、FDD等。極限編程（Extreme Programming，XP）是最著名的敏捷開發(fā)方法，它由一系列簡單的、互相依賴的最佳實(shí)踐組成。,客戶也是開發(fā)團(tuán)隊(duì)成員,客戶作為開發(fā)團(tuán)隊(duì)的成員，與開發(fā)人

44、員密切合作，共同解決存在的問題。,短交付周期,XP項(xiàng)目每兩周向客戶交付一次軟件，所交付的軟件涉及客戶的一部分需求，客戶要及時作出反饋。為了實(shí)現(xiàn)短交付周期，項(xiàng)目組需要制定迭代計(jì)劃和發(fā)布計(jì)劃。兩周為一個迭代周期，迭代代表向用戶的一次產(chǎn)品交付，是用戶所需功能的一個集合。六個迭代（約三個月時間）形成一個發(fā)布（Release），發(fā)布是一個主要的產(chǎn)品交付，會被集成到最終產(chǎn)品中。,項(xiàng)目組必須為每次迭代和發(fā)布制定預(yù)算。用戶根據(jù)預(yù)算來選擇迭代和發(fā)布中

45、所包含的功能。,短交付周期,結(jié)對編程,兩個程序員用一臺電腦一起工作，其中一人操作鍵盤，輸入程序，另一人與他密切交流，檢查錯誤和需要改進(jìn)的地方。兩人的角色頻繁互換。所編寫的代碼由兩人共同負(fù)責(zé)。每個程序員至少每天更換一次配對的對象，這樣當(dāng)一個迭代結(jié)束后，每個程序員都與小組中所有其它程序員配過對，工作涉及到本次迭代的所有內(nèi)容。,結(jié)對編程能夠極大地促進(jìn)知識在團(tuán)隊(duì)中的傳播，沒有任何一個程序模塊由單獨(dú)一人完成，這樣就保證了任何人的工作在必要時都

46、可由其他人代替完成。經(jīng)驗(yàn)證明，結(jié)對編程沒有降低開發(fā)團(tuán)隊(duì)的效率，而且大幅度地減小了缺陷率。,結(jié)對編程,集體所有權(quán),代碼歸集體所有，團(tuán)隊(duì)中的所有成員都有權(quán)訪問和改進(jìn)項(xiàng)目的所有模塊代碼。沒有一個人單獨(dú)負(fù)責(zé)某一模塊或技術(shù)。集體所有權(quán)可促進(jìn)交流，增強(qiáng)團(tuán)隊(duì)凝聚力和發(fā)揮集體創(chuàng)造力。,可持續(xù)的開發(fā)速度,軟件項(xiàng)目不是短跑，而是馬拉松，它需要一個可持續(xù)的速度，能夠保持能量和敏銳性。極限編程的一個原則是“不要加班”，但也有例外，即在一個發(fā)布周期的最后

47、一周加班是允許的，因?yàn)檫@時可能需要加速以達(dá)到發(fā)布目標(biāo)。,開放工作空間,開發(fā)小組在一個大的辦公區(qū)域中一同工作，每個桌子上放兩到三臺電腦，墻上可以張貼狀態(tài)圖、任務(wù)分解圖等各種圖表。這樣的工作環(huán)境便于交流，每個人員都可以及時了解到小組其他人員的工作狀態(tài)，知道他們是否遇到了麻煩。,計(jì)劃游戲,XP項(xiàng)目計(jì)劃的主導(dǎo)思想是將業(yè)務(wù)責(zé)任和開發(fā)責(zé)任相分離。業(yè)務(wù)人員（客戶）確定哪些產(chǎn)品特征是重要的，開發(fā)人員確定實(shí)現(xiàn)這些特征需花費(fèi)多少成本。在每個迭代或發(fā)布周

48、期的開始，開發(fā)人員交給客戶一個預(yù)算，說明在該迭代或發(fā)布周期中能夠完成多少工作，客戶根據(jù)這個預(yù)算選擇需實(shí)現(xiàn)哪些產(chǎn)品功能。,敏捷軟件開發(fā)方法參考資料,《解析極限編程：擁抱變化（第二版）》，Kent Beck著，電子工業(yè)出版社《敏捷軟件開發(fā)：原則、模式與實(shí)踐》，Robert C. Martin著，人民郵電出版社,敏捷開發(fā)方法是針對傳統(tǒng)的重量級開發(fā)方法的缺點(diǎn)而提出的，但它并沒有全盤否定重量級開發(fā)方法。兩種方法不是誰取代誰的關(guān)系，它們互相吸取