統(tǒng)一的六段式項目策劃管理方法

1、統(tǒng)一的六段式項目治理方法從經(jīng)濟(jì)學(xué)角度改進(jìn)軟件項目治理過程（作者：Ezra Thomad）摘要：軟件工程項目，歸根到底是一種經(jīng)濟(jì)生產(chǎn)活動，它應(yīng)該遵循經(jīng)濟(jì)的規(guī)律，以更趨近經(jīng)濟(jì)利潤和成功滿足需求為目標(biāo)。軟件項目瀑布、敏捷、螺旋、迭代模型的紛亂，能夠借鑒上千年來人們在建筑工程上的經(jīng)驗，使之更規(guī)范、科學(xué)、有益于項目的成功。 將項目治理統(tǒng)一為六個時期，并提出每個時期的本質(zhì)與目標(biāo)特征，能將建筑、軟件等所有項目治理統(tǒng)一在一個框架下，更加符合人們的認(rèn)知和工程項目治理的合理化。 六段式治理方法，規(guī)避風(fēng)險、高效有用、斷點清晰。系統(tǒng)的分析與設(shè)計獨立出來，將會成為軟件工程項目的核心，系統(tǒng)分析者職業(yè)化是以后軟件工程的亟需

2、和趨向。目錄 TOC o 1-2 h z u HYPERLINK l _Toc380857278 一、軟件工程項目與建筑項目治理的統(tǒng)一 PAGEREF _Toc380857278 h 2 HYPERLINK l _Toc380857279 二、統(tǒng)一的六段式項目治理過程 PAGEREF _Toc380857279 h 2 HYPERLINK l _Toc380857280 六時期分不定義、特征、實踐注意點 PAGEREF _Toc380857280 h 2 HYPERLINK l _Toc380857281 三、六段式項目治理與傳統(tǒng)方法的對比和優(yōu)勢 PAGEREF _Toc380857281 h

3、 7 HYPERLINK l _Toc380857282 六段式項管與早期分段法、瀑布模型 PAGEREF _Toc380857282 h 7 HYPERLINK l _Toc380857283 六段式項管與產(chǎn)品迭代模型 PAGEREF _Toc380857283 h 9 HYPERLINK l _Toc380857284 六段式項管與RUP PAGEREF _Toc380857284 h 10 HYPERLINK l _Toc380857285 四、六段式項目治理與常見問題辨析 PAGEREF _Toc380857285 h 12 HYPERLINK l _Toc380857286 六段式項

4、管與需求變更 PAGEREF _Toc380857286 h 12 HYPERLINK l _Toc380857287 六段式項管與敏捷開發(fā) PAGEREF _Toc380857287 h 16 HYPERLINK l _Toc380857288 系統(tǒng)分析師和軟件架構(gòu)師、PdM和PjM PAGEREF _Toc380857288 h 20 HYPERLINK l _Toc380857289 五、六段式項目治理規(guī)范化 PAGEREF _Toc380857289 h 22 HYPERLINK l _Toc380857290 六、以后軟件工程和系統(tǒng)分析之路 PAGEREF _Toc380857290

5、 h 26一、軟件工程項目與建筑項目治理的統(tǒng)一軟件工程越來越成為技術(shù)進(jìn)展和現(xiàn)代社會建設(shè)的重要支脈，隨著x8086、ARM等通用硬件架構(gòu)的進(jìn)一步完善，軟件工程甚至逐漸普及和加強(qiáng)為IT和通信的要緊內(nèi)容和核心驅(qū)動力。 然而，一直以來，軟件工程都缺乏一種有效公認(rèn)統(tǒng)一的治理方法，使得工程高利潤、可操縱的順利實現(xiàn)目標(biāo)。相反的，經(jīng)常見到小如APP，大到電網(wǎng)集散操縱系統(tǒng)，經(jīng)常不能完美達(dá)到用戶需求、預(yù)算超支、工程延期等問題甚至合同違約或項目失敗；與客戶理想的人機(jī)交互不同，更是屢見不鮮。有沒有一種治理方法能夠解決？瀑布模型、敏捷開發(fā)、演化模型、RUP和螺旋模型，輪番上陣，盡管都在各個領(lǐng)域取得一些效果和有一些最佳實

6、踐，卻始終沒有一種被證明絕對有效、被人們長期公認(rèn)科學(xué)的項目治理模型。由于曾負(fù)責(zé)建筑工程的專門經(jīng)歷，使我考慮能不能將建筑工程經(jīng)驗借鑒； 或者將建筑治理與軟件工程項目過程相統(tǒng)一。建筑項目是項目，軟件項目，也是項目，兩者絕不僅僅只名稱相同；有“一次性”目標(biāo)性等許多項目的共同特征。項目過程與標(biāo)準(zhǔn)化生產(chǎn)過程不同，他的一次性獨特性專門明顯。經(jīng)濟(jì)中除了生產(chǎn)、確實是項目；應(yīng)該有一個共同框架來統(tǒng)一項目過程。建筑項目，俯拾皆是；國家的建設(shè)如火如荼，那么多項目，總有營養(yǎng)汲取。況且中外建筑史有數(shù)千年，中國大型建筑項目也差不多有二千年歷史，有許多經(jīng)驗。實際上建筑業(yè)早已形成統(tǒng)一的規(guī)范的過程模式。一般的，建筑過程有規(guī)劃草圖

7、和勘探、設(shè)計、土建安裝、監(jiān)理驗收等多個環(huán)節(jié)，兩相類比，軟件項目缺少一個獨立、明顯的設(shè)計過程； 設(shè)計過程往往被前置到需求交流、或以“詳細(xì)設(shè)計”名義實際融入開發(fā)過程中了。由于缺少成型、明確的設(shè)計， 使得開發(fā)與用戶理解有潛在差異，成本預(yù)估不確切，開發(fā)變更修改反復(fù)進(jìn)行而工期延遲， 這確實是導(dǎo)致項目治理最終失控的要緊緣故。通過更詳細(xì)的分析與研究，和對整個項目過程的對比籌劃考慮，尤其是對項目成敗起決定作用的前期過程的不斷思辨，形成了統(tǒng)一的六段式項目治理方法。二、統(tǒng)一的六段式項目治理過程將軟件工程項目治理過程劃分為六個時期，并明確其特征和分隔點，在實踐中確定有效。六時期分不定義、特征、實踐注意點1、提案時期

8、。由提議人完成，通常是1-3人；這一時期要：確定進(jìn)行之目的，明確項目的初步范圍，確定“做什么”。完成時輸出xxx項目建議書，批準(zhǔn)結(jié)束。那個過程特不快，通常1天或幾天內(nèi)迅速完成，或不斷討論逐步形成定案；那個時期花費在總成本中不超過1%2%。在實踐中，由產(chǎn)品經(jīng)理提出，或有時直接由老總口述指定。由于現(xiàn)在期短促，經(jīng)常見到那個過程被省略，或不形成定議文案。但實際上，這是不對的，必須堅決反對。有些項目完全超出預(yù)算，實質(zhì)確實是變更巨大，甚或完全推翻，以致漫無目的地發(fā)散，自己搞不清最初的目標(biāo)了。這是一個必須經(jīng)由的時期，而且必須形成正式文檔，通過評議并保存。關(guān)于一個創(chuàng)新性項目，須要適當(dāng)詳細(xì)的建議書，以明確大致范

