軟件項目管理

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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