項(xiàng)目管理是一項(xiàng)非常有挑戰(zhàn)性的工作,尤其是軟件項(xiàng)目管理。做項(xiàng)目管理的人都知道“項(xiàng)目三角形”法則,也就是制約項(xiàng)目的三個(gè)因素———時(shí)間、成本、范圍各構(gòu)成三角形的一邊,其中一個(gè)因素的變化必然引起另一個(gè)或者兩個(gè)同時(shí)發(fā)生變化。
　　例如項(xiàng)目要趕進(jìn)度(縮短項(xiàng)目時(shí)間),可以投入成本、增加人力,或者將原定計(jì)劃要實(shí)現(xiàn)的范圍縮小,如何做取舍就要靠項(xiàng)目經(jīng)理進(jìn)行權(quán)衡選擇。如果要做個(gè)譬喻,項(xiàng)目經(jīng)理不亞于是“在針尖上跳舞”的舞者,他甚至可能要在捉襟見肘的寸方三角形舞臺上導(dǎo)出一段“不可能完成任務(wù)”(mission impossible)的“群舞”。
　　1 范圍管理概論
　　項(xiàng)目經(jīng)理如此不幸,而軟件項(xiàng)目經(jīng)理就更可以說是“不幸中的不幸”,因?yàn)楦鶕?jù)經(jīng)典數(shù)據(jù)統(tǒng)計(jì),軟件開發(fā)項(xiàng)目的成功率目前不超過50%,如果時(shí)光回退十幾年,這個(gè)數(shù)字會(huì)再低十個(gè)百分點(diǎn),而且對于規(guī)模越大的項(xiàng)目,其成功率越低。
　　到底是哪些原因?qū)е氯绱说偷某晒β?通過對過往失敗項(xiàng)目案例進(jìn)行整理和分析,人們生了問題才臨時(shí)采取行動(dòng),試圖迅速地解決問題。這樣的管理方式往往讓項(xiàng)目組很被動(dòng),也大大增加了管理成本,并使項(xiàng)目的進(jìn)度面臨很大的風(fēng)險(xiǎn),所以必須采用主動(dòng)式的風(fēng)險(xiǎn)管理模式,防患于未然。
　　發(fā)現(xiàn)其中一個(gè)主要的“敗因”是范圍管理失去了控制,從而引發(fā)“范圍蔓延”(Scope Creep),以這種方式失敗的項(xiàng)目表現(xiàn)為:項(xiàng)目已經(jīng)比原定計(jì)劃大大延期,客戶仍在源源不斷地有新需求,或者對已經(jīng)完成的功能提出各種修改意見,開發(fā)團(tuán)隊(duì)士氣低迷,總有完不成的開發(fā)任務(wù),項(xiàng)目預(yù)算已幾乎消耗殆盡,而距離項(xiàng)目收尾卻遙遙無期。
　　范圍管理難在何處?通過對以這類原因失敗的項(xiàng)目進(jìn)行分析和總結(jié),大致可以歸為客戶方和開發(fā)方兩大“責(zé)任方”。這里有兩種觀點(diǎn)。
　　(1) 責(zé)任在于客戶。這類觀點(diǎn)通常是由開發(fā)方“總結(jié)”得出的,經(jīng)常從開發(fā)方的技術(shù)人員口中聽到諸如此類的抱怨,“我們的客戶從項(xiàng)目一開始就不清楚需要做什么”,“他們總是在變,今天想要這個(gè),明天又想要那個(gè),更難以忍受的是他們的要求又往往是矛盾的”,這種來自于客戶方的需求“模糊”以及“朝三暮四”,使得項(xiàng)目的范圍充滿了不確定性,而開發(fā)方頭上懸著“范圍”—“時(shí)間”—“成本”這一“項(xiàng)目三角形”達(dá)摩克利斯之劍,范圍的變動(dòng)就意味著項(xiàng)目開發(fā)周期的延長和成本增加,帶來的嚴(yán)重后果就是項(xiàng)目嚴(yán)重超支、項(xiàng)目延期難以交付而導(dǎo)致最終的項(xiàng)目失敗。
　　(2)責(zé)任在于開發(fā)方。幸運(yùn)的是開放方的責(zé)任并不是客戶“投桃報(bào)李”總結(jié)出來的,開發(fā)方擁有很好的自覺反省,自己道出了“苦水”。他們通常認(rèn)為,項(xiàng)目失敗很大的一個(gè)主因是范圍的定義不夠明確,做不到可量化、可驗(yàn)證的程度,因而在進(jìn)度和成本的量度和控制上面引發(fā)了多米諾效應(yīng),最后導(dǎo)致項(xiàng)目的“滑鐵盧”。
　　而為什么項(xiàng)目開發(fā)方的管理團(tuán)隊(duì)無法做到范圍界定明確的程度,原因有以下幾個(gè):
　　1)開發(fā)方缺乏規(guī)范的項(xiàng)目范圍管理過程是最主要的原因。比如缺少范圍評審環(huán)節(jié),開發(fā)方與客戶方無法在項(xiàng)目開頭就對項(xiàng)目范圍進(jìn)行很好的商討、澄清,并達(dá)成共識而且共同簽署范圍確認(rèn)書,給后來的范圍蔓延埋下隱患;
　　又比如開發(fā)方?jīng)]有對變更進(jìn)行有效的管理控制,在項(xiàng)目進(jìn)行過程中,面對客戶方“漫天要價(jià)”提出的后續(xù)需求缺乏有效變更系統(tǒng)加以辨別、遴選、記錄和處理,最終由“量變”引發(fā)“質(zhì)變”,項(xiàng)目范圍遠(yuǎn)遠(yuǎn)超出最初預(yù)計(jì)。
　　2)開發(fā)方缺乏正確的方法作為指導(dǎo)。這里的方法即指軟件工程領(lǐng)域中的方法,比如需求采集方法,也指項(xiàng)目管理中的方法,比如在范圍分解的時(shí)候,運(yùn)用正確的工作分解結(jié)構(gòu)(WBS)法進(jìn)行范圍劃分。
　　3)沒有使用必要的項(xiàng)目管理工具進(jìn)一步加強(qiáng)范圍管理以及其他管理活動(dòng),給項(xiàng)目成功帶來更高的保險(xiǎn)系數(shù)。典型的工具有微軟的Project 2000,以及IBM的統(tǒng)一項(xiàng)目管理平臺。
　　以上對范圍管理失控原因的總結(jié)和分析都很有道理,從中拿出任何一條,都可以在眾多失敗的項(xiàng)目中找到支持的佐證。為了解決范圍管理這個(gè)難題,項(xiàng)目管理協(xié)會(huì)(PMI)和軟件工程協(xié)會(huì)(SEI)都提出相應(yīng)的范圍管理體系。
　　PMI的項(xiàng)目管理知識體系指南(PM-BOK)對范圍管理的定義是“為了成功完成項(xiàng)目,需要確保項(xiàng)目包括所需的全部工作,但又只包括必須完成的工作的各個(gè)過程”,從這個(gè)定義可以得知PMI的范圍管理是一個(gè)過程管理,它關(guān)注的是在項(xiàng)目進(jìn)行過程中的各項(xiàng)工作活動(dòng)需要圍繞項(xiàng)目交付展開,既要包含所有必需的活動(dòng),也不能包含不必要的活動(dòng),簡而言之就是不多不少(just-in-time)。PMI的范圍管理主要?jiǎng)澐譃槲鍌€(gè)過程展開,這五個(gè)過程分別是范圍規(guī)劃(planning)、范圍定義(definition)、范圍分解(break-down)、范圍核實(shí)(verification)以及范圍變更控制(con-trol),這五個(gè)過程是這么定義的。
　　(1)范圍規(guī)劃。規(guī)劃主要指的是實(shí)現(xiàn)范圍管理的策略,比如通過什么辦法來采集需求以得到項(xiàng)目范圍,以什么方式來進(jìn)行范圍分解等,范圍規(guī)劃相當(dāng)于整個(gè)范圍管理的一個(gè)計(jì)劃,這個(gè)過程主要是得出一份項(xiàng)目范圍管理計(jì)劃書。
　　(2)范圍定義。在范圍管理計(jì)劃的指導(dǎo)下,對要交付的項(xiàng)目制品進(jìn)行分析,或者對歷史同類項(xiàng)目制品進(jìn)行識別,編寫出一份項(xiàng)目范圍說明書。
　　(3)范圍分解。利用定義過程輸出的項(xiàng)目范圍說明書,按層次將項(xiàng)目制品分解成較小的可交付部分,同時(shí)也將項(xiàng)目工作分成較小和更便于管理的多項(xiàng)子工作,分解后得到一個(gè)樹狀分解結(jié)構(gòu),“根”代表項(xiàng)目,底層組成部分(“樹葉”)的計(jì)劃工作稱作“工作包”,這些工作包可以安排在進(jìn)度表中,進(jìn)行費(fèi)用估算以及監(jiān)控。
　　(4)范圍核實(shí)。范圍核實(shí)將對上述過程產(chǎn)生的成果進(jìn)行評審,如開發(fā)方的項(xiàng)目管理委員會(huì)召開專家評審會(huì)議進(jìn)行范圍評估,范圍核實(shí)也包括在項(xiàng)目收尾階段客戶對項(xiàng)目制品進(jìn)行驗(yàn)收的過程。
　　(5)范圍控制。范圍控制將對造成項(xiàng)目范圍變更的因素施加影響,并控制變更造成的后果,PMI認(rèn)為變更是不可避免的,但是必須強(qiáng)制一定形式的變更控制過程,使得變更盡量可控。
　　綜合而論,PMI的范圍管理定義了一個(gè)過程棧,在這個(gè)過程棧中以上一個(gè)過程的輸出(通常是一個(gè)或多個(gè)文檔)作為輸入,采用組織既有的資產(chǎn)(比如文檔模板、表格、歷史項(xiàng)目數(shù)據(jù))以及方法(比如專家判斷)進(jìn)行處理,然后得到一份或多份結(jié)果文檔,而這些結(jié)果文檔又可以作為下一過程的輸入。通過有序的過程將項(xiàng)目利益相關(guān)方以及有關(guān)資源組織起來,并且通過專家判斷、會(huì)議評審等方法,使項(xiàng)目范圍定義漸進(jìn)地得到明朗化,使其定義和分解較為全面與合理,達(dá)到可量化、可計(jì)劃、可控制的一個(gè)良好管理狀態(tài)。
　　2 軟件項(xiàng)目中的范圍管理
　　PMI只對項(xiàng)目范圍的管理提供指導(dǎo),不涉及具體的應(yīng)用領(lǐng)域,比如軟件開發(fā)領(lǐng)域,因而PMBOK只是一個(gè)通用項(xiàng)目管理的指導(dǎo)體系,要完整地進(jìn)行范圍管理,還須結(jié)合特定的應(yīng)用領(lǐng)域加以運(yùn)用。對于軟件開發(fā)項(xiàng)目來說,項(xiàng)目制品指項(xiàng)目要交付的軟件產(chǎn)品,因?yàn)轫?xiàng)目范圍取決于產(chǎn)品范圍,所以軟件的項(xiàng)目范圍管理依賴于軟件產(chǎn)品范圍管理,軟件產(chǎn)品范圍則來源于軟件的使用者———客戶對軟件所提出的需求。由于認(rèn)識到軟件需求的重要性,在20世紀(jì)80年代中期,從SEI中分離并形成了軟件工程的子領(lǐng)域———需求工程(Require-ment Engineering,RE)。
　　進(jìn)入到20世紀(jì)90年代,需求工程逐漸成為研究的熱點(diǎn)之一,1993年起每兩年舉辦一次需求工程國際研討會(huì)(ISRE),1994年起每兩年舉辦一次需求工程國際會(huì)議(ICRE)。此外一些關(guān)于需求工程的工作小組也相繼成立,如歐洲的RENOIR(Requirements Engineering Network of International Co-operating Research Groups),并開始開展與需求工程研究有關(guān)的各項(xiàng)工作。需求工程研究使用已證實(shí)有效的技術(shù)、方法進(jìn)行需求分析,確定用戶需求,幫助分析人員理解問題并定義目標(biāo)系統(tǒng)的所有外部特征。
　　與軟件工程提出的生命周期類似,需求工程也有需求生命周期,它將最初用戶的設(shè)想和要求通過一系列過程,并采用適合的工程方法轉(zhuǎn)化為可以指導(dǎo)軟件開發(fā)的需求規(guī)格,并提出要對這些需求進(jìn)行相應(yīng)的管理以跟蹤和控制。
　　從上述特征來看,需求工程與PMI的范圍管理實(shí)質(zhì)上都是過程管理,而且重點(diǎn)在于各種說明詳盡的文檔編制,通過文檔來驅(qū)動(dòng)和指導(dǎo)開發(fā),以求做到任何的進(jìn)展和變動(dòng)都有文檔記錄和跟蹤,在開發(fā)流程和開發(fā)文檔的雙重保險(xiǎn)機(jī)制下,盡可能避免發(fā)生差錯(cuò),提高過程控制能力。
　　但是依靠過程式的管理是否完全適合軟件這樣一種特別的項(xiàng)目制品?是否能夠有效地對范圍進(jìn)行管理,以提高項(xiàng)目成功系數(shù)?回答這個(gè)問題可以從三個(gè)方面入手:第一,軟件這種制品有什么特征;第二,如何衡量一個(gè)軟件開發(fā)項(xiàng)目的成功;第三,管理的本質(zhì)又是什么。
　　先來看軟件這一特殊的項(xiàng)目制品,說它特殊是因?yàn)檐浖煌诳梢姷挠行挝锲?有形物品比如房屋、橋梁可以用計(jì)量單位和計(jì)量方法進(jìn)行描述和標(biāo)識,比如建筑物的位置、高度、面積、體積及空間位置等,軟件則不然,軟件是運(yùn)行于計(jì)算機(jī)中的代碼,它不是有形實(shí)體,無法進(jìn)行嚴(yán)格而且形象的量化。軟件要模擬并解決人在現(xiàn)實(shí)世界中發(fā)生的活動(dòng)事務(wù),而人的活動(dòng)與事務(wù)又是千差萬別,不同組織不同人其行事方式各有不同,期待的結(jié)果也不一,這就是具備相同功能的同一個(gè)軟件產(chǎn)品不能完全適用于所有客戶的原因,用軟件行業(yè)術(shù)語講需要進(jìn)行“本地化”和“客戶化”以滿足不同需求。軟件所能滿足的對象就是所說的客戶,軟件的生產(chǎn)者即開發(fā)方,一個(gè)軟件從最初的想法到具體構(gòu)思,再到設(shè)計(jì)和實(shí)現(xiàn)這一系列過程,需要客戶向開發(fā)方描述所要構(gòu)建的是一個(gè)什么樣的系統(tǒng),
　　將解決和能解決什么問題,最終達(dá)到什么樣的一個(gè)效果,這個(gè)過程需要雙方的溝通,以達(dá)成對要構(gòu)建系統(tǒng)的較為一致的認(rèn)識。但是正如我們熟知的,在溝通的過程中,人們所處的觀察角度不同,思考方式不同,表達(dá)方式也不盡相同,這都會(huì)導(dǎo)致信息在傳達(dá)過程中發(fā)生丟失與變形,會(huì)出現(xiàn)客戶所想不是開發(fā)方所做的這么一種狀況,有人將客戶與開發(fā)方這種矛盾做了有趣的比方,“客戶奢望得到一張沙發(fā),開發(fā)人員卻提供一條板凳;客戶僅要求得到一把椅子,開發(fā)人員卻提供了一張豪華沙發(fā)”。也正是這種矛盾,才會(huì)出現(xiàn)客戶方在軟件需求上面為什么會(huì)“朝三暮四”,因?yàn)榈谝?客戶方對要做什么是一個(gè)由淺入深的過程,剛開始需求提出少是因?yàn)檎J(rèn)識不夠,隨著項(xiàng)目深入其認(rèn)識也逐步加深,對于系統(tǒng)要構(gòu)建成什么樣子更加明朗化,自然需求就提得越多;
　　第二,項(xiàng)目是一個(gè)過程,它跨越一個(gè)時(shí)間階段,在這個(gè)階段中客戶的活動(dòng)方式和事務(wù)內(nèi)容往往會(huì)發(fā)生變化,在這個(gè)時(shí)候軟件的開發(fā)也隨之發(fā)生變化是一個(gè)再自然不過的事情,而且規(guī)模越大、時(shí)間跨度越大的項(xiàng)目就越是要面臨這種挑戰(zhàn)。
　　再反觀過程式管理,該管理模式要求項(xiàng)目一開始就能較清楚地確定要完成事項(xiàng)的大致范圍,進(jìn)而安排計(jì)劃進(jìn)度,確定投入的成本與資源,顯然這與軟件這一特殊項(xiàng)目制品漸進(jìn)和反復(fù)式的構(gòu)建特點(diǎn)以及構(gòu)建過程有相違的地方。
　　過程式管理理論源于20世紀(jì)初的機(jī)器工業(yè)生產(chǎn)時(shí)代,管理的對象是機(jī)器化作業(yè)流程以及流程中的生產(chǎn)者,典型的代表是流水線作業(yè),這種管理對于固定生產(chǎn)方式是非常有效的,因?yàn)橐坏┳鳂I(yè)流程和單位人員生產(chǎn)效率確定之后,輸入和產(chǎn)出間有一個(gè)線性關(guān)系,自然也就可以進(jìn)行量化和計(jì)劃,并通過計(jì)劃來指導(dǎo)和管理生產(chǎn),投入成本、產(chǎn)量、交付時(shí)間等可以做到比較準(zhǔn)確而沒有多大偏差,但是由于軟件制品的上述產(chǎn)品特征以及其漸進(jìn)的過程特征,這種線性管理模式比較難發(fā)揮作用,因?yàn)閺囊婚_始它就缺乏準(zhǔn)確的量化作為輸入,并且計(jì)劃一旦形成,就很難再適應(yīng)后續(xù)需求的變化。
　　再來看一個(gè)軟件項(xiàng)目如何才算成功,由于軟件項(xiàng)目牽涉兩方,那么自然成功的衡量標(biāo)準(zhǔn)是同時(shí)滿足兩方的期待。客戶方是軟件產(chǎn)品的投入者,其期待自然就是產(chǎn)出,這種產(chǎn)出從商業(yè)角度講就是獲得價(jià)值,無論這種價(jià)值是以什么樣一種方式提供,比如客戶通過軟件產(chǎn)品節(jié)約運(yùn)作成本,提高工作效率,或者是給用戶提供更好的服務(wù)質(zhì)量,增強(qiáng)企業(yè)競爭力,直接產(chǎn)生經(jīng)濟(jì)效益等。對于軟件開發(fā)方來說,作為一個(gè)商業(yè)實(shí)體其期待是通過項(xiàng)目獲取開發(fā)利潤,能否獲取到預(yù)期的利潤自然又回到“項(xiàng)目三角形”這個(gè)簡單的原理,當(dāng)項(xiàng)目的范圍、時(shí)間、成本符合計(jì)劃預(yù)期時(shí),項(xiàng)目可以獲得最大的贏利,反之如果這三個(gè)因素有一個(gè)增大,利潤就減少,因此開發(fā)方的項(xiàng)目經(jīng)理顯然更操心的是計(jì)劃制訂的合理性,希望范圍能夠定得準(zhǔn)確,希望計(jì)劃能夠做得完美,希望變更不要太多,希望項(xiàng)目進(jìn)展一如預(yù)期。然而正如人們常說的,世間沒有兩全其美的事,“魚與熊掌不可兼得”,而且應(yīng)該可以看到客戶方和開發(fā)方兩邊的期待其實(shí)暗含一種此消彼長的邏輯關(guān)系,那么假定在極端情況下,如果只可以確保一方的利益,應(yīng)該優(yōu)先考慮哪一方呢?無論是從“甲方乙方”這個(gè)簡單商業(yè)原則,或者從項(xiàng)目最終是為了提供特定產(chǎn)品、服務(wù)、成果這個(gè)宗旨來看,應(yīng)該優(yōu)先考慮的是客戶這一方,因?yàn)橹挥性诳蛻羧〉贸晒?、?shí)現(xiàn)增值目標(biāo)的前提下,開發(fā)方才獲得真正意義的最大“利潤”。
　　從一些著名的項(xiàng)目實(shí)例可以找到對這一選擇的支持,“銥星”是摩托羅拉耗費(fèi)巨資投入的一個(gè)項(xiàng)目,盡管項(xiàng)目進(jìn)展一如預(yù)期,但是這個(gè)項(xiàng)目最終卻沒有給摩托羅拉帶來商業(yè)上的成功,這無疑是個(gè)徹頭徹尾失敗的項(xiàng)目;電影《泰坦尼克號》的拍攝嚴(yán)重超支超時(shí),早期被批評家認(rèn)為2億美金打了水漂,但是最后卻成為全球第一部超過10億票房收入的電影,毫無疑問這是一個(gè)經(jīng)典的成功項(xiàng)目。過程式管理強(qiáng)調(diào)計(jì)劃、控制,而審慎詳盡的計(jì)劃往往耗時(shí)費(fèi)力,又難免遇到范圍信息輸入較少這樣的尷尬境界,因而如果項(xiàng)目經(jīng)理死守一份僵化的計(jì)劃,為了維護(hù)“項(xiàng)目三角”關(guān)系,有意無意地利用事先設(shè)置的種種流程環(huán)節(jié)以拖延、回避、拒絕合理的范圍變更,所導(dǎo)致的嚴(yán)重后果勢必是交付給客戶一個(gè)不符合期待、不能創(chuàng)造價(jià)值的平庸軟件產(chǎn)品,甚至可能成為客戶日常作業(yè)的“累贅”,或者是“食之無味”的“雞肋”。應(yīng)該找到一種管理方法,使得項(xiàng)目既能滿足客戶的要求,又能為客戶帶來真正的價(jià)值,并且使客戶方與開發(fā)方實(shí)現(xiàn)一種“雙贏”的合作方式,很顯然單獨(dú)依靠過程管理難以做到這點(diǎn)。最后來看管理的本質(zhì)。無論軟件是如何一種特殊的制品,其管理仍是通常意義“管理”中的一種,它的管理目標(biāo)、管理方法應(yīng)該與通常意義的“管理”一致。
　　對于“管理是什么”這樣一個(gè)深?yuàn)W的本體論話題,誕生了百年的管理學(xué)界仍無法形成統(tǒng)一的看法,盡管如此,對于管理包含什么,具備什么職能,實(shí)現(xiàn)什么目標(biāo)還是比較明確。管理存在于人類社會(huì),自從出現(xiàn)了群體以及發(fā)生了共同勞動(dòng),就出現(xiàn)了管理,管理將獨(dú)立分散的生產(chǎn)要素結(jié)合起來,以完成特定群體即組織的共同目標(biāo),并且在實(shí)現(xiàn)這個(gè)共同目標(biāo)的過程中,管理可以并且必須充分發(fā)揮各個(gè)組織以及成員的潛能。軟件開發(fā)說其特殊,是因?yàn)槠渲饕?ldquo;生產(chǎn)要素”是人,不像一個(gè)生產(chǎn)流水線,軟件生產(chǎn)甚至不需要提供一個(gè)固定的生產(chǎn)空間—廠房,軟件生產(chǎn)可以是分布在地球任何角落的一個(gè)或者多個(gè)個(gè)體———程序員或者開發(fā)組織;也不需要強(qiáng)制規(guī)定工作時(shí)間,因?yàn)橛行╅_發(fā)人員的晚上工作效率往往高于白天;軟件生產(chǎn)的產(chǎn)出并不是線性的,當(dāng)遇到技術(shù)難題的時(shí)候,開發(fā)人員會(huì)被擱置在難點(diǎn)攻關(guān)上而不產(chǎn)生任何可見的成果,比如一行代碼,如果在思維活躍的時(shí)候,開發(fā)人員又可能會(huì)變得異常高效,他可以在幾天當(dāng)中完成原計(jì)劃需要半個(gè)月甚至更長時(shí)間的任務(wù)。“軟件產(chǎn)品開發(fā)主要基于人”這樣一個(gè)最大的生產(chǎn)特性被過程式管理所忽略,因?yàn)檫^程式管理的一個(gè)出發(fā)點(diǎn)和作用是防范整個(gè)過程體系中有個(gè)別人能力不足或者由于人員流失而給組織帶來損失,防范由于人的自由性使事情偏離預(yù)想軌道,因此通過在一系列過程中安排檢查點(diǎn)及時(shí)進(jìn)行糾偏,并且設(shè)置層級的組織結(jié)構(gòu)對此進(jìn)行制約。過程式管理在生產(chǎn)型組織中做得非常成功,但在軟件項(xiàng)目開發(fā)中并沒有預(yù)期的理想,因此軟件開發(fā)應(yīng)該需要這么一個(gè)管理體系,它能夠發(fā)揮人的主觀能動(dòng)性,激發(fā)團(tuán)隊(duì)合作潛能,實(shí)現(xiàn)客戶提出的有價(jià)值的業(yè)務(wù)“思維”,開發(fā)出軟件這樣一種“純思想”的制品,最終提供客戶價(jià)值。這個(gè)更能適合軟件項(xiàng)目開發(fā)的管理體系需要引入的是“敏捷”。