9、圍；關(guān)于產(chǎn)品化的項目，每個項目只是產(chǎn)品演進(jìn)進(jìn)展的一時期，建議書能夠簡明扼要，明確當(dāng)前版本要達(dá)到的要緊目的目標(biāo)即可。甚至能夠一頁紙 但這一時期不可或缺，尤其涉及變更時； 這也是關(guān)心治理者，厘清思路，明確優(yōu)先次序的過程。2、調(diào)研時期。由籌備小組完成， 這一時期要：確定項目整體是否可行，籌備所需人力、資財，組建核心團(tuán)隊，解決“能否做”。完成時要輸出可行性分析報告立項申請書，通過了評審，正式批準(zhǔn)是時期結(jié)束標(biāo)志，有時稱“立項時期”。那個時期花費在總成本中通常不到5%。實踐中一些軟件項目還沒有明顯的立項過程；然而，廠礦、建設(shè)項目可行性研究明顯，有人認(rèn)為軟件項目不涉及環(huán)評、土地、審批等不需可行性研究；事實上

10、是沒有理解，可行性研究的核心在于，理清實施的主體架構(gòu)、要緊步驟、核心內(nèi)容。主體架構(gòu)決定整個走向，要緊步驟是資源運籌大方向，兩者確定是否可行，他們確定以后才談到如何實施和可行性。建筑項目中，那個時期會畫出規(guī)劃草圖、進(jìn)行勘探以確定設(shè)計參數(shù)和可行性等。因此，設(shè)計并不是從設(shè)計時期開始、而是總體設(shè)計在提案、調(diào)研時期即開始，在設(shè)計時期細(xì)化和完善、完成。立項基于可行性分析，可行基于架構(gòu)和步驟?？尚行詧蟾妫ǔ０ㄕ呖尚行?、經(jīng)濟(jì)可行性、技術(shù)可行性、法律、環(huán)境、可持續(xù)性等部分。但重點是技術(shù)、經(jīng)濟(jì)可行性，對軟件項目而言尤其如此。軟件項目能夠省略不必要的可行分析部分，只重點描述技術(shù)實現(xiàn)方案、經(jīng)濟(jì)可行；一些產(chǎn)品化的

11、項目，甚至能夠?qū)⒖尚袌蟾婧喜⒃诹㈨棿_認(rèn)書中，甚至能夠不須計算經(jīng)濟(jì)可行性（完全產(chǎn)品化的軟件收入估算復(fù)雜），只需明確技術(shù)實現(xiàn)方案、和市場用戶（競爭對手優(yōu)勢）預(yù)估。立項申請書中，應(yīng)載明當(dāng)前版本的要緊任務(wù)、整體范圍界定、實施成本及人力預(yù)估、工期安排和估算，有些還需要附帶測試驗收標(biāo)準(zhǔn)。立項申請應(yīng)在批準(zhǔn)確認(rèn)后，以文本形式備檔，作為后期變更的基準(zhǔn)線和治理考核、項目考評的依據(jù)。需要強(qiáng)調(diào)講明，設(shè)計、測試、框架開發(fā)等專項工作，并非僅在其名義時期上進(jìn)行；實際上，他們是滲透在各個時期上進(jìn)行的。比如，設(shè)計在提案時期就差不多有大致范圍和初步架構(gòu)，在調(diào)研時期設(shè)計主體架構(gòu)，在設(shè)計時期完成詳細(xì)設(shè)計和明確；與一般理解不同，設(shè)計（

12、差不多評審和批準(zhǔn)）在實施時期仍在接著，包括尚未完成的一部分設(shè)計（一部分先通過評審的需求先實施）、對實施中發(fā)覺不清晰、不合適的進(jìn)行細(xì)化設(shè)計和補充設(shè)計、因變更引起的重新設(shè)計。再如，開發(fā)可能在提案前差不多有現(xiàn)成組件、中間件或構(gòu)件，在調(diào)研等時期預(yù)進(jìn)行一些核心和長周期的開發(fā)，設(shè)計時期甚至進(jìn)行一些部分已確認(rèn)的細(xì)節(jié)開發(fā)。再如更明顯更為大伙兒熟知：測試中的單元測試，實際是在開發(fā)時期完成的，而不是在驗收時期；驗收只是系統(tǒng)測試和性能測試。因此這與直接的表面理解不同，在RUP模型出現(xiàn)之后，業(yè)界普遍認(rèn)同了不同工作的進(jìn)行時刻是互相疊合的，因此，必須首先理解一項工作內(nèi)容，并非僅在其名義時期上進(jìn)行；劃分時期的名稱只是當(dāng)前時

13、期的要緊工作、核心工作，而不是全部工作或純粹工作。RUP的四個時期都分不含有不同比例的分析、架構(gòu)、設(shè)計、實施工作內(nèi)容，而不是在設(shè)計時期只做設(shè)計、實施時期只做開發(fā)，這些工作是不同子團(tuán)隊并行推進(jìn)的，而不是串行進(jìn)行由同一團(tuán)隊完成。下圖描繪了在RUP 中，不同工作在項目時刻軸推進(jìn)中不同時期的工作數(shù)量。圖1另外講明，那個時期的工作是由籌備小組完成，這在工程、廠礦中專門常見，軟件項目中較少見，實際上是籌備組是隱式存在的，只是未使用名稱，人員可能分散并行著多個項目。軟件項目中，通常能夠虛擬組成，人員能夠由不同部門職員虛擬組成團(tuán)隊，職員能夠同時存在多個項目的籌備組中，少量需要實設(shè)組織架構(gòu)。 籌備組并非是單一的

14、分析師和項目治理者組成，而是發(fā)起者、分析師、面向開發(fā)的架構(gòu)師、界面美工、幾個程序員甚至測試共同組成的混合團(tuán)隊；立項后，分不面向不同子工作團(tuán)隊，成為其不同層級的骨干。當(dāng)立項申請獲批，項目即得到了資源、財務(wù)的支持，人力投入認(rèn)可，籌備組即轉(zhuǎn)化為項目組，其成本自然進(jìn)入項目成本。非立項籌備成本是可施行性比率下合理的沉沒成本。有時這過程也稱“立項時期”，但調(diào)研更確切描述時期的本質(zhì)。3、設(shè)計時期。由分析設(shè)計人員完成，有時是規(guī)范的產(chǎn)品團(tuán)隊；這一時期要：確定項目完成最終實現(xiàn)的目標(biāo)，軟件成品的詳細(xì)描述，包括系統(tǒng)交互、狀態(tài)變化和處理邏輯、數(shù)據(jù)和部署等。即解決“做成什么樣”。完成時要輸出需求規(guī)格講明書，并通過三方評審

15、。那個時期時刻占到總過程30%，但成本僅占15%。當(dāng)前，在許多軟件項目實踐中，這一時期都不明顯，甚或消逝。這導(dǎo)致開發(fā)承擔(dān)者、與使用用戶（需求方）對成型后成果，有顯著理解差異；并最終導(dǎo)致開發(fā)人員對工程量無法確切評估（實際上，出于贏得好感，多數(shù)都傾向評估或給出較短的數(shù)字），和實施后又反復(fù)修改成品導(dǎo)致延期和超支。在建筑項目中，這時期是由專業(yè)的“建筑設(shè)計院”、專業(yè)建筑師和結(jié)構(gòu)師完成，并以出圖（藍(lán)色圖）為基礎(chǔ)，設(shè)計中都遵循嚴(yán)格的設(shè)計規(guī)范、支撐結(jié)構(gòu)原則、公認(rèn)范例等規(guī)則（因此也是受建筑安全國家法律限制）。與建筑一樣，設(shè)計時期將逐步獨立出來和更加規(guī)范。一些項目，由于甲方領(lǐng)導(dǎo)無經(jīng)驗，又重視細(xì)節(jié)，反而自然而然的要

16、求進(jìn)行了圖形界面設(shè)計或demo演示。在實踐中，有些項目有設(shè)計，然而仍然導(dǎo)致承建方無法實施、或項目完全失敗。是因為設(shè)計沒有建立在系統(tǒng)分析之上，設(shè)計沒有基礎(chǔ)。我們經(jīng)常講OOA/OOD（object oriented analysis/design），能夠發(fā)覺這兩個詞差不多上一起出現(xiàn)；分析是設(shè)計的前提，設(shè)計是分析的結(jié)果輸出；兩者異常緊密，之間完全映射而不是須要溝通，兩者合而為一才是最高效和合理的，分析者即是設(shè)計者。只有面向系統(tǒng)的分析-需求分析，才能導(dǎo)致可實現(xiàn)的、最佳成本和高體驗的設(shè)計。分析師需要一定的進(jìn)入門檻和如建筑設(shè)計師的專業(yè)素養(yǎng)，以確保設(shè)計是基于合理可靠的分析，面向系統(tǒng)實現(xiàn)和用戶的。需求規(guī)格講明

