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