一些成功的指導(dǎo)模式
迭代過程大多是由解決不確定性和管理軟件風(fēng)險的需要而發(fā)展的。這里的指導(dǎo)需要動態(tài)控制以及中間的檢查點，這樣涉眾可以評估到目前為止完成了哪些工作，應(yīng)該對目標(biāo)作出什么修改，以及如何重新分配他們的工作以使目標(biāo)按照為經(jīng)濟(jì)的方式組合。我曾觀察到成功的軟件集中型項目典型的四種模式。這些模式表現(xiàn)了一些“抽象規(guī)格”，對指導(dǎo)評估、范圍管理、過程控制、進(jìn)展和質(zhì)量控制有所幫助。我有預(yù)感，多數(shù)在項目管理中“被鑒定過的”項目管理者對此都會作出消極的反應(yīng)，因為這些理念在一定程度上是與傳統(tǒng)相悖的。
范圍管理：方案從用戶具體的要求發(fā)展而來，而用戶的具體要求從候選方案發(fā)展而來。與從開始確定所有需求不同。
過程控制：過程和工具的使用從輕到重漸變。與把整個項目的生存周期過程定義為輕或重不同。
進(jìn)展：健康的項目展示出一個進(jìn)展和背離的序列。與按照預(yù)期計劃實現(xiàn)價值，沒有明顯的背離不同。
質(zhì)量控制：測試可演示的發(fā)布版本是一個頭等重要的、貫穿全生命周期的活動。與認(rèn)為它是次要的，生命周期晚期的活動的觀點不同。
我承認(rèn)在實際軟件項目中，上述四點都是說起來容易做起來難，而且對不同領(lǐng)域它們應(yīng)該被不同地應(yīng)用。網(wǎng)絡(luò)應(yīng)用程序開發(fā)團(tuán)隊與嵌入式應(yīng)用程序開發(fā)團(tuán)隊實現(xiàn)這些模式的方法應(yīng)該是不同的，但是對他們來說模式都是可用的。方法、模式和技術(shù)的書籍和論文的寫作，（工業(yè)界稱為思想領(lǐng)導(dǎo)），是相對簡單的。盡管如此，我們中的多數(shù)人并不是在尋找好的思想，而是在尋找好的實踐方法。管理實際項目需要實踐的領(lǐng)導(dǎo)力，而在實際項目條件下應(yīng)用和執(zhí)行這些理念是相對困難的。我們應(yīng)當(dāng)珍惜懂得實踐的領(lǐng)導(dǎo)力的項目管理者：他們可能是每個公司中稀有的資源。的項目管理者，像的電影制作人一樣，不只是常常創(chuàng)造出的產(chǎn)品，他們還是年輕團(tuán)隊成員的良師益友，這些年輕人能夠?qū)W習(xí)有效的技術(shù)并發(fā)展他們自己在多維權(quán)衡、持續(xù)性溝通、風(fēng)險管理、模式識別以及指導(dǎo)式領(lǐng)導(dǎo)等方面的技能。項目管理訓(xùn)練課程是學(xué)習(xí)的良好催化劑，但是學(xué)徒期是不可或缺的。
范圍管理
傳統(tǒng)軟件過程的比較微妙的挑戰(zhàn)之一是如何把生存周期表現(xiàn)為一系列順序的活動：從需求分析到設(shè)計，編碼，測試，后發(fā)行。成功的項目確實用一種抽象的方式實現(xiàn)了這種進(jìn)展路線，但是活動之間的界限是模糊不清的，只能被合作的涉眾所接受。另一方面，不成功的項目則陷入了掙扎著尋找活動間清晰的界限的誤區(qū)。比如，在過渡到設(shè)計前追求固定的需求基線，或是在過渡到編碼前追求非常詳細(xì)的設(shè)計文檔，都是嚴(yán)格的中間目標(biāo)，造成了注意力被瑣碎細(xì)節(jié)所分散，而重要工程決定的進(jìn)展卻被放緩甚至停止。
當(dāng)我們建立一個全新的軟件方案時，從需求到設(shè)計的連續(xù)的詳細(xì)規(guī)格說明流也許是有一定意義的。但是現(xiàn)在，我們通常是升級一個已有系統(tǒng)或者根據(jù)已有部件（操作系統(tǒng)、網(wǎng)絡(luò)服務(wù)、網(wǎng)絡(luò)、圖形用戶界面、數(shù)據(jù)管理、封裝的應(yīng)用程序、中間件、計算平臺、遺留系統(tǒng)等）建立新的系統(tǒng)。改造或復(fù)用已有財產(chǎn)的經(jīng)濟(jì)效益迫使我們考慮在這些已有財產(chǎn)的環(huán)境和限制下的用戶具體需要。
我前面曾經(jīng)說過，需求可能是我們的工業(yè)中被嚴(yán)重誤用的詞。需求意味著不可協(xié)商，但我們卻在幾乎所有成功項目中看到需求的變化，妥協(xié)和讓步。改變一個需求需要進(jìn)行大量嚴(yán)格的審查，因為這通常對涉眾間的合同有很大影響。我建議我們使用規(guī)格說明來代替需求。規(guī)格說明是可以更改的，而且可以理解為我們現(xiàn)階段對項目的認(rèn)識狀態(tài)。
我所見過的而言，用戶規(guī)格說明有兩種重要形式。第一種是觀點陳述（或用戶需要），它抓住了開發(fā)團(tuán)隊和買方或說用戶之間的合同。這些信息應(yīng)以用戶可理解的形式（一種包括了文本、原型、用例，電子表格等等的特殊格式）表現(xiàn)。一個支持觀點陳述的用例模型起到了用戶或買方可以理解的語言表達(dá)可操作的概念以及期望的行為的作用。
規(guī)格說明的第二種形式與需求非常不同。我傾向于使用評估標(biāo)準(zhǔn)這種說法，它被自然理解為目標(biāo)的瞬間快照，而目標(biāo)是一個生存周期的中間檢查點，比如一個可演示的版本發(fā)布。評估標(biāo)準(zhǔn)是從觀點陳述或者其他資源（制作/購買/復(fù)用分析、風(fēng)險管理相關(guān)、架構(gòu)方面的考慮、隱藏問題、實現(xiàn)限制、質(zhì)量極限等等）中派生出來的中間的指導(dǎo)目標(biāo)。它們與用例模型一起，為早期測試，而不是為傳統(tǒng)的需求表達(dá)提供了更好的框架。一個計劃的發(fā)布內(nèi)容序列和計劃的評估標(biāo)準(zhǔn)的初始提議是一個風(fēng)險管理計劃的很好的形式。
過程嚴(yán)格性
多年來，我一直嘗試著調(diào)解敏捷陣營（軟件過程觀點的自由主義左翼）和過程成熟陣營（軟件過程觀點的保守派右翼）之間狂熱的爭論。他們都有有益的觀點和適當(dāng)?shù)募夹g(shù)。但是經(jīng)過老于世故的努力，在需要解決方案的范圍內(nèi)沒有清晰的正確或者錯誤的處方。上下文環(huán)境是極為重要的，而且?guī)缀跛胁皇翘^普通的項目和組織都需要結(jié)合技術(shù)、常識、領(lǐng)域內(nèi)的經(jīng)驗來取得成功。多數(shù)項目管理者會同意下述觀點：
在我看來，后一個觀點描述了決定敏捷方法的速度和自由度，嚴(yán)格方法的質(zhì)量和說明性指導(dǎo)的決定性因素。過程嚴(yán)格性應(yīng)該與重力作用很相似：你越接近產(chǎn)品的發(fā)布，過程、工具、員工每天的活動使用儀器的影響越大。你離發(fā)布日期越遠(yuǎn)，這種影響越小。這個公理在過程里似乎完全被忽略了，或者至少是不受重視的，但是它在成功的軟件項目中通常是非常引人注目的。
大多數(shù)成功的軟件開發(fā)過程的一個標(biāo)志性特征是詳細(xì)定義的從創(chuàng)造階段（初始和細(xì)化）到生產(chǎn)階段（構(gòu)建和產(chǎn)品化）的過渡過程。當(dāng)軟件項目無法成功時，一個主要的原因是對過程嚴(yán)格性不合適的強調(diào)（過多或者過少）。這種現(xiàn)象在傳統(tǒng)過程和迭代過程中都是存在的。多數(shù)不成功的項目帶有下列特征之一：
生存周期早期階段（創(chuàng)造性方面）的過度設(shè)計。你需要有機動性的過程，該過程容易適應(yīng)新發(fā)現(xiàn)、適應(yīng)對幾個主要風(fēng)險和原型方案造成攻擊的一定程度上的不確定性，并且建立早期的粗糙工件。你能想到哪些創(chuàng)造性原則，根據(jù)這些原則過程嚴(yán)格性對幫助人類思考被認(rèn)為是有益的？
生存周期晚期階段（生產(chǎn)方面）的設(shè)計不足。詳細(xì)工件的廣泛的變化管理基線需要帶有富有洞察力的實現(xiàn)方法，對連貫性的密切關(guān)注，以及自始至終對產(chǎn)品質(zhì)量聚焦的工程過程。