17、書（Software Requirements Specifications），有時也籠統(tǒng)的稱為需求描述，實際上需求規(guī)格講明書，有特不規(guī)范的寫法；其中，包括明細(xì)的用例，“一圖頂千言”的界面，對象的狀態(tài)變化等。以用例分析系統(tǒng)，以用例引領(lǐng)用戶活動，活動確認(rèn)交互，把界面作為UML9圖的補充；狀態(tài)和時序確定邏輯。與傳統(tǒng)不同，我們強(qiáng)調(diào)設(shè)計輸出是以“圖”為要緊表現(xiàn)方式，輔以文字講明，這更像建筑業(yè)的圖紙，實際上所有工程都應(yīng)該是以圖為指導(dǎo)的。圖的表達(dá)方式，更直觀、信息量更大、更容易清晰。要注意，在產(chǎn)品化大規(guī)模的項目中，SRS并不是一份文檔；而是幾個文檔組成的一個文檔組，由許多分析師協(xié)作完成，每人負(fù)責(zé)一定模塊或

18、模組，由一個總體講明文檔統(tǒng)領(lǐng)；對產(chǎn)品化的，總體文檔會講明下一版本開發(fā)任務(wù)的要緊內(nèi)容、組成文檔、基線版本。*注曾有個時期，業(yè)界認(rèn)為軟件模型應(yīng)該每個時期成果，逐步逐層映射到最終成品，因此設(shè)計應(yīng)該越詳細(xì)越好；至今仍有不明真相者如此想。現(xiàn)實中，也見到在設(shè)計時期即過分追究視覺細(xì)節(jié)、追求設(shè)計與開發(fā)的映射；甚至有嘗試將UML直接映射為代碼，而這些項目都失敗了。實際上設(shè)計時期的要緊目標(biāo)，是在最小成本下明確成品做成什么樣；這能夠消除需求方與開發(fā)者之間理解差異，開發(fā)者內(nèi)部之間理解差異（包括有子團(tuán)隊的大項目），清晰項目目標(biāo)成果，并在清晰全部成果后詳細(xì)估算成本，檢驗可實現(xiàn)性。因此，更詳細(xì)設(shè)計稿更好，但這一時期的成本需

19、要嚴(yán)格操縱在總成本的15%不超過20%，否則會擠占開發(fā)成本，就會出現(xiàn)設(shè)計得專門好，做出來卻差距專門大，而且白費時刻進(jìn)度。設(shè)計輸出要重新修正立項時確定的開發(fā)成本，使逼近20%內(nèi)，并在通過三方評審后確立。4、實施時期。要緊由實施、開發(fā)團(tuán)隊完成， 這一時期是要緊承擔(dān)項目實施、開發(fā)完成的時期；也是資金成本投入最密集的時期，通常占總成本60%-70%，有時也稱開發(fā)時期。在那個過程中，要解決“如何做”；在調(diào)研時期，我們解決“能否做”時，實際上差不多討論如何做的主體思路；但具體每個單元如何做并未涉及，現(xiàn)在期進(jìn)行中會解決。除輸出成品，為確保實施時期的，可控、可督促、治理的及時和有效，應(yīng)該輸出定期項目實施報告和

20、實施日志。實踐中，有專門多項目是外包單位實施完成；這時對需求規(guī)格講明書和兩個輸出文檔就顯得尤為重要。需求描述是開發(fā)的基礎(chǔ)，當(dāng)有良好的需求描述時就能夠?qū)⒄麄€開發(fā)實施時期外包，如建筑業(yè)做法一樣；而實施報告和實施日志則是實施過程中的保障，以確保進(jìn)度、質(zhì)量合乎項目的規(guī)劃，成本在可控預(yù)算內(nèi)。兩者區(qū)分在于報告是用于管控的，日志是用于清查的。盡管我們希望報告督促開發(fā)實施的勤懇，但并不是越多越好。實施組對治理層的開發(fā)報告，每周一次即可；開發(fā)日志能夠每天記，但不須詳細(xì)、也不須每人記，一個小組有一份日志即可，簡單數(shù)語扼要即好。如要確保人人進(jìn)度，可日例會輪流口頭匯報進(jìn)度。5、驗收時期。由測試、驗收團(tuán)隊完成，這一時期

21、要：確定項目是否達(dá)成目標(biāo)，是否達(dá)到預(yù)期可正常運作，和結(jié)束實施。完成時要輸出系統(tǒng)測試報告和驗收報告。那個時期花費在總成本中通常在10%內(nèi)，時刻占15%左右。理論上講，驗收報告 通常由所有方出具，或由獨立的第三方出具（以確保、公正），驗收應(yīng)該是全面的、詳細(xì)的檢測；系統(tǒng)測試和性能測試是由測試團(tuán)隊完成，獨立的過程。但實踐上，由于甲方的強(qiáng)勢、和減少重復(fù)勞動及成本分擔(dān)的考慮，通常會與系統(tǒng)測試合并，如此只需要一份系統(tǒng)測試報告，和一個簡明扼要驗收報告。當(dāng)如此做時，應(yīng)注意驗收測試并不是完全消逝了，驗收只做，核心功能和應(yīng)用活動流程的測試，而不需要重復(fù)ST中每一步驟、細(xì)節(jié)；這是兩個互相獨立的工作，ST的是測試團(tuán)隊，

22、驗收則可由產(chǎn)品團(tuán)隊代表所有方實施，不能因合并而完全依靠單一ST，保證制衡與復(fù)核。如此通常能夠有效操縱成本在10%。如此做緣故，同樣是基于軟件研發(fā)也是一項經(jīng)濟(jì)活動，我們不是為做而做，而是為了更好、更有效率的改造世界，美化人們的生活。有些公司專門重視測試，把測試作為一個重要的關(guān)卡和檢驗標(biāo)志，這是好事。然而要注意軟件的質(zhì)量是開發(fā)出來的，甚至是設(shè)計出來的，而不是測試出來的。那個地點講明，單元測試和中間集成測試是由開發(fā)為主和測試組共同完成，且在開發(fā)實施時期做；而系統(tǒng)測試報告和性能測試則由測試團(tuán)隊完成。一些無明確要求的項目，能夠減省或模糊地施行壓力測試和負(fù)載測試。6、維護(hù)時期。每一個項目，實際上都涉及到項

23、目結(jié)束后的持續(xù)維護(hù)問題。盡管維護(hù)過程或顯著、或微弱；實際上都存在。如MS windows xp一直在打必要補??；tencent微信軟件，一些小版本是維護(hù)更新；有些項目完成后雖幾乎不牽扯，但必要的嚴(yán)峻bug仍需修正。因此是必要的時期。事實上，建筑也一樣，驗收交付后，仍會存在漏水、裂縫空鼓等，進(jìn)行修補、后續(xù)維護(hù)是必要的、合理的步驟。維護(hù)時期的成本，通?？刹荒苡嬋腠椖砍杀绢A(yù)算；這是因為維護(hù)時長、難度都彈性專門大，無法預(yù)估或高值掩蓋開發(fā)成本。一旦驗收合格，理論上后續(xù)成本都應(yīng)另計為維護(hù)成本，因此許多項目會預(yù)留一年質(zhì)保期和質(zhì)保金，這部分可作為第一年維護(hù)成本。建筑項目的維護(hù)約在總開發(fā)成本5%，系統(tǒng)集成項目通

