關鍵字：指導與平衡
本文介紹了管理一個軟件產品與管理一部電影作品的若干對比，然后討論了從成功項目中獲得的四種軟件管理方法。 使用傳統的工程管理原則管理軟件項目是很難取得成功的。把軟件管理的挑戰與制作一部動作大片進行比較，我們會發現很多有趣的觀點。兩者的管理問題都集中在在受經濟因素制約的環境下進行復雜的集成知識產權的開發。本文介紹了管理一個軟件產品與管理一部電影作品的一些對比，然后詳細介紹了從成功項目中獲得的軟件管理的四種方法。主要的推薦做法是使用指導性的領導方式，而不是傳統理念上的事無巨細的計劃-軌跡領導方式。
在我的職業生涯中，我有機會觀察并評估了上百個軟件項目，它們廣泛覆蓋了各種工業和應用。一個顯著的成敗決定因素是在項目從初始到被用戶接受的過程中所采用的項目管理方式。
根據我的經驗，如果軟件項目管理者使用更像是管理一部電影作品的方式，而不是管理一個工程產品的方式，那么他們似乎更容易成功�！昂f！”有人可能反對�！败浖椖啃枰鄧栏竦墓こ坦芾�，而不是更少！”在你發表你的言論，向權威發出挑戰以前，請考慮以下觀察資料：
大多數軟件權威不需要物理定律或者物質屬性來制約他們的問題及其解決方案。他們只是受到人類想象力、經濟因素的制約，以及當他們獲得一些可執行程序時，他們受到運行平臺性能的制約。一些嵌入式軟件的開發者顯然是例外者。
在一個軟件項目中，你幾乎可以在任何時間改變任何東西：計劃、人、預算里程碑、需求、設計、測試等等。需求——可能是我們的工業中被最嚴重誤用的詞——很少能描述出真正需要的任何事情。一切幾乎都是可以協商的。
軟件產品的評估和衡量沒有原子單元。經濟性能（在服務行業中更為典型，評價為性價比）被證明是最好的成功的度量手段。質量的大多數方面都是很主觀的，比如可維護性、可靠性以及可用性。
這些觀察結果對電影制片人同樣適用，他們是有規律地創作獨特的、復雜的、只受視角和人類創造性制約的知識產權作品。我假設電影作品的經濟性能與軟件項目的經濟性能是相似的：從2000年起，只有三分之一作品的發行帶有時間或經濟上的可預言性。1我知道這些觀察在使用工程理念來制造飛機、橋梁、心臟移植管、核反應堆、摩天大樓以及衛星的項目管理者看來是不入流的（除非這些工程項目包括重要的軟件內容或是空前的，史無前例的系統）。
好的，有人可能會說，軟件只是一個未成熟的工程分支，在我的職業生涯中，大約每五年軟件項目的底層技術就要翻新一次。這些翻新包括語言、結構模式、應用、用戶界面、計算平臺、網絡、環境、過程以及工具。這種快速持續的進化將要放慢了嗎？目前還看不出這種跡象。人類想象力和市場作用仍是非常強大的。
就像電影工業，我們需要有資格的建筑師（導演）、分析家（編劇、設計師）、軟件工程師（產品工作人員、編輯、特技制造者、演員替身）以及項目管理者（制片人）。還是和電影工業一樣，我們必須使軟件成為可執行形式（弄到膠片上）來切實進行進度和質量的評估。在我們發現什么可用什么不可用的過程中會產生大量的碎片和重復工作，然后我們把很多人的貢獻集成為一個緊密集成的知識產權作品。
我所認識到的是，軟件管理應被更精確地描述為軟件經濟的一個分支，而不是軟件工程。軟件管理者每天的決定（正如電影制作人每天的決定），主要是由價值判斷、成本權衡、人為因素、宏觀經濟趨勢、技術趨勢、市場強度以及時機控制的。軟件項目很少注重于精確的數學、物質屬性、物理定律或是其他已經建立的成熟的工程原則。
我希望這一對軟件-電影的對比刺激了你的神經，使你想繼續讀下去。如果想了解更詳細的對比請參考 Paul Graham 的論文。2下文著重介紹的是一些從軟件項目中獲得的斷言，這些項目包括了我在25年多的時間里在軟件項目管理領域跟從、領導、實踐、指導的少數成功軟件項目和大量不成功軟件項目。
迭代的方法
造成軟件集中型項目的低成功率的原因之一是傳統的項目管理方法不鼓勵進行指導和調整以緩解以下問題的不確定性：
問題域（用戶究竟想要或者需要什么）
解決域（何種結構和技術的組合是最適用的）
計劃域（成本和時間制約、團隊組成和生產力、涉眾交流、遞增結果序列等等）
我們需要一種更為動態和具有適應性的方法來思考軟件進程和質量管理的問題，這種方法應當適應成功項目的模式。當今的現代軟件管理方法3-5 通常被稱為迭代 開發方法。在現今充滿不確定性的軟件應用程序、產品和服務開發的雷區中，迭代方法指導了軟件項目，而不是遵循一個精確的、長期的計劃。按時間和預算計劃成功發布軟件產品需要一種發現、生產、評估和指導性領導方式的進步的混合�！爸笇А币辉~意味著積極的管理參與，經常的過程矯正以產生更好的結果。所有涉眾應該通力合作，集中實現不斷前進的目標。
作為一個被廣泛接受的現代迭代開發過程，IBM Rational Unified Process，6 為一個更為平衡的發展提供了一個框架，這一發展是鼓勵對不確定性和風險進行管理的。它的生命周期包括四個階段，每個階段都有可演示的結果：
1.起始：遠景和商業案例的定義和原型設計
2.細化：對架構基線進行集成、論證和評估
3.構建：對有用的增量進行開發、論證和評估
4.產品化：可用性評估、最終產品以及發行
階段的名稱表現了項目的狀態，而不是從需求到設計到編碼到測試到發行的基于順序性活動的項目進展。
我們把這一迭代管理方式稱為基于結果的，而不是基于活動的。在軟件世界中，真正的結果是可執行程序。其他的任何東西（需求文檔、用例模型、設計模型、測試用例、計劃、過程、文檔、檢查）都是次要的，而且只是實現目標——一個可執行的軟件程序——的手段的一部分�；叵肽阕�程序員的日子：當你在建立一個模型、畫流程圖草圖、推理一個狀態機的邏輯或是寫源代碼的時候，你知道你只是在思考和集成一個抽象方案。只有當你編譯、鏈接和執行時方案才變得切實可行。項目管理者應該有同樣的感覺。當你評估一個計劃、模型、文檔或一些其他不可執行的表現物的美好和出色之處時，你只是在推測項目質量和進度。電影制作人對劇本、情節串連板、背景設置以及服裝設計的感覺也是如此。他們著力于影片的每一個鏡頭，使得電影成為可以判斷總體集成效果的實體。
精確度與準確度
在一個成功的軟件項目中，每一個開發階段都加深了對發展計劃、規格說明和完整解決方案的理解，因為每一個階段都延伸了可執行序列和團隊對競爭目標的認識。在生命周期中的任意一點，次要工件的精確性應與這種理解相平衡，在詳細程度上保持一致，相互之間保持一定程度的可追蹤性。
精確度與準確度之間的區別（在軟件管理的上下文中）并不是它們看起來那樣小。軟件管理充滿灰色的區域、情景依賴性以及不明確的折衷。對優秀的軟件管理者來說，理解精確性與準確性之間的區別是一種基本技能，因為他們必須準確地對投資、風險以及變化帶來的影響進行預測。未被證實的精確度——在需求或是計劃內的——實際上是造成阻礙成功的潛在而微妙的因素。大多數時候，早期的精確性是不誠實的，造成了有比實際上更多的進展和更高的質量的假象。不幸的是，很多項目發起者和涉眾要求這種早期精確性和詳細性，因為這給了他們對已經取得的進展的（虛假的）安慰。
我在軟件工業中所見的最常見的失敗模式之一是開發有五位數精度的規格說明，而涉眾其實對問題、方案或者計劃只有一位數精度的理解。延長建立一個精確的需求理解或詳細的計劃的時間實際上耽誤了對架構上更重要的問題的理解。你曾經做過、修改過、痛苦地回顧過多少厚度嚇人的需求文檔或是詳細的管理計劃呢？而幾個月后當項目取得了有實際意義的可演示的進展，加快了涉眾對實際的權衡的理解時，你又要全部重新檢查這些文檔和計劃了。這種普遍現象在我們的行業里被稱為刨光廢物。
一些成功的指導模式
迭代過程大多是由解決不確定性和管理軟件風險的需要而發展的。這里的指導需要動態控制以及中間的檢查點，這樣涉眾就可以評估到目前為止完成了哪些工作，應該對目標作出什么修改，以及如何重新分配他們的工作以使目標按照最為經濟的方式組合。我曾觀察到成功的軟件集中型項目典型的四種模式。這些模式表現了一些“抽象規格”，對指導評估、范圍管理、過程控制、進展和質量控制有所幫助。我有預感，多數在項目管理中“被鑒定過的”項目管理者對此都會作出消極的反應，因為這些理念在一定程度上是與傳統相悖的。
范圍管理：方案從用戶具體的要求發展而來，而用戶的具體要求從候選方案發展而來。與從開始就確定所有需求不同。
過程控制：過程和工具的使用從輕到重漸變。與把整個項目的生存周期過程定義為輕或重不同。
進展：健康的項目展示出一個進展和背離的序列。與按照預期計劃100%實現價值，沒有明顯的背離不同。
質量控制：測試可演示的發布版本是一個頭等重要的、貫穿全生命周期的活動。與認為它是次要的，生命周期晚期的活動的觀點不同。
我承認在實際軟件項目中，上述四點都是說起來容易做起來難，而且對不同領域它們應該被不同地應用。網絡應用程序開發團隊與嵌入式應用程序開發團隊實現這些模式的方法應該是不同的，但是對他們來說模式都是可用的。方法、模式和技術的書籍和論文的寫作，（工業界稱為思想領導），是相對簡單的。盡管如此，我們中的多數人并不是在尋找最好的思想，而是在尋找最好的實踐方法。管理實際項目需要實踐的領導力，而在實際項目條件下應用和執行這些理念是相對困難的。我們應當珍惜懂得實踐的領導力的項目管理者：他們可能是每個公司中最稀有的資源。優秀的項目管理者，就像優秀的電影制作人一樣，不只是常常創造出優秀的產品，他們還是年輕團隊成員的良師益友，這些年輕人能夠學習有效的技術并發展他們自己在多維權衡、持續性溝通、風險管理、模式識別以及指導式領導等方面的技能。項目管理訓練課程是學習的良好催化劑，但是學徒期是不可或缺的。
范圍管理
傳統軟件過程的比較微妙的挑戰之一是如何把生存周期表現為一系列順序的活動：從需求分析到設計，編碼，測試，最后發行。成功的項目確實用一種抽象的方式實現了這種進展路線，但是活動之間的界限是模糊不清的，只能被合作的涉眾所接受。另一方面，不成功的項目則陷入了掙扎著尋找活動間清晰的界限的誤區。比如，在過渡到設計前追求100%固定的需求基線，或是在過渡到編碼前追求非常詳細的設計文檔，都是嚴格的中間目標，造成了注意力被瑣碎細節所分散，而重要工程決定的進展卻被放緩甚至停止。
當我們建立一個全新的軟件方案時，從需求到設計的連續的詳細規格說明流也許是有一定意義的。但是現在，我們通常是升級一個已有系統或者根據已有部件（操作系統、網絡服務、網絡、圖形用戶界面、數據管理、封裝的應用程序、中間件、計算平臺、遺留系統等）建立新的系統。改造或復用已有財產的經濟效益迫使我們考慮在這些已有財產的環境和限制下的用戶具體需要。
我前面曾經說過，需求可能是我們的工業中被最嚴重誤用的詞。需求意味著不可協商，但我們卻在幾乎所有成功項目中看到需求的變化，妥協和讓步。改變一個需求需要進行大量嚴格的審查，因為這通常對涉眾間的合同有很大影響。我建議我們使用規格說明來代替需求。規格說明是可以更改的，而且可以理解為我們現階段對項目的認識狀態。
就我所見過的而言，用戶規格說明有兩種重要形式。第一種是觀點陳述（或用戶需要），它抓住了開發團隊和買方或說用戶之間的合同。這些信息應以用戶可理解的形式（一種包括了文本、原型、用例，電子表格等等的特殊格式）表現。一個支持觀點陳述的用例模型起到了用戶或買方可以理解的語言表達可操作的概念以及期望的行為的作用。
規格說明的第二種形式與需求非常不同。我傾向于使用評估標準這種說法，它被自然理解為目標的瞬間快照，而目標是一個生存周期的中間檢查點，比如一個可演示的版本發布。評估標準是從觀點陳述或者其他資源（制作/購買/復用分析、風險管理相關、架構方面的考慮、隱藏問題、實現限制、質量極限等等）中派生出來的中間的指導目標。它們與用例模型一起，為早期測試，而不是為傳統的需求表達提供了更好的框架。一個計劃的發布內容序列和計劃的評估標準的初始提議就是一個風險管理計劃的很好的形式。
過程嚴格性
多年來，我一直嘗試著調解敏捷陣營（軟件過程觀點的自由主義左翼）和過程成熟陣營（軟件過程觀點的保守派右翼）之間狂熱的爭論。他們都有有益的觀點和適當的技術。但是經過最老于世故的努力，在需要解決方案的范圍內沒有清晰的正確或者錯誤的處方。上下文環境是極為重要的，而且幾乎所有不是太過普通的項目和組織都需要結合技術、常識、領域內的經驗來取得成功。多數項目管理者會同意下述觀點：
在我看來，最后一個觀點描述了決定敏捷方法的速度和自由度，嚴格方法的質量和說明性指導的決定性因素。過程嚴格性應該與重力作用很相似：你越接近產品的發布，過程、工具、員工每天的活動使用儀器的影響就越大。你離發布日期越遠，這種影響就越小。這個公理在過程里似乎完全被忽略了，或者至少是不受重視的，但是它在成功的軟件項目中通常是非常引人注目的。
大多數成功的軟件開發過程的一個標志性特征是詳細定義的從創造階段（初始和細化）到生產階段（構建和產品化）的過渡過程。當軟件項目無法成功時，一個主要的原因是對過程嚴格性不合適的強調（過多或者過少）。這種現象在傳統過程和迭代過程中都是存在的。多數不成功的項目帶有下列特征之一：
生存周期早期階段（創造性方面）的過度設計。你需要有機動性的過程，該過程容易適應新發現、適應對幾個主要風險和原型方案造成攻擊的一定程度上的不確定性，并且建立早期的粗糙工件。你能想到哪些創造性原則，根據這些原則過程嚴格性對幫助人類思考被認為是有益的？
生存周期晚期階段（生產方面）的設計不足。詳細工件的廣泛的變化管理基線需要帶有富有洞察力的實現方法，對連貫性的密切關注，以及自始至終對產品質量聚焦的工程過程。
成功的現代項目——以及使用傳統過程開發的成功項目——通常都有詳細定義的項目階段性標志，即從創造性研究狀態到生產狀態的顯著過渡。早期階段著重于實現可演示的功能。后期階段著重于實現可供用戶使用的產品，這種產品關注的是健壯性、性能、適用性以及完整性。
另一個重要方面是從創造性世界到生產世界的過渡對整個團隊的影響。結構良好的團隊通常不喜歡嚴格的過程、細節以及不成熟的精確性。生產能力強的團隊通常會對松散的、不固定的、粗糙的結果感到不愉快。項目管理者需要管理各種團隊的平衡性，這樣技術上領導的重力中心就可以在整個生存周期發展進化，從初始階段的管理團隊，到細化階段的架構團隊，到建構階段的開發團隊，再到過渡階段的測試/評估團隊。軟件項目管理中人的因素被低估了，而且團隊動態性的主題值得被給予比今天大多數項目管理課程所給予的更多的關注。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/