本文介紹了管理一個(gè)軟件產(chǎn)品與管理一部電影作品的若干對比，然后討論了從成功項目中獲得的四種軟件管理方法。
使用傳統的工程管理原則管理軟件項目是很難取得成功的。把軟件管理的挑戰與制作一部動(dòng)作大片進(jìn)行比較，我們會(huì )發(fā)現很多有趣的觀(guān)點(diǎn)。兩者的管理問(wèn)題都集中在在受經(jīng)濟因素制約的環(huán)境下進(jìn)行復雜的集成知識產(chǎn)權的開(kāi)發(fā)。本文介紹了管理一個(gè)軟件產(chǎn)品與管理一部電影作品的一些對比，然后詳細介紹了從成功項目中獲得的軟件管理的四種方法。主要的推薦做法是使用指導性的領(lǐng)導方式，而不是傳統理念上的事無(wú)巨細的計劃-軌跡領(lǐng)導方式。
在我的職業(yè)生涯中，我有機會(huì )觀(guān)察并評估了上百個(gè)軟件項目，它們廣泛覆蓋了各種工業(yè)和應用。一個(gè)顯著(zhù)的成敗決定因素是在項目從初始到被用戶(hù)接受的過(guò)程中所采用的項目管理方式。
根據我的經(jīng)驗，如果軟件項目管理者使用更像是管理一部電影作品的方式，而不是管理一個(gè)工程產(chǎn)品的方式，那么他們似乎更容易成功。“胡說(shuō)！”有人可能反對。“軟件項目需要更多嚴格的工程管理，而不是更少！”在你發(fā)表你的言論，向權威發(fā)出挑戰以前，請考慮以下觀(guān)察資料：
大多數軟件權威不需要物理定律或者物質(zhì)屬性來(lái)制約他們的問(wèn)題及其解決方案。他們只是受到人類(lèi)想象力、經(jīng)濟因素的制約，以及當他們獲得一些可執行程序時(shí)，他們受到運行平臺性能的制約。一些嵌入式軟件的開(kāi)發(fā)者顯然是例外者。
在一個(gè)軟件項目中，你幾乎可以在任何時(shí)間改變任何東西：計劃、人、預算里程碑、需求、設計、測試等等。需求——可能是我們的工業(yè)中被最嚴重誤用的詞——很少能描述出真正需要的任何事情。一切幾乎都是可以協(xié)商的。
軟件產(chǎn)品的評估和衡量沒(méi)有原子單元。經(jīng)濟性能（在服務(wù)行業(yè)中更為典型，評價(jià)為性?xún)r(jià)比）被證明是最好的成功的度量手段。質(zhì)量的大多數方面都是很主觀(guān)的，比如可維護性、可靠性以及可用性。
這些觀(guān)察結果對電影制片人同樣適用，他們是有規律地創(chuàng )作獨特的、復雜的、只受視角和人類(lèi)創(chuàng )造性制約的知識產(chǎn)權作品。我假設電影作品的經(jīng)濟性能與軟件項目的經(jīng)濟性能是相似的：從2000年起，只有三分之一作品的發(fā)行帶有時(shí)間或經(jīng)濟上的可預言性。1我知道這些觀(guān)察在使用工程理念來(lái)制造飛機、橋梁、心臟移植管、核反應堆、摩天大樓以及衛星的項目管理者看來(lái)是不入流的（除非這些工程項目包括重要的軟件內容或是空前的，史無(wú)前例的系統）。
好的，有人可能會(huì )說(shuō)，軟件只是一個(gè)未成熟的工程分支，在我的職業(yè)生涯中，大約每五年軟件項目的底層技術(shù)就要翻新一次。這些翻新包括語(yǔ)言、結構模式、應用、用戶(hù)界面、計算平臺、網(wǎng)絡(luò )、環(huán)境、過(guò)程以及工具。這種快速持續的進(jìn)化將要放慢了嗎？目前還看不出這種跡象。人類(lèi)想象力和市場(chǎng)作用仍是非常強大的。
就像電影工業(yè)，我們需要有資格的建筑師（導演）、分析家（編劇、設計師）、軟件工程師（產(chǎn)品工作人員、編輯、特技制造者、演員替身）以及項目管理者（制片人）。還是和電影工業(yè)一樣，我們必須使軟件成為可執行形式（弄到膠片上）來(lái)切實(shí)進(jìn)行進(jìn)度和質(zhì)量的評估。在我們發(fā)現什么可用什么不可用的過(guò)程中會(huì )產(chǎn)生大量的碎片和重復工作，然后我們把很多人的貢獻集成為一個(gè)緊密集成的知識產(chǎn)權作品。
我所認識到的是，軟件管理應被更精確地描述為軟件經(jīng)濟的一個(gè)分支，而不是軟件工程。軟件管理者每天的決定（正如電影制作人每天的決定），主要是由價(jià)值判斷、成本權衡、人為因素、宏觀(guān)經(jīng)濟趨勢、技術(shù)趨勢、市場(chǎng)強度以及時(shí)機控制的。軟件項目很少注重于精確的數學(xué)、物質(zhì)屬性、物理定律或是其他已經(jīng)建立的成熟的工程原則。
我希望這一對軟件-電影的對比刺激了你的神經(jīng)，使你想繼續讀下去。如果想了解更詳細的對比請參考 Paul Graham 的論文。2下文著(zhù)重介紹的是一些從軟件項目中獲得的斷言，這些項目包括了我在25年多的時(shí)間里在軟件項目管理領(lǐng)域跟從、領(lǐng)導、實(shí)踐、指導的少數成功軟件項目和大量不成功軟件項目。
迭代的方法
造成軟件集中型項目的低成功率的原因之一是傳統的項目管理方法不鼓勵進(jìn)行指導和調整以緩解以下問(wèn)題的不確定性：
問(wèn)題域（用戶(hù)究竟想要或者需要什么）
解決域（何種結構和技術(shù)的組合是最適用的）
計劃域（成本和時(shí)間制約、團隊組成和生產(chǎn)力、涉眾交流、遞增結果序列等等）
我們需要一種更為動(dòng)態(tài)和具有適應性的方法來(lái)思考軟件進(jìn)程和質(zhì)量管理的問(wèn)題，這種方法應當適應成功項目的模式。當今的現代軟件管理方法3-5 通常被稱(chēng)為迭代 開(kāi)發(fā)方法。在現今充滿(mǎn)不確定性的軟件應用程序、產(chǎn)品和服務(wù)開(kāi)發(fā)的雷區中，迭代方法指導了軟件項目，而不是遵循一個(gè)精確的、長(cháng)期的計劃。按時(shí)間和預算計劃成功發(fā)布軟件產(chǎn)品需要一種發(fā)現、生產(chǎn)、評估和指導性領(lǐng)導方式的進(jìn)步的混合。“指導”一詞意味著(zhù)積極的管理參與，經(jīng)常的過(guò)程矯正以產(chǎn)生更好的結果。所有涉眾應該通力合作，集中實(shí)現不斷前進(jìn)的目標。
作為一個(gè)被廣泛接受的現代迭代開(kāi)發(fā)過(guò)程，IBM Rational Unified Process，6 為一個(gè)更為平衡的發(fā)展提供了一個(gè)框架，這一發(fā)展是鼓勵對不確定性和風(fēng)險進(jìn)行管理的。它的生命周期包括四個(gè)階段，每個(gè)階段都有可演示的結果：
1.起始：遠景和商業(yè)案例的定義和原型設計
2.細化：對架構基線(xiàn)進(jìn)行集成、論證和評估
3.構建：對有用的增量進(jìn)行開(kāi)發(fā)、論證和評估
4.產(chǎn)品化：可用性評估、最終產(chǎn)品以及發(fā)行
階段的名稱(chēng)表現了項目的狀態(tài)，而不是從需求到設計到編碼到測試到發(fā)行的基于順序性活動(dòng)的項目進(jìn)展。
我們把這一迭代管理方式稱(chēng)為基于結果的，而不是基于活動(dòng)的。在軟件世界中，真正的結果是可執行程序。其他的任何東西（需求文檔、用例模型、設計模型、測試用例、計劃、過(guò)程、文檔、檢查）都是次要的，而且只是實(shí)現目標——一個(gè)可執行的軟件程序——的手段的一部分?；叵肽阕龀绦騿T的日子：當你在建立一個(gè)模型、畫(huà)流程圖草圖、推理一個(gè)狀態(tài)機的邏輯或是寫(xiě)源代碼的時(shí)候，你知道你只是在思考和集成一個(gè)抽象方案。只有當你編譯、鏈接和執行時(shí)方案才變得切實(shí)可行。項目管理者應該有同樣的感覺(jué)。當你評估一個(gè)計劃、模型、文檔或一些其他不可執行的表現物的美好和出色之處時(shí)，你只是在推測項目質(zhì)量和進(jìn)度。電影制作人對劇本、情節串連板、背景設置以及服裝設計的感覺(jué)也是如此。他們著(zhù)力于影片的每一個(gè)鏡頭，使得電影成為可以判斷總體集成效果的實(shí)體。
精確度與準確度
在一個(gè)成功的軟件項目中，每一個(gè)開(kāi)發(fā)階段都加深了對發(fā)展計劃、規格說(shuō)明和完整解決方案的理解，因為每一個(gè)階段都延伸了可執行序列和團隊對競爭目標的認識。在生命周期中的任意一點(diǎn)，次要工件的精確性應與這種理解相平衡，在詳細程度上保持一致，相互之間保持一定程度的可追蹤性。
精確度與準確度之間的區別（在軟件管理的上下文中）并不是它們看起來(lái)那樣小。軟件管理充滿(mǎn)灰色的區域、情景依賴(lài)性以及不明確的折衷。對優(yōu)秀的軟件管理者來(lái)說(shuō)，理解精確性與準確性之間的區別是一種基本技能，因為他們必須準確地對投資、風(fēng)險以及變化帶來(lái)的影響進(jìn)行預測。未被證實(shí)的精確度——在需求或是計劃內的——實(shí)際上是造成阻礙成功的潛在而微妙的因素。大多數時(shí)候，早期的精確性是不誠實(shí)的，造成了有比實(shí)際上更多的進(jìn)展和更高的質(zhì)量的假象。不幸的是，很多項目發(fā)起者和涉眾要求這種早期精確性和詳細性，因為這給了他們對已經(jīng)取得的進(jìn)展的（虛假的）安慰。
我在軟件工業(yè)中所見(jiàn)的最常見(jiàn)的失敗模式之一是開(kāi)發(fā)有五位數精度的規格說(shuō)明，而涉眾其實(shí)對問(wèn)題、方案或者計劃只有一位數精度的理解。延長(cháng)建立一個(gè)精確的需求理解或詳細的計劃的時(shí)間實(shí)際上耽誤了對架構上更重要的問(wèn)題的理解。你曾經(jīng)做過(guò)、修改過(guò)、痛苦地回顧過(guò)多少厚度嚇人的需求文檔或是詳細的管理計劃呢？而幾個(gè)月后當項目取得了有實(shí)際意義的可演示的進(jìn)展，加快了涉眾對實(shí)際的權衡的理解時(shí)，你又要全部重新檢查這些文檔和計劃了。這種普遍現象在我們的行業(yè)里被稱(chēng)為刨光廢物。
一些成功的指導模式
迭代過(guò)程大多是由解決不確定性和管理軟件風(fēng)險的需要而發(fā)展的。這里的指導需要動(dòng)態(tài)控制以及中間的檢查點(diǎn)，這樣涉眾就可以評估到目前為止完成了哪些工作，應該對目標作出什么修改，以及如何重新分配他們的工作以使目標按照最為經(jīng)濟的方式組合。我曾觀(guān)察到成功的軟件集中型項目典型的四種模式。這些模式表現了一些“抽象規格”，對指導評估、范圍管理、過(guò)程控制、進(jìn)展和質(zhì)量控制有所幫助。我有預感，多數在項目管理中“被鑒定過(guò)的”項目管理者對此都會(huì )作出消極的反應，因為這些理念在一定程度上是與傳統相悖的。
范圍管理：方案從用戶(hù)具體的要求發(fā)展而來(lái)，而用戶(hù)的具體要求從候選方案發(fā)展而來(lái)。與從開(kāi)始就確定所有需求不同。
過(guò)程控制：過(guò)程和工具的使用從輕到重漸變。與把整個(gè)項目的生存周期過(guò)程定義為輕或重不同。
進(jìn)展：健康的項目展示出一個(gè)進(jìn)展和背離的序列。與按照預期計劃100%實(shí)現價(jià)值，沒(méi)有明顯的背離不同。
質(zhì)量控制：測試可演示的發(fā)布版本是一個(gè)頭等重要的、貫穿全生命周期的活動(dòng)。與認為它是次要的，生命周期晚期的活動(dòng)的觀(guān)點(diǎn)不同。
我承認在實(shí)際軟件項目中，上述四點(diǎn)都是說(shuō)起來(lái)容易做起來(lái)難，而且對不同領(lǐng)域它們應該被不同地應用。網(wǎng)絡(luò )應用程序開(kāi)發(fā)團隊與嵌入式應用程序開(kāi)發(fā)團隊實(shí)現這些模式的方法應該是不同的，但是對他們來(lái)說(shuō)模式都是可用的。方法、模式和技術(shù)的書(shū)籍和論文的寫(xiě)作，（工業(yè)界稱(chēng)為思想領(lǐng)導），是相對簡(jiǎn)單的。盡管如此，我們中的多數人并不是在尋找最好的思想，而是在尋找最好的實(shí)踐方法。管理實(shí)際項目需要實(shí)踐的領(lǐng)導力，而在實(shí)際項目條件下應用和執行這些理念是相對困難的。我們應當珍惜懂得實(shí)踐的領(lǐng)導力的項目管理者：他們可能是每個(gè)公司中最稀有的資源。優(yōu)秀的項目管理者，就像優(yōu)秀的電影制作人一樣，不只是常常創(chuàng )造出優(yōu)秀的產(chǎn)品，他們還是年輕團隊成員的良師益友，這些年輕人能夠學(xué)習有效的技術(shù)并發(fā)展他們自己在多維權衡、持續性溝通、風(fēng)險管理、模式識別以及指導式領(lǐng)導等方面的技能。項目管理訓練課程是學(xué)習的良好催化劑，但是學(xué)徒期是不可或缺的。
范圍管理
傳統軟件過(guò)程的比較微妙的挑戰之一是如何把生存周期表現為一系列順序的活動(dòng)：從需求分析到設計，編碼，測試，最后發(fā)行。成功的項目確實(shí)用一種抽象的方式實(shí)現了這種進(jìn)展路線(xiàn)，但是活動(dòng)之間的界限是模糊不清的，只能被合作的涉眾所接受。另一方面，不成功的項目則陷入了掙扎著(zhù)尋找活動(dòng)間清晰的界限的誤區。比如，在過(guò)渡到設計前追求100%固定的需求基線(xiàn)，或是在過(guò)渡到編碼前追求非常詳細的設計文檔，都是嚴格的中間目標，造成了注意力被瑣碎細節所分散，而重要工程決定的進(jìn)展卻被放緩甚至停止。
當我們建立一個(gè)全新的軟件方案時(shí)，從需求到設計的連續的詳細規格說(shuō)明流也許是有一定意義的。但是現在，我們通常是升級一個(gè)已有系統或者根據已有部件（操作系統、網(wǎng)絡(luò )服務(wù)、網(wǎng)絡(luò )、圖形用戶(hù)界面、數據管理、封裝的應用程序、中間件、計算平臺、遺留系統等）建立新的系統。改造或復用已有財產(chǎn)的經(jīng)濟效益迫使我們考慮在這些已有財產(chǎn)的環(huán)境和限制下的用戶(hù)具體需要。
我前面曾經(jīng)說(shuō)過(guò)，需求可能是我們的工業(yè)中被最嚴重誤用的詞。需求意味著(zhù)不可協(xié)商，但我們卻在幾乎所有成功項目中看到需求的變化，妥協(xié)和讓步。改變一個(gè)需求需要進(jìn)行大量嚴格的審查，因為這通常對涉眾間的合同有很大影響。我建議我們使用規格說(shuō)明來(lái)代替需求。規格說(shuō)明是可以更改的，而且可以理解為我們現階段對項目的認識狀態(tài)。
就我所見(jiàn)過(guò)的而言，用戶(hù)規格說(shuō)明有兩種重要形式。第一種是觀(guān)點(diǎn)陳述（或用戶(hù)需要），它抓住了開(kāi)發(fā)團隊和買(mǎi)方或說(shuō)用戶(hù)之間的合同。這些信息應以用戶(hù)可理解的形式（一種包括了文本、原型、用例，電子表格等等的特殊格式）表現。一個(gè)支持觀(guān)點(diǎn)陳述的用例模型起到了用戶(hù)或買(mǎi)方可以理解的語(yǔ)言表達可操作的概念以及期望的行為的作用。
規格說(shuō)明的第二種形式與需求非常不同。我傾向于使用評估標準這種說(shuō)法，它被自然理解為目標的瞬間快照，而目標是一個(gè)生存周期的中間檢查點(diǎn)，比如一個(gè)可演示的版本發(fā)布。評估標準是從觀(guān)點(diǎn)陳述或者其他資源（制作/購買(mǎi)/復用分析、風(fēng)險管理相關(guān)、架構方面的考慮、隱藏問(wèn)題、實(shí)現限制、質(zhì)量極限等等）中派生出來(lái)的中間的指導目標。它們與用例模型一起，為早期測試，而不是為傳統的需求表達提供了更好的框架。一個(gè)計劃的發(fā)布內容序列和計劃的評估標準的初始提議就是一個(gè)風(fēng)險管理計劃的很好的形式。
過(guò)程嚴格性
多年來(lái)，我一直嘗試著(zhù)調解敏捷陣營(yíng)（軟件過(guò)程觀(guān)點(diǎn)的自由主義左翼）和過(guò)程成熟陣營(yíng)（軟件過(guò)程觀(guān)點(diǎn)的保守派右翼）之間狂熱的爭論。他們都有有益的觀(guān)點(diǎn)和適當的技術(shù)。但是經(jīng)過(guò)最老于世故的努力，在需要解決方案的范圍內沒(méi)有清晰的正確或者錯誤的處方。上下文環(huán)境是極為重要的，而且幾乎所有不是太過(guò)普通的項目和組織都需要結合技術(shù)、常識、領(lǐng)域內的經(jīng)驗來(lái)取得成功。多數項目管理者會(huì )同意下述觀(guān)點(diǎn)：
在我看來(lái)，最后一個(gè)觀(guān)點(diǎn)描述了決定敏捷方法的速度和自由度，嚴格方法的質(zhì)量和說(shuō)明性指導的決定性因素。過(guò)程嚴格性應該與重力作用很相似：你越接近產(chǎn)品的發(fā)布，過(guò)程、工具、員工每天的活動(dòng)使用儀器的影響就越大。你離發(fā)布日期越遠，這種影響就越小。這個(gè)公理在過(guò)程里似乎完全被忽略了，或者至少是不受重視的，但是它在成功的軟件項目中通常是非常引人注目的。
大多數成功的軟件開(kāi)發(fā)過(guò)程的一個(gè)標志性特征是詳細定義的從創(chuàng )造階段（初始和細化）到生產(chǎn)階段（構建和產(chǎn)品化）的過(guò)渡過(guò)程。當軟件項目無(wú)法成功時(shí)，一個(gè)主要的原因是對過(guò)程嚴格性不合適的強調（過(guò)多或者過(guò)少）。這種現象在傳統過(guò)程和迭代過(guò)程中都是存在的。多數不成功的項目帶有下列特征之一：
生存周期早期階段（創(chuàng )造性方面）的過(guò)度設計。你需要有機動(dòng)性的過(guò)程，該過(guò)程容易適應新發(fā)現、適應對幾個(gè)主要風(fēng)險和原型方案造成攻擊的一定程度上的不確定性，并且建立早期的粗糙工件。你能想到哪些創(chuàng )造性原則，根據這些原則過(guò)程嚴格性對幫助人類(lèi)思考被認為是有益的？
生存周期晚期階段（生產(chǎn)方面）的設計不足。詳細工件的廣泛的變化管理基線(xiàn)需要帶有富有洞察力的實(shí)現方法，對連貫性的密切關(guān)注，以及自始至終對產(chǎn)品質(zhì)量聚焦的工程過(guò)程。
成功的現代項目——以及使用傳統過(guò)程開(kāi)發(fā)的成功項目——通常都有詳細定義的項目階段性標志，即從創(chuàng )造性研究狀態(tài)到生產(chǎn)狀態(tài)的顯著(zhù)過(guò)渡。早期階段著(zhù)重于實(shí)現可演示的功能。后期階段著(zhù)重于實(shí)現可供用戶(hù)使用的產(chǎn)品，這種產(chǎn)品關(guān)注的是健壯性、性能、適用性以及完整性。
另一個(gè)重要方面是從創(chuàng )造性世界到生產(chǎn)世界的過(guò)渡對整個(gè)團隊的影響。結構良好的團隊通常不喜歡嚴格的過(guò)程、細節以及不成熟的精確性。生產(chǎn)能力強的團隊通常會(huì )對松散的、不固定的、粗糙的結果感到不愉快。項目管理者需要管理各種團隊的平衡性，這樣技術(shù)上領(lǐng)導的重力中心就可以在整個(gè)生存周期發(fā)展進(jìn)化，從初始階段的管理團隊，到細化階段的架構團隊，到建構階段的開(kāi)發(fā)團隊，再到過(guò)渡階段的測試/評估團隊。軟件項目管理中人的因素被低估了，而且團隊動(dòng)態(tài)性的主題值得被給予比今天大多數項目管理課程所給予的更多的關(guān)注。
進(jìn)展
經(jīng)典開(kāi)發(fā)過(guò)程的很多方面造成了涉眾關(guān)系退化到相互間的不信任。信任對在用戶(hù)需要、產(chǎn)品特性以及計劃中通過(guò)指導和協(xié)商取得平衡是最基本的。迭代過(guò)程加強了涉眾間的有效交流（通過(guò)一系列可演示的發(fā)布實(shí)現），允許基于更為客觀(guān)的所有人理解的協(xié)商。這需要客戶(hù)、用戶(hù)、以及管理者集中于可用系統的發(fā)布，而不是篤信標準和合同條款。它同時(shí)還需要開(kāi)發(fā)組織致力于用能獲得利潤的方式創(chuàng )造價(jià)值。
迭代過(guò)程需要對一個(gè)不斷完整的系統進(jìn)行順序的建構，這個(gè)系統展示了架構，實(shí)現了客觀(guān)的需求協(xié)商，證實(shí)了技術(shù)方法，并指出關(guān)鍵風(fēng)險。理想的情況下，所有涉眾都著(zhù)眼于這些里程碑，把它們視為有用功能的遞增發(fā)布，這不同于那些投機的對最終觀(guān)點(diǎn)的論文描述。向可演示驅動(dòng)的生存周期的過(guò)渡造成了非常不同的項目外觀(guān)。一個(gè)健康的項目將誠實(shí)地展示出一個(gè)進(jìn)展與背離共存的序列，而不是一個(gè)線(xiàn)性發(fā)展價(jià)值遞增的軌跡（通常是不誠實(shí)的）。
下面是兩個(gè)我從未見(jiàn)過(guò)的反例的相關(guān)觀(guān)察：
1.一個(gè)具有一張價(jià)值持續不斷增長(cháng)曲線(xiàn)圖的軟件項目一定會(huì )有一個(gè)待解決的很大的回歸。
2.在解決不確定性，會(huì )師于一個(gè)可接受的解決方案的過(guò)程中，健康的軟件項目表現為一個(gè)進(jìn)展不斷增加，彎路不斷減少的序列。
雄心勃勃的展示是一個(gè)健康的項目的發(fā)展道路上絕好的里程碑。在生存周期早期進(jìn)行展示的目的是暴露設計缺陷，不是粉飾門(mén)面。涉眾不應對早期錯誤、背離或不成熟的設計反應過(guò)激。如果早期工程階段受到過(guò)分限制，開(kāi)發(fā)組織建立的中間檢查點(diǎn)將不會(huì )那么有抱負。早期的增量是不成熟的。外界涉眾，比如客戶(hù)和用戶(hù)，不能指望初始發(fā)布的版本擁有最終發(fā)布版本的規格和性能——也就是完整、完全可靠、擁有目標級的質(zhì)量和性能。
另一方面，開(kāi)發(fā)組織必須對連續增量之上的切實(shí)的進(jìn)展負責，并對之進(jìn)行展示?？陀^(guān)地量化變化、修改以及更新將會(huì )為進(jìn)展和質(zhì)量提供誠實(shí)的指示。公開(kāi)和專(zhuān)心的追隨對解決問(wèn)題是必須的。好的和不好的項目性能在生存周期的早期往往更為明顯。采用指導式的領(lǐng)導方式，成功就會(huì )孕育成功。在發(fā)布一系列可演示的結果以后，你就可以很好地預測結果了。持續沒(méi)有進(jìn)展或者停滯的結果序列是項目需要認真重新考慮資源、范圍或者項目?jì)r(jià)值的標志。軟件項目的經(jīng)驗已多次表明，早期階段決定項目的成敗。這就是使用小型的、能力強的出發(fā)團隊處理計劃和架構設計階段工作的原因。如果這些早期階段處理得當，項目將會(huì )由能力中等規模的團隊向最終產(chǎn)品發(fā)展，并成功完成。如果計劃和架構設計階段處理不好，即使出動(dòng)全世界的程序和測試專(zhuān)家可能也無(wú)法在后續階段取得成功。
質(zhì)量控制
如果你按照迭代開(kāi)發(fā)的精神正在成功管理一個(gè)項目，那么多數集成測試應在部件測試之前進(jìn)行。停下來(lái)思考這一陳述。盡管在任何時(shí)候都有兩種活動(dòng)在混合進(jìn)行，你應該認識到初始的部件開(kāi)發(fā)和測試更多的是作為在一個(gè)集成的、系統級的線(xiàn)程或行為內執行一個(gè)部件的接口和功能的方法。一旦接口和集成行為被成功測試，部件的完整性也就可以測試了。先進(jìn)行集成測試加速了架構上重要的問(wèn)題更早進(jìn)入生存周期的相應階段。它還為持續的系統級和部件級進(jìn)展和性能的評估提供了演進(jìn)的測試模板。
這種先進(jìn)行集成測試的方法的一個(gè)關(guān)鍵副產(chǎn)品是測試和測試人員成了項目過(guò)程中的頭等公民。在傳統方法中，測試人員建立計劃、過(guò)程和文檔，它們都是次要于分析和設計工件的。測試人員的工作和生存周期早期的工件對項目的成功沒(méi)有太多指示作用，在多數組織內都是由“B選手”（意思是，不能成為最優(yōu)秀分析和設計師的人）來(lái)完成的。在健康的迭代項目中，生存周期早期的演示需要重要的測試觀(guān)念和產(chǎn)品。很多測試團隊對一些最有效的“分析”活動(dòng)和結果負有責任。太多分析人員在抽象模型內單獨工作，他們的分析受到的制約是有限的。但是測試人員面臨的是建立“測試用例”——真實(shí)世界中用例或者評估標準或者預期行為的表現。他們提出一整套不同的問(wèn)題并從一個(gè)不同的角度看世界，因為他們的工作是把抽象的東西翻譯為可測試的東西。
這是一個(gè)例子?，F在很多項目都面臨著(zhù)對商業(yè)上可獲得的部件和應用程序是采取買(mǎi)還是自己寫(xiě)的辦法的抉擇。如果第一個(gè)面向結果的項目的里程碑是通過(guò)演示來(lái)作出自己寫(xiě)/購買(mǎi)的決定的，那么你應該對你的團隊進(jìn)行如下分工：
分析團隊：與用戶(hù)一起工作，捕捉產(chǎn)生最差性能的關(guān)鍵用例的情況，比如數據量峰值或者最關(guān)鍵的控制畫(huà)面。
設計團隊：設計可以運行候選商業(yè)部件的原型。
測試團隊：構建測試用例（比如，一個(gè)消息集合、一個(gè)測試驅動(dòng)、一個(gè)智能樁模塊、一個(gè)有數據的數據庫、一個(gè)圖形用戶(hù)界面操作的序列等等）。這些用例能夠反映關(guān)鍵用例，驅動(dòng)原型并記錄它的相應。
為了實(shí)現這第一個(gè)里程碑，你的團隊可以只關(guān)注其中兩個(gè)關(guān)鍵用例（約為用戶(hù)需要的10%）、少數幾個(gè)關(guān)鍵部件以及少數幾個(gè)測試用例，但是它們以及用戶(hù)將會(huì )在生存周期非常早的時(shí)候就解決掉30%的風(fēng)險。通過(guò)把測試觀(guān)點(diǎn)作為過(guò)程早期一個(gè)同等伙伴包括進(jìn)來(lái)，你將可以吸引更多作出更好分析的優(yōu)秀人才，因為這項工作更為有趣，而且對成功的貢獻更為有效。
傳統軟件測試方法遵循相同的、應用于軟件開(kāi)發(fā)的文檔驅動(dòng)方法。開(kāi)發(fā)團隊在建立任何源文件或可執行文件之前先建立需求文檔、頂層設計文檔以及詳細設計文檔。相似地，測試團隊在建立任何測試驅動(dòng)、樁模塊或工具之前先建立系統測試計劃文檔，系統測試過(guò)程文檔、集成測試計劃文檔、單元測試計劃文檔以及單元測試過(guò)程文檔。這一文檔驅動(dòng)方法對測試活動(dòng)造成的問(wèn)題與它對開(kāi)發(fā)活動(dòng)造成的問(wèn)題是相同的：對大量廢物的刨光，還要留待日后重新組合整理。
為了在生存周期中提早進(jìn)行集成測試，測試序列應該由迭代過(guò)程來(lái)組織，而不是根據部件來(lái)組織。典型地，它應該被一組用例和其它文本表現的、能有意義地為用戶(hù)進(jìn)行演示的實(shí)體所捕獲。下面是一個(gè)抽象的描述：
初始迭代：大約五到十個(gè)評估標準，抓住與主要用例（對結構選擇和整體商業(yè)案例有影響的）相關(guān)的驅動(dòng)問(wèn)題。
細化迭代：十幾個(gè)評估標準，當用候選架構進(jìn)行演示時(shí)，為主要用例檢驗實(shí)體框架，并證明關(guān)鍵風(fēng)險已經(jīng)被解決了。
構建迭代：大約數百個(gè)與有意義的用例集相關(guān)的評估標準，這些用例集通過(guò)測試以后將組成有用的產(chǎn)品子集，可以轉為產(chǎn)品的alpha或beta發(fā)布版本。
產(chǎn)品化迭代：完整的用例集和相關(guān)的評估標準（可能有上千個(gè)），組成了與真正發(fā)布產(chǎn)品相關(guān)的接受測試結果的標準。
現代過(guò)程在產(chǎn)品的測試活動(dòng)中使用的基本工具、語(yǔ)言、符號以及工件與在產(chǎn)品的開(kāi)發(fā)過(guò)程中使用的是相同的。測試是指對某些組件在一個(gè)控制情境下的執行以及期望的客觀(guān)結果的外在評估。一個(gè)測試的成功取決于在一般意義上定義的成功標準下期望結果與實(shí)際結果的比較情況。測試就是可以大規模自動(dòng)化由機器完成的評估形式。
總結
圖1提供了項目管理者對改進(jìn)時(shí)間和價(jià)值過(guò)渡的觀(guān)點(diǎn)，我們都應該努力實(shí)現這一理念。它為概括有效實(shí)現指導式領(lǐng)導（我在四項推薦中所暗示的）提供了一個(gè)很好的抽象視角。我通過(guò)畫(huà)出開(kāi)發(fā)進(jìn)度-時(shí)間圖展示了三個(gè)項目的外觀(guān)，其中進(jìn)度是用可執行百分比定義的，也就是用目標的可演示形式。在這個(gè)意義下的進(jìn)展是與結果確實(shí)相關(guān)的，正如我前面描述過(guò)的，而且通過(guò)可執行演示是很好度量的?？蓤绦胁灰馕吨?zhù)完整、適應或是符合規格；但是它確實(shí)意味著(zhù)軟件是可測試的。
當使用這種度量方法時(shí)，典型的傳統工程項目管理風(fēng)格序列是（1）通過(guò)文字設計和詳細（經(jīng)常過(guò)于詳細）工件實(shí)現的早期成功，（2）承諾在生存周期后期完成可執行代碼，（3）由不可預見(jiàn)的實(shí)現問(wèn)題和接口二義性造成的集成噩夢(mèng)，（4）使系統工作起來(lái)的巨大的預算和時(shí)間壓力，（5）末期不甚理想的產(chǎn)品，沒(méi)有時(shí)間進(jìn)行重新設計，最后（6）一個(gè)脆弱、不可維護的產(chǎn)品推遲發(fā)行。
我這里介紹的現代管理方法把集成加入到了設計階段，并經(jīng)過(guò)一系列可演示的版本發(fā)布，于是也就使得架構上重要的缺陷更早出現，能夠在生存周期目標的上下文中被解決。順流而下的集成噩夢(mèng)被避免了，同時(shí)避免的還有以后的補丁和軟件修正。結果是一個(gè)更為健壯和可維護的產(chǎn)品的按期發(fā)行，于是產(chǎn)品在經(jīng)濟上成功的可能性也就更大了。
使用傳統方法管理的項目，陷于集成的無(wú)效性和實(shí)質(zhì)設計問(wèn)題的發(fā)現過(guò)晚，把總資源消耗的40%花在集成和測試活動(dòng)上，而這些努力大多帶來(lái)的是過(guò)量的碎片和返工。采用迭代過(guò)程和指導式領(lǐng)導的現代項目發(fā)行一個(gè)產(chǎn)品，上述活動(dòng)只消耗了預算的25%。
我討論了真正使用迭代開(kāi)發(fā)精神管理的項目的四種成功模式。每個(gè)模式表現了一種平衡，它能夠幫助團隊掌控制做產(chǎn)品和獲得經(jīng)濟效益的路徑：
用戶(hù)需要與設計資產(chǎn)間的平衡
創(chuàng )造性過(guò)程的自由性與生產(chǎn)過(guò)程的嚴格性間的平衡
產(chǎn)品進(jìn)度與實(shí)驗性的識別背離的平衡
抽象觀(guān)點(diǎn)與通過(guò)測試進(jìn)行的切實(shí)評估間的平衡
根據我的經(jīng)驗，前例中的傳統項目外觀(guān)仍然是普遍的，是我們今天見(jiàn)到的一半以上項目的特征。盡管這些項目中的多數使用傳統的工程管理方法，有一些聲稱(chēng)使用了現代迭代開(kāi)發(fā)。但是，由于不采用指導式領(lǐng)導，它們沒(méi)能成功取得預期的商業(yè)結果。也許今天的項目有四分之一采用了現代模式，但只有八分之一能夠在目標外觀(guān)上進(jìn)行操作。正是從這些不固定的外觀(guān)和成功的結果上我觀(guān)察出了本文所討論的風(fēng)格的一致使用問(wèn)題。
和建造一座橋比起來(lái)，軟件項目管理真的更像管理一部電影作品嗎？也許不是這樣，特別是在產(chǎn)品的后幾個(gè)階段。但是我希望這種類(lèi)比能使讀者從不同的參考中來(lái)審視軟件項目管理技術(shù)。這些模式不是新的。它們在很多組織，以各種不同的程度，在廣泛領(lǐng)域內經(jīng)過(guò)了實(shí)踐（盡管不太經(jīng)常）。如果你深入研究在實(shí)踐中使用這些模式，你會(huì )發(fā)現它們都著(zhù)眼于處理管理上的人與團隊工作的方面，很少帶有科學(xué)、工程或是制造業(yè)的偏見(jiàn)。我認為采用指導式管理的組織更容易取得經(jīng)濟上的成功——甚至可能一鳴驚人。
聯(lián)系客服