24、常包括一些軟件的改進(jìn)而不僅是安裝部署成本，屬于新需求開發(fā)，因此有可能10%/年。維護(hù)團(tuán)隊通常由原開發(fā)團(tuán)隊兼任，注意產(chǎn)品化項目存在上一版本維護(hù)，和新版本開發(fā)兩個相關(guān)任務(wù)，日常性運行維運則能夠組織專職團(tuán)隊。維護(hù)時期不包含在項目預(yù)算范圍，并不表示維護(hù)時期是可有可無的，或是獨立于項目外的；應(yīng)該必須認(rèn)識到維護(hù)是必定存在，和作為項目自然延伸和整體的組成部分，是項目本身價值體現(xiàn)。項目過程中，實施、驗收、維護(hù)時期的治理差不多在實踐中有較成型規(guī)范，而前期時期則相對混亂；尤其是，前期時期是決定項目成敗的關(guān)鍵。因此前三時期是重點，投入單人密度也較高。三、六段式項目治理與傳統(tǒng)方法的對比和優(yōu)勢 六段式項目治理方法，與傳

25、統(tǒng)的軟件開發(fā)模型和方法相比，有什么優(yōu)勢和改進(jìn)呢六段式項管與早期分段法、瀑布模型在上世紀(jì)90年代，軟件開發(fā)通常分為：需求分析、總體設(shè)計、詳細(xì)設(shè)計、編碼、測試和驗收等時期；確實是傳統(tǒng)的瀑布模型。如下圖（缺圖2）現(xiàn)存大多數(shù)模型，都從瀑布模型進(jìn)展演變而來，六段式也不例外；那么相比瀑布模型有什么優(yōu)勢呢？回答這問題，要從更早期的軟件開發(fā)講起。 在電子軟件渡過五六十年代的蒙昧期后，整個70年代多數(shù)軟件，差不多上為了軟件編譯、科研計算、數(shù)據(jù)處理和顯示而進(jìn)展的，顯然這些軟件的使用者幾乎確實是開發(fā)者，因此不存在需求方和開發(fā)方分離的狀況；一方面這些使用者差不多上有極客傾向的專業(yè)人士，對非圖形界面和苛刻交互差不多上高

26、手，沒有客戶體驗概念，他們深刻了解系統(tǒng)；另一方面，開發(fā)者直接了解應(yīng)用情景（use scenario），理解使用的目的。 那個時期的團(tuán)隊也較簡單，有時甚至是一個人獨立開發(fā)，一般團(tuán)隊可能5-8人，少則2-3人，最大的團(tuán)隊也只是十幾人。軟件特不重視性能和資源耗用， 團(tuán)隊成員差不多上從獨立地開發(fā)軟件成長起來的，能獨立負(fù)擔(dān)軟件過程中任何時期； 由于人少，也能夠集體參觀使用環(huán)境，了解用戶需求。因此，從設(shè)計到編碼差不多上同一組人在做，不存在專業(yè)分工。這情況一直持續(xù)到80年代早期。而現(xiàn)在的軟件業(yè)界，發(fā)生了質(zhì)的變化。首先，硬件快速進(jìn)展，性能和資源占用不再是第一位的，軟件的體驗和可用性，代替性能和可處理性成為重點

27、，編譯器進(jìn)步、Python語言等的進(jìn)展，對編碼的質(zhì)量要求有所降低。 其次，軟件從面向信息業(yè)界和極客，迅速擴(kuò)展到各行各業(yè)，面向幾乎全社會用戶；而行業(yè)也深入到開發(fā)者完全不熟悉不理解、甚至不清晰具體使用的領(lǐng)域，及有些日常難得一見的特不專業(yè)的領(lǐng)域，開發(fā)者無法再自然地理解需求； 80年代以來GUI取代舊界面，系統(tǒng)的作用更傾向業(yè)務(wù)應(yīng)用、引導(dǎo)、交互而不是單純地處理運算，可用性和用戶體驗提高到前所未有的高度。 同時，這種情況下的行業(yè)跨越進(jìn)展，大量新手涌入，短時刻內(nèi)他們來不及從始至終了解每一個開發(fā)環(huán)節(jié)、了解用戶使用情景和真實需求，多數(shù)都為某一專業(yè)具體工作而培養(yǎng)，而不再是初期基礎(chǔ)牢固的全面型人才；工作分工職業(yè)也越

28、來越細(xì)越專業(yè)化。在早期的團(tuán)隊中，成員統(tǒng)稱系統(tǒng)工程師，并無系統(tǒng)分析師、系統(tǒng)架構(gòu)師、測試專家之分，現(xiàn)在則不同。 數(shù)十、數(shù)百人的項目團(tuán)隊，須要更有組織化；調(diào)研需求再也不能集體到現(xiàn)場，高效化的結(jié)果是，委派幾位需求分析師調(diào)研用戶需求；溝通傳遞需求的方式再不是反復(fù)開會討論，而是高效的專業(yè)分析，和形成文檔由開發(fā)者隨時查閱。如此一來項目團(tuán)隊變得分工更專業(yè)，更加有機(jī)層次。軟件早期和瀑布模型時代，由于開發(fā)團(tuán)隊強(qiáng)大的可適應(yīng)性，和集體同步工作，軟件能夠從需求、轉(zhuǎn)變?yōu)橄到y(tǒng)設(shè)計、逐級替代為代碼，形成順序的流程，如同一個直流而下的瀑布。而現(xiàn)在，需要人員專職于自己的分工，多個子工作并行的推進(jìn)，互相協(xié)作完成。因此，六段式項目治

29、理方法更加適應(yīng)大規(guī)模、高效率的現(xiàn)代項目開發(fā)。六段式項管與產(chǎn)品迭代模型軟件產(chǎn)品進(jìn)展到現(xiàn)在，涌現(xiàn)許多模型，其中迭代模型是最成功的模型之一。因為迭代模型符合了自由軟件的思想，讓軟件充分地復(fù)用，和更優(yōu)化、更具體驗、更先進(jìn)。在馮諾依曼程序存儲思想下，硬件通用后軟件具有幾乎無成本復(fù)制生產(chǎn)的優(yōu)勢。 當(dāng)人們通過一個項目開發(fā)了一款好軟件后，希望充分復(fù)用之， 而不是不同用戶重新成立項目組進(jìn)行重復(fù)的開發(fā)；同時，人們還希望軟件在原有的基礎(chǔ)上，不斷的改進(jìn)、更新，使具備更多功能、可用性和更優(yōu)秀的體驗。這大幅地節(jié)約整個社會的成本、提高軟件質(zhì)量和可用性。這時，許多軟件開始產(chǎn)品化，比如MS office， Photoshop，

30、Donald的TeX、一些ERP系統(tǒng)等。軟件公司對一個軟件在前次版本基礎(chǔ)上，做新的需求規(guī)劃、立項、系統(tǒng)分析設(shè)計、開發(fā)、測試；產(chǎn)品上市后又開始新一輪需求規(guī)劃，周而復(fù)始。迭代模型就在這種背景下得到認(rèn)可。軟件的產(chǎn)品化，極大的推動軟件業(yè)進(jìn)步和社會的進(jìn)展。但應(yīng)該了解，每一個軟件版本，是通過了立項進(jìn)行開發(fā)的，是一個獨立的軟件項目，而不能將軟件不斷進(jìn)展演進(jìn)過程，視為一個大項目。只有把這大“項目”拆解成一個一個小獨立過程，我們才能對其中時期進(jìn)行標(biāo)準(zhǔn)化、把項目治理演變成一個科學(xué)、標(biāo)準(zhǔn)、可控的方法；否則，復(fù)雜龐大的大項目沒有純粹共同點，我們無法提煉其中的規(guī)律，項目治理就變成一個人治的、主觀的、失控的過程。這也是分

31、析、分解的差不多思想。當(dāng)我們視為一個個獨立版本的項目過程后，就發(fā)覺周而復(fù)始的螺旋上升，確實是一個一個軟件需求項目的首尾相接，不斷上升進(jìn)展的過程。談到軟件的持續(xù)開發(fā)和多個項目交替，可能就會想到，由于項目團(tuán)隊成員的分工專業(yè)化，盡管不同子工作之間有并行推進(jìn)、和時刻重疊；但在不同時期仍然造成大量人力閑置和白費。如在實施時期，要緊是開發(fā)人員在工作，測試和分析設(shè)計人員是較空閑的。 如此會導(dǎo)致整個社會成本的增高，即使通過報價彌補了這部分成本，也仍造成人力的白費。 因此，實踐上，成熟的軟件團(tuán)隊，一般差不多上同時負(fù)擔(dān)2個項目或軟件版本，或3-4個項目。比如甲團(tuán)隊，正在編碼開發(fā)某軟件3.11版本，同時在調(diào)研、設(shè)計

32、軟件的3.20版本；再如乙團(tuán)隊，正在設(shè)計的是水電DCS系統(tǒng)，同時進(jìn)行著某企業(yè)erp系統(tǒng)的測試和bug修改。因此，一個產(chǎn)品化軟件的生命周期過程，是由一個個獨立開發(fā)項目組成，如此才具有一次性、目標(biāo)性等項目的典型特征；才是標(biāo)準(zhǔn)化、可科學(xué)治理和提高效率成功率的項目。產(chǎn)品化的軟件，每一個新特性版本都應(yīng)該立項，以確定市場目標(biāo)和投入，按標(biāo)準(zhǔn)項目過程操作，提高資金使用效率、人力使用效率。對每一個版本項目，應(yīng)該進(jìn)行投入效益的考核，和總結(jié)反思，效益不僅是收入、利潤的經(jīng)濟(jì)指標(biāo)，也要包括：活躍用戶數(shù)、用戶體驗、競爭對手差距等。產(chǎn)品化，才是軟件行業(yè)的主流，由于軟件復(fù)制幾乎無成本，一個好的軟件在跟一般質(zhì)量的軟件市場競爭中

33、，價格、產(chǎn)品都處于絕對優(yōu)勢，更況且差的軟件。專門多軟件如OS、通用APP都會形成幾家獨大，一般研發(fā)項目幾乎無法生存，產(chǎn)品化才是軟件業(yè)以后。另外還要講明，軟件開發(fā)是一個項目，軟件的安裝部署也是一個獨立的項目；而不能將兩者混淆。軟件部署也同樣有調(diào)研、設(shè)計、實施、驗收的過程；只是部署項目通常專門小，過程被微縮了。比如，某erp產(chǎn)品部署項目，部署目標(biāo)專門明確，因此提案即是某軟件的安裝部署；調(diào)研是試安裝、調(diào)試的過程；通過嘗試確定了在online環(huán)境中正式安裝的步驟、次序、人員分工/機(jī)器分布、失敗預(yù)案，確實是對安裝過程的設(shè)計；正式安裝確實是實施；完成后應(yīng)該進(jìn)行測試檢驗，作為驗收；后續(xù)發(fā)覺遺漏還需維護(hù)。順便

34、講明一點，部署也是項目，建筑也是項目，因此我們把要緊核心過程的名稱定為“實施”而不是“開發(fā)”。但關(guān)于大型的設(shè)備的部署安裝項目，如大型水電機(jī)組安裝，則有專門明顯的六個時期過程。安裝項目，與機(jī)組制造、系統(tǒng)開發(fā)，是兩個獨立的項目過程。六段式項管與RUP細(xì)心讀者可能發(fā)覺，六段式治理，與RUP具有特不多的相似之處，那么什么緣故還要再進(jìn)展六段式治理，與RUP相比有什么優(yōu)勢和區(qū)不。六段式項目治理方法的發(fā)覺專門早且是獨立的，并沒有參考RUP的過程。首先講，RUP是眾多工程師的實踐結(jié)晶和經(jīng)驗總結(jié)，并由Rational（IBM收購）最先公布推廣，是各模式的進(jìn)展和軟件開發(fā)經(jīng)驗的集成；兩者相似只是“智謀之士，所見略同

35、”的必定。RUP明確認(rèn)識了各個時期中不同種工作并存，領(lǐng)先將概設(shè)詳設(shè)等從開發(fā)實施中獨立出來建立了對應(yīng)“設(shè)計”的細(xì)化過程，建立了循環(huán)的四段過程對軟件不朽貢獻(xiàn)，對行業(yè)產(chǎn)生重大阻礙；六段式方法在進(jìn)展過程中也參考學(xué)習(xí)了RUP過程；從那個意義上講，六段式方法是對RUP的進(jìn)展和演進(jìn)。那么，六段式治理與RUP 有哪些不同：1、六段式治理重新整理了初始時期的過程，依照不同本質(zhì)，對項目成本至關(guān)重要的前期時期，進(jìn)行了更細(xì)化、規(guī)范化的整理。RUP 有四個過程，Inception（初始）、Elaboration （細(xì)化）、Construction（實施）、Transition（交付）時期；其中Construction時

36、期確實是六段式的【實施時期】，有時稱【構(gòu)建時期】，Transition時期對應(yīng)于【驗收時期】，細(xì)化大致相當(dāng)于【設(shè)計時期】。關(guān)于初始的Inception時期RUP描述特不模糊，我們把提案獨立出來，以最快明確項目的要緊目的和大致范圍，并要形成文檔，幸免漫無目的地發(fā)散，或本質(zhì)性變動導(dǎo)致的成本、時刻失控。關(guān)于初始時期的其他部分，我們把它明確為可行性研究，而作可行性研究先要有要做的框架、要緊步驟、范圍；確實是講整體架構(gòu)、設(shè)計那個時期就已在進(jìn)行了，講明和解讀了這時期要做的目的。最后作為可行性的輸出，要完成立項申請報告，獲得項目進(jìn)行所必需的人力和資金。（圖3 RUP）2、六段式過程提出了每時期的時刻操縱和成

37、本標(biāo)準(zhǔn)，輸出等目標(biāo)特征。盡管六段式與RUP的要緊時期都大致對應(yīng)，但RUP并沒有提出每時期的時刻、成本占用比例；導(dǎo)致一些項目雖按RUP進(jìn)行，但各時期嚴(yán)峻不成比例，如僅對部分架構(gòu)和界面美觀研究時刻太長，卻忽略甚至躍過了細(xì)化時期； 設(shè)計時刻過長和反復(fù)糾結(jié)太多，沒有給實施時期留下足夠時刻和成本。對每個時期的成本操縱，絕不是小事；而是一個必須進(jìn)行操縱的事。整體上這是一個循序漸進(jìn)，逐步擴(kuò)大的投入過程，1%，5%，15%，65%，這一過程實際上降低了項目過程中的風(fēng)險。這是六段式項目治理最重要的一點。 各時期的成本操縱也是用于衡量設(shè)計與開發(fā)間成本配比和工作效率的依據(jù)之一，就軟件而言優(yōu)秀的過程設(shè)計與實際實施開發(fā)

38、，單位時刻投入大約在1:3到1:4，而實施時長通常比設(shè)計多50%左右。3、六段式過程清晰化各時期規(guī)范，尤其是設(shè)計時期的工作方式和輸出標(biāo)準(zhǔn)。在RUP中，Inception和Elaboration的里程碑描述不專門清晰，事實上它確實是立項確認(rèn)書。而設(shè)計時期是整個項目成敗的關(guān)鍵，RUP并未明確其過程。六段式明確了這一時期要緊目的，確實是完成項目的應(yīng)用設(shè)計。而設(shè)計，絕不是肆意畫圖、想象、任性設(shè)定，想如何設(shè)計就如何設(shè)計；設(shè)計必須以分析為基礎(chǔ)，實際完成設(shè)計的人員不叫設(shè)計師，而是系統(tǒng)分析師；需求分析并非對需求的簡單想想、分析分析，需求分析是專業(yè)人員作的，必須是基于系統(tǒng)面向系統(tǒng)開發(fā)的。需求分析人員不但要有專門

39、強(qiáng)理性思維能力、把自己代入用戶情境（use scenario）的能力，而且要有全面、堅實、深刻的IT和CT系統(tǒng)知識，對系統(tǒng)梳理、分析的能力 ；最后要掌握表述規(guī)范用標(biāo)準(zhǔn)的圖、文表達(dá)出來。實際上，六段式治理，借用改良UML，確立了規(guī)范的需求規(guī)格講明書寫法和圖形語言，因為圖的表達(dá)能力更強(qiáng)。因此，它重新定義了設(shè)計時期的工作細(xì)節(jié)，和輸出設(shè)計稿的標(biāo)準(zhǔn)。同時，更規(guī)范化了一些標(biāo)準(zhǔn)，如維護(hù)是測試驗收后，盡管有時投入幾乎為0，然而考慮整體性，不宜將之抹除。 在六段式治理中，各時期“輸出”也更加明確；能夠講六段式是RUP進(jìn)一步規(guī)范。4、六段式過程的時期性，真正有效規(guī)避了風(fēng)險，提高了項目成功性和對需求的滿足。 我們提

40、出軟件項目過程模型的目的，是為提高項目成功率和更確切滿足需求。然而，項目失敗率（或與需求偏差）顯著偏高，如對比生產(chǎn)，如何才能操縱項目過程中的風(fēng)險，提高成功率或盡早發(fā)覺風(fēng)險減少損失？我們明白項目是個一次性的有目的的過程，由于它的一次性沒有可借鑒經(jīng)驗，如何樣提高成功的可靠性，只有逐步投入、漸次逼近目標(biāo)，發(fā)覺風(fēng)險后及時彌補和中止，才是真正降低風(fēng)險，保證項目成功的依靠。這是通用的唯一的方法。六段式項目過程，是逐步擴(kuò)大投入的過程，如同喇叭口，這種擴(kuò)大并不是線性擴(kuò)大，而是指數(shù)級增長（如4的x-1次冪）。在擴(kuò)大的每個時期，都會進(jìn)行review評審，當(dāng)發(fā)覺風(fēng)險時就能夠及時操縱、改進(jìn)；必要時中止項目以防止損失擴(kuò)

41、大。要明白，項目實施人員基于工作量酬勞的緣故，即使發(fā)覺風(fēng)險也有接著完成項目的沖動。提案評審批準(zhǔn)、立項評審批準(zhǔn)、規(guī)格三方評審，每個要緊環(huán)節(jié)都進(jìn)行了嚴(yán)格的風(fēng)險操縱，團(tuán)隊外的評估。 軟件過程，或建筑項目過程，本質(zhì)上差不多上“社會生產(chǎn)”過程，是為了讓人們生活得更好，工作更有效率，解放人力用于享受幸福，差不多上一種經(jīng)濟(jì)活動。經(jīng)濟(jì)活動就要符合經(jīng)濟(jì)活動的規(guī)律，最大化追求利潤，或成本一定的情景下最大化滿足需求；而不是追求過程看起來有對稱、整齊或理論深奧。保障項目的成功率，用最少投入完成項目目標(biāo)，防范風(fēng)險、降低重復(fù)確實是節(jié)約成本，轉(zhuǎn)化和增加了利潤；在項目開發(fā)總成本未增加的情況下，做出的成品更加貼近用戶需求或用戶

42、理想狀態(tài)、提高使用效率何樂而不為？ 六段式方法，用最簡單最直接的方式，清晰的操縱風(fēng)險，幸免了繁雜評審過程中反復(fù)和白費，本質(zhì)上是對項目經(jīng)濟(jì)性的詮釋。四、六段式項目治理與常見問題辨析六段式項管與需求變更1、如何樣操縱變更進(jìn)而操縱項目有人問我需求變更如何樣操縱？他們使用了CCB（Change control board）、變更操縱流程等種種治理措施，仍不能有效的操縱變更的數(shù)量，需求時在變、編碼中變、編碼后還在變。首先，需求變更是一種客觀存在，沒有人是諸葛亮，能夠準(zhǔn)確預(yù)測所有可能出現(xiàn)的情況、實施過程中的問題。因此，沒有變更的項目是不正常的；重要的是如何對待變更。假如需求不斷變化，那講明提案時還沒搞清要

43、干什么，就匆忙施行；或者沒有充分確定可行性和優(yōu)先次序，過后才發(fā)覺架構(gòu)要改；或者沒有一個確定的設(shè)計，結(jié)果邊干邊設(shè)計，一面涂抹一面實施。 總之確實是沒有確定方法 或方法沒有通過系統(tǒng)地分析，沒有項目的過程治理、成品的設(shè)計（治理學(xué)術(shù)語，沒有制定打算）；解決方法也專門簡單，確實是嚴(yán)格按照六段式項目過程進(jìn)行即可。 然而打算沒有變化快，總是有細(xì)節(jié)不在打算內(nèi)，這專門正常；在編碼中，或編碼完成后出現(xiàn)變更也是合理的。這在建筑工程中也專門常見，舉一個親身經(jīng)歷例子，2004年為某單位建設(shè)居民樓，設(shè)計院的圖紙都通過評審、答疑、交底，無異議后才實施；數(shù)月后施工單位向我匯報要求變更一個下水PVC管位置，側(cè)移10cm，緣故是

44、管子會遮擋一些衛(wèi)生間窗口的視線，且造成用戶開關(guān)窗口略不便；基于為居民著想這變更專門合理，而且在圖紙上審議時專門難預(yù)想到觀窗視線的細(xì)節(jié)，經(jīng)與設(shè)計院協(xié)商，其修訂了圖紙（未全部重曬）。像這種成本專門少、基于用戶需求的都能夠變更。然而一定要操縱變更的度。 確實是在實施時期，進(jìn)行變更，包括設(shè)計更改，也包括工期調(diào)整、預(yù)算追加，不能超過評審?fù)ㄟ^的需求規(guī)格的15%。假如超出、或發(fā)覺今后會超出，必須立即報告決策層，預(yù)算和工期都一樣，并重新修訂預(yù)案。 要特不強(qiáng)調(diào)的一點，對設(shè)計變更，必須要通知設(shè)計團(tuán)隊并征得其同意（代表產(chǎn)品、需求方）不論其節(jié)約預(yù)算或超支；編碼變更和設(shè)計變更能夠同步同時進(jìn)行，但設(shè)計團(tuán)隊要對變更留底。有

45、人講，他們刻意遵照RUP過程，然而公司治理層強(qiáng)勢改變、尤其增加了專門多需求，仍然導(dǎo)致變更超出了預(yù)算，或?qū)崿F(xiàn)需求不理想；時刻也有延期。在六段式治理或RUP中， 假如一個變更是本時期內(nèi)的，（變更的原方案是本時期內(nèi)才提出來的，只阻礙時期內(nèi)），能夠直接變更，不需要申請、審批流程。 假如變更的是上一時期的輸出（如通過評審的需求規(guī)格、立項書），則必須要返回上一時期進(jìn)行修改，并重新評審批準(zhǔn)。 而不是直接在本時期變更， 盡管那樣看起來更簡潔，然而卻蘊藏了巨大風(fēng)險和不可持續(xù)性；為今后軟件改進(jìn)和以后著想，必須回上一時期。如：實施時發(fā)覺要增加一個專門大項需求；這時要返回立項時期（甚至提案）重新確定立項，書面明確更改

46、后的預(yù)算、和工期，然后作這部分的設(shè)計；或者能夠如此想，實施時的問題，返回設(shè)計，設(shè)計能解決則解決，若發(fā)覺還不符合上一時期輸出，那還要接著返回調(diào)研時期。由于六段式治理每時期都有評審，實際上如此也能夠幸免，不明白技術(shù)的領(lǐng)導(dǎo)亂拍板，一些糊涂領(lǐng)導(dǎo)不認(rèn)賬。 變更的結(jié)果必須在時期輸出文檔中保留；變更緣故和原設(shè)計盡量保留。 如此能夠不用嚴(yán)格按照申-評-決-施-驗-存六步變更操縱流程處處存檔，幸免許多人最反感的文檔化和繁文縟節(jié)，簡化流程提高效率。2、三方評審、質(zhì)控減少變更關(guān)于評審。每個時期結(jié)束時，都要進(jìn)行評審（評價及審批），實際上是時期性質(zhì)量操縱，通過評審將時期性操縱后期變更的風(fēng)險。變更越早發(fā)覺、越早進(jìn)行，成本

47、越低。提案和調(diào)研的評審，都由決策層（或需求投資方）直接進(jìn)行，決策者簽字確認(rèn)或集體決策的通過討論匯簽確認(rèn)。提案書被確認(rèn)后確實是籌備組工作的依據(jù)批文，立項申請書，被確認(rèn)后確實是立項確認(rèn)書。這如同審建筑圖紙，決策層重點審戶型、框架、滿足需求，而不是專業(yè)的細(xì)節(jié)。不同的是設(shè)計時期，設(shè)計時期的評審，叫做“三方評審”，前面評審能夠是一個時刻點，而三方評審可能是需求規(guī)格講明書一套文檔，內(nèi)容多且專業(yè)，不是一次會議可完成的。往往分多次陸續(xù)評審，評審?fù)ㄟ^的先進(jìn)入開發(fā)，假如一定要找時刻點，那么以首次80%需求規(guī)格通過評審為準(zhǔn)。所謂“三方”，是指用戶方代表、開發(fā)方代表、獨立第三方專家。產(chǎn)品化的軟件，無法找到全面用戶代表

48、，可由產(chǎn)品團(tuán)隊和專業(yè)需求分析人員組成代表組，但不能僅僅是設(shè)計者本人。開發(fā)方代表，可由開發(fā)經(jīng)理和系統(tǒng)架構(gòu)師組成，具有否決權(quán)，重點審核設(shè)計能否實現(xiàn)，成本如何。多數(shù)項目聘請第三方專家專門難，可由具備開闊民眾平常心和知識遠(yuǎn)見的公司領(lǐng)導(dǎo)來代表。評審須要三方通過，不通過的需闡明理由和需改進(jìn)點。為了評審效率，通常產(chǎn)品、系統(tǒng)分析師會與研發(fā)、系統(tǒng)架構(gòu)師預(yù)先會面口頭溝通。因設(shè)計是從用戶中來，因此評審傾向于通過，需改進(jìn)不超15%的，可直接改進(jìn)后進(jìn)入下一時期，不重評審。實施時期的評審，是個大規(guī)模評審，實際確實是驗收。驗收的評審確實是驗收報告評審會。 我們劃分各時期的標(biāo)志確實是評審點；能夠想象這是一個時刻軸直線，五次評

49、審確實是5個刻度分隔點，把直線分成了六個區(qū)段。3、變更和測試的誤區(qū)變更也會出現(xiàn)在測試中。測試中，也經(jīng)常會提出些改進(jìn)，要求變更需求和軟件設(shè)計。首先，我們要分清bug和需求變更。原則上，bug是需求和設(shè)計中有要求（或隱含），而開發(fā)未達(dá)到的；需求變更是原需求文檔和設(shè)計中沒有的。只是，有些時候仍專門難分請bug和需求變更。不論bug或需求，只要合理合適的，都應(yīng)該更改；但假如涉及需求，同樣的，要返回設(shè)計時期，由分析設(shè)計團(tuán)隊分析討論確定了新設(shè)計，再開發(fā)改進(jìn)。如此做的理由同樣是軟件專業(yè)人員不是用戶，不能保證確切的理解用戶需求；沒有通過全面分析、規(guī)劃軟件長期演進(jìn)，可能會在今后反復(fù)改回；分析人員調(diào)研需求代表用戶

50、。 要強(qiáng)調(diào)的是，測試的依據(jù)是需求規(guī)格講明書，而不是理解中用戶正確需求，即使測試的意見是正確的，原設(shè)計不合理，也不能直接作為bug直接提交開發(fā)，這涉及到開發(fā)團(tuán)隊，對一個定稿設(shè)計的開發(fā)效率和工作考核。需求描述也會引起變更。常見的情況是需求規(guī)格講明書描述得不細(xì)、或有歧義（對不專業(yè)的分析設(shè)計團(tuán)隊尤其是），這會增加bug的量和變更。有些是分析設(shè)計人員沒有掌握規(guī)范的規(guī)格講明書的寫法；也有些是正常的溝通和表達(dá)理解適應(yīng)問題。 因此，好的產(chǎn)品團(tuán)隊和開發(fā)團(tuán)隊要通過磨合一段時期，才能達(dá)到配合默契、理解相通，開發(fā)才對設(shè)計理解更清晰、準(zhǔn)確，整個團(tuán)隊的效率才更高。但再次強(qiáng)調(diào)需求規(guī)格講明書（SRS）絕不是越細(xì)越好，文檔比代

51、碼還多；也不是用幾句描述性的語言講明使用目的確實是需求（前者極限靠近凈室模型，后者是多數(shù)非專業(yè)人員常犯的錯誤）； 而應(yīng)該追求最少的文檔，準(zhǔn)確表達(dá)設(shè)計成品和使用意圖。 那個地點開發(fā)人員要注意一點是，遇有描述不細(xì)、或有理解歧義的，開發(fā)人員要主動提出來，要求分析設(shè)計人員“交底”、“澄清”，而不是按照自己的理解自行開發(fā)或被動等待，之后導(dǎo)致變更或bug。因為分析人員要預(yù)估開發(fā)人員的理解的歧義難得多。 通常在實施時期，要提供途徑給開發(fā)和設(shè)計之間，快速、口頭、準(zhǔn)確地溝通，設(shè)計要及時響應(yīng)開發(fā)詢問，使便捷詢問。一般而言，分析設(shè)計人員的固定薪酬部分是低于技術(shù)開發(fā)、系統(tǒng)架構(gòu)人員的固定薪酬的，一是因為開發(fā)人員，尤其系

52、統(tǒng)架構(gòu)師要緊依靠技術(shù)門檻、計時和工作量來計算績效，那個部分特不穩(wěn)定；二是因為分析設(shè)計人員還有市場效益變化的績效薪酬。由于對分析設(shè)計的評價經(jīng)常專門難進(jìn)行，存在公講公有理婆講婆有理，而且分析設(shè)計團(tuán)隊是要對市場和用戶負(fù)責(zé)的，因此以用戶和市場變化作為優(yōu)劣客觀評判是最好的激勵。 對用戶需求的分析，沒有最好、只有更好，通常都沒有一次設(shè)計最完美不再改進(jìn)的軟件；有時細(xì)節(jié)用例的遺漏也屬正常，但核心用例的遺漏和核心流程缺失，確實是分析設(shè)計師的責(zé)任。同時，分析設(shè)計人員也有責(zé)任確保一次性提交通過深入分析的設(shè)計，以節(jié)約開發(fā)工作量，假如實施時經(jīng)常返回前時期大規(guī)模地變更，重新評估可行、重設(shè)計，那就要考慮項目分析團(tuán)隊、系統(tǒng)分

53、析師，是否沒有足夠能力擔(dān)當(dāng)、沒有足夠資格及資質(zhì)。測試用例文檔不是越細(xì)越好（這與需求規(guī)格類似）、也不是每個項目都必需的。我們預(yù)備測試用例（指測試用案例，注意這與系統(tǒng)分析中的用例，完全不是同一概念），是為了更好理清測試思路、完善測試細(xì)節(jié)。由于80%時刻都不在系統(tǒng)測試期間，測試人員相對的時期性忙閑較明顯，那么實施時期除了協(xié)助開發(fā)人員進(jìn)行單元測試，專門大程度都被安排來寫測試用例。因為測試時刻緊，提早做預(yù)備，要做哪些方面的測試不要遺漏，合并用例一跑多測來提高效率，完美覆蓋的系統(tǒng)邊界值，提早編寫測試用例能夠?qū)ｉT好地提高測試效率；然而，測試的優(yōu)劣和工作評價決不是測試用例寫得好壞。測試只能以測試的結(jié)果是否有效

54、過濾了需求規(guī)格所要求的，是否真正適合用戶應(yīng)用為唯一的終極目標(biāo)。在滿足以上要求情況下，應(yīng)該最大化節(jié)約人力、減輕文檔、加速時刻；從那個角度上講，有些敏捷項目直接測試，不寫測試用例，也是能夠的。測試應(yīng)該有一個測試規(guī)劃做統(tǒng)領(lǐng)，但并不是事事處處要有文檔， 測試方面建筑項目的驗收，是專門好的榜樣。測試應(yīng)該回歸到操縱工程質(zhì)量、滿足用戶需求為目標(biāo)的簡易模式，以開發(fā)實施為核心，輕測試、輕文檔地完成有用的成品，才是項目治理的真諦。六段式項管與敏捷開發(fā)近年來，敏捷開發(fā)爆發(fā)性的進(jìn)展，有人認(rèn)為不再需要瀑布模型，不再需要文檔操縱，能夠自由的、快捷的開發(fā)軟件；敏捷是所有軟件開發(fā)的唯一以后。敏捷方法春筍般出現(xiàn)，極限編程XP

55、Extreme Programming、自適應(yīng)軟件開發(fā)、水晶方法Crystal、特性驅(qū)動開發(fā)Feature Driven Development、精益軟件開發(fā)Lean Software Development、Scrum、AUP。 甚至在一些人口中，看起來一時刻敏捷能夠包打天下，不做敏捷就落伍了、確實是低效的、就不夠先進(jìn)，假如還提CMMI 確實是守舊頑固的代表。然而，要明白到目前為止，還沒有任何一個大規(guī)模開發(fā)項目或優(yōu)質(zhì)產(chǎn)品，是完全依靠敏捷開發(fā)的。不論是windows、依舊oracle DB。敏捷確實進(jìn)展專門快，滿足了許多項目過程需要，也出現(xiàn)了一些最佳實踐。我特不認(rèn)同敏捷開發(fā)的四原則，人員素養(yǎng)和

56、口頭溝通比鋪陳些文檔和用過程來保障重要，一個實際工作的軟件不管如何都比遵循形式化的流程重要（互文）；靈活隨機(jī)應(yīng)變地處理變化比因循打算重要；作為一種結(jié)果或狀態(tài)，也專門認(rèn)同客戶合作勝過合同談判。但敏捷決不是能夠解決一切問題的最佳方法。首先，敏捷特不適合小型的項目，當(dāng)緊湊團(tuán)隊的成員超過了30人，而且團(tuán)隊成員有增減變化，全風(fēng)光對面溝通全然無法進(jìn)行，就不如文檔溝通突破了時刻、空間的限制。文檔應(yīng)該恰如其分，反應(yīng)將要完成的成品，而不是越細(xì)越好；讓成員隨時查閱，而不需要集中時刻會議傳達(dá)。 現(xiàn)代軟件項目經(jīng)常失敗或不理想，要緊緣故是并不真正了解用戶需求， 未能專業(yè)的分析需求并闡釋用戶理想中的成品狀態(tài)或者講確實是缺

57、少一個最終“做成什么樣”的設(shè)計。 敏捷如何解決這一問題呢？ 他通過客戶參與，直接讓客戶確認(rèn)是否符合需求，是否有理想的交互； 頻繁提交新版本給客戶（通常2周或不超2月），通過不斷試錯的方式，彌補對需求缺乏分析和深刻認(rèn)識的不足，并通過盡早提交，把錯誤消滅在萌芽狀態(tài)。 為快速適應(yīng)需求不確定的變化，他要求團(tuán)隊Responding to change，這就要求團(tuán)隊小而精悍、靈活調(diào)轉(zhuǎn)，并快速的面對面溝通及時傳遞變化信息而不是等待沉淀成文。另外敏捷還通過每天的面會匯報，督促了成員進(jìn)度。是否感受專門眼熟？ 前面談到過，在軟件開發(fā)早期，團(tuán)隊特不小、成員都深刻了解用戶需求（并互相討論），也能夠集體參觀使用環(huán)境而了

58、解使用情境；并不預(yù)設(shè)繁雜的文檔。這不確實是現(xiàn)在敏捷嗎？ 成員都能獨立承擔(dān)軟件架構(gòu)、分析設(shè)計、編碼各環(huán)節(jié)，因此能夠集體撲入項目同一時期，彼此信任和默契配合，而敏捷中通過小單元提交、結(jié)對編程、老帶新等也近似解決了那個問題（因此敏捷專門強(qiáng)調(diào)個體素養(yǎng)）。敏捷通過不斷把項目簡單化、易理解化，把項目變成一個可由小型緊密專業(yè)的團(tuán)隊承擔(dān)的工程，并通過原始自然的最直接、明確目標(biāo)的方法推進(jìn)，因此高效、有用，易掌握。從那個意義上，敏捷不是項目方法的進(jìn)展、而是回歸真樸。 然而敏捷仍然不是完美的方法， 除了上述敏捷開發(fā)無法適應(yīng)大規(guī)模團(tuán)隊項目，是問題之一，敏捷還有兩個重要缺陷。敏捷方法會因客戶不專業(yè)、不斷變更而白費開發(fā)人

59、力。 關(guān)于簡單直觀的項目，敏捷專門湊效；但關(guān)于一些無法直觀面對的項目，客戶會因不專業(yè)而反復(fù)變更需求和軟件設(shè)計，實際上白費了開發(fā)人力和降低了開發(fā)效率；一些需要深度專業(yè)分析的項目，由于客戶缺少系統(tǒng)和分析專業(yè)知識而開發(fā)缺少對需求深刻理解，使項目推進(jìn)緩慢而困難。即便是直觀的項目，由于有些客戶對自身需求毫無概念，或者對技術(shù)缺少起碼的了解，也會造成工作量的無謂白費和項目停滯。 而一些項目無法簡化為可online的中間項目，在中間提交時都能獲得客戶認(rèn)同，但最終要驗收才發(fā)覺有嚴(yán)峻問題，這是客戶的非專業(yè)和不能預(yù)測引起的，國外差不多有許多如此例子。即使那些順利完成的項目，除了完全增量性的，由于不斷提交，對“組合”

60、部分反復(fù)進(jìn)行集成測試，實際確實是白費人力。而且敏捷反復(fù)拉客戶確認(rèn)需求的過程，實際上是耗費客戶的時刻量彌補需求理解能力的不足。 而有些產(chǎn)品，面向的是社會公眾（如騰訊QQ、Winrar），你無法找到客戶；盡管你能夠抽取幾十用戶代表來參與開發(fā)、評審，然而抽取的用戶代表無法代表全體，這些代表所堅持的意見，可能對另一部分用戶確實是截然相反的意見，仍然需要深刻專業(yè)的分析師。 不論從項目需求確認(rèn)的可靠性，依舊項目的效率和經(jīng)濟(jì)性看， 這差不多上一種低效的工作方式，盡管它以增加一些工作量，從而保證了項目的成功和對客戶需求的滿足。敏捷方法不能讓具有廣度和深度的軟件完美實現(xiàn)。如上所講，客戶的對需求的理解是淺顯和直白