《五項核心度量》第三章節選。
第一階段：初始
很好理解，在花費幾百萬美元之前，被提議的系統在技術上是可行的，並且有一個相關的業務實例。最初，你所擁有的只是一個大幅揮手的高級主管在說“不能將我們所有操作極好地結合到一個獨立系統中去嗎？”，你無法估計時間和努力。對於所需軟件的規模，你沒有足夠的信息去做即使是粗略的估計。
首先你需要做三個準備工作：你必須將雄偉的想象分解成足夠具體去研究的部分；你必須弄清楚什麼是系統之內的，什麼是系統之外的；你必須判斷你的組織是否能生產出你粗略勾畫過的系統。
在當前的技術條件下，系統在技術上可行嗎？這個問題看起來發生在類似國防部、美國聯邦航空局，以及其他善意的非技術型領導們做着產品速成夢的地方。這個問題也發生在新的領域，或稱爲“新生領域”，這些領域我們尚未完成過一個項目。在更多普通的領域裏，許多應用軟件的可行性是十分可靠的。只要認識到項目隨後就能完成，或者開發者以前在這個應用領域工作過，那就已經足夠了。那些經驗讓我們感到放心，因爲這工作至少是切實可行的。
但是，即使一項提案在技術上是可行的，它也不一定適合此刻我們特定的組織者。我們可能缺乏這個項目必要的技能。我們的組織可能無法調動所需的資金。產品也許不能和我們公司的核心能力協調一致。我們將在第九章更深入地研究如此這類的問題。這裏，圖3-1說明了第一階段在項目準備工作開始時的位置。
在第一階段得出的幾個關鍵結果可能會被放在可靠性度量的次要位置。即使是本階段可能作出的對系統規模的粗略估計，也需要根據已有系統規模的相關信息做出。而據此得出的關於構造時間、努力和成本的極其粗略的估計，也包含了如何將規模度量轉變成這種極其粗略的評估的知識。
第二階段：細化
爲了使標價合乎業務基礎，你需要進一步增加對這個項目的瞭解。你需要相當精確地考慮你將要去做的事情。這就是細化階段的目的。該階段有三個目標：
 把需求擴展至能夠設計出絕大多數架構的程度。
 設計出絕大多數架構。
 識別出風險，如果不能減輕，則確定其可能導致的額外成本。
在允許繼續進行架構設計之前，你必須很好地掌握關鍵需求。你所建立架構的基礎正是這些需求。你不必掌握在這個階段所有的細節需求。在熟悉的領域，用它可能足以設計出一些大家知道的子系統。在不太熟悉的領域，你可能需要將架構轉化爲一個較低級別的結構。
對於架構的某些部分，是否會有因爲理解不深刻，以致不能根據實施所需的時間和努力來估計它是否正向制定方向前進的情況呢？如果有，就必須對這些部分進行深入的探索。例如，爲了保證其完成，你可能必須找到某種算法，或者甚至是親自編寫一個。爲了完成項目的這一部分，你可能不得不通過完整的需求獲取、分析、設計、實現、測試一個工作原型，來確定它不僅能夠完成，而且能夠在商業約束下完成。當然，商業約束也是某種類型的度量。
你的評估在什麼時候可以算是足夠好了呢？在第二階段，你找出的關於將要實現系統的內容越多，你的規模評估將會越準確。你相應的時間和努力評估也會變得更精確。你爲項目的架構、設計和風險縮減引入了兩個標準：首先，它應該處於相關業務領域中通常的偏差範圍之內；其次，它有成功完成的可能性。需要注意的是這兩個標準都是基於度量法的。
過程進展到第二階段，規模估計應該足以用於給出一個標價，但問題還沒有完成。在管理者、客戶和市場的壓力下，這一階段通常在進展到可以給出一個報價之後，就被過早地結束了。當然，對於那些在度量法方面的背景知識很少的組織，其所作的估價和由於系統知識的缺乏而做出的估價沒有太大的不同。總之，他們僅僅是在猜想。對於那些使用度量法的組織，經過這一階段的中途規模評估之後，還有一個很大的誤差幅度。在這點上的時間和努力評估，還存在着相對較大的不確定性。評價這些數字導致了我們在第三階段常見的所有問題，即在構造階段時，時間和努力超出限度、質量低劣、甚至是取消項目。
相比於度量法而言，如果標價建立在決策者直覺的基礎上，那麼第二階段無論在哪裏結束都大同小異。對於那些使用了更好的評估技術和了解怎樣去得出更精確的度量的組織，更重要的是在第二階段進展到能夠進行正確的規模評估。
你也許會覺得這聽起來有點道理。然後，進一步你會問，“誰將爲這提前的預備工作提供經費呢？”商業單位有時希望考慮將成本轉移給一些其他的商業單位。在公司之間，請求報價的一方會認爲它需要承擔的成本應該轉移給軟件承包方。同樣地，在一個公司內部，需要軟件的部門有時會試圖將規劃軟件的成本轉移給軟件開發者。如果這些微乎其微的“成就”帶來了對第二階段的忽視，最後遭受劣質軟件苦果的將是使用軟件的公司或部門。因此，無論誰爲第二階段提供了資金，使用軟件的組織需要確保資金，以能夠達到成功完成第三階段——構造時所需時間和努力的資金需求的目的。
爲了達到上述目標而對第二階段的延長，有可能會推遲構造的開始。從心理學角度來說，這種延期很難被接受。我們都希望看到構造在進行中。人們希望計算完成的代碼行。然而，當構造過早開始時，開發者將可能在不充分的估價下開展工作，也就意味着是在不充分的人員配置下的過短的時間內開展工作。那樣無論在商業立場還是技術立場來說都是不好的。在構造中途，開發者意識到架構不能完全滿足需求，這一十足的風險擾亂了時間進度，同時，所需的修改將會比正常情況下花費更多的費用。
降低這類問題的一個方法是保持項目邊界範圍的長度。不要試圖提出一個五年或十年計劃就能永遠解決你的所有問題。太多的因素，如需求、環境、可複用的組件、硬件以及操作系統平臺等，在跨越這麼長的時期內必然會改變。相反，試着去建立一個你可以在其中設立很多短期計劃的靈活的架構。你也許可以控制在兩年時間範圍內的大多數計劃。其訣竅是在設計架構時，考慮其擴展性能夠達到後續的發佈和產品生產。
在第二階段細化中，度量系統甚至比第一階段更加嚴格。在這個階段，根據定義，需要議定一個商業標價。標價是指導項目通過構造和遷移的最重要的度量。但標價不能就象宙斯頭頂的閃電那樣憑空而降。更正確地說，它通過更少的度量，比如規模、生產力水平和可靠性來建立。
第三階段：構造
就如我們在本章開始時提到的那樣，人們解決問題；而不是度量法在解決問題。然而，度量法能夠幫助人解決問題。隨着時間的過去，必然會有足夠多的人，以及一個通過人時或人月來衡量的被稱爲努力的度量。必然會有足夠長的時間，也就是另一個度量——時間進度，用周、月、年來衡量。此外，軟件用戶通常要求人們充分地解決問題——或許我們可以用一個不正式的名稱“質量”來稱呼這種要求。質量有很多方面，有些不能很容易地簡化爲一個數字。而可靠性是可以計量的，也反映了質量的其他方面的範圍。可靠性以缺陷比例（或者它的倒數，指缺陷的次數）的表現方式成爲第三個關鍵度量。
因此，商業投標暗含的時間和努力度量，提供給問題解決人員在第三階段所需要的用來構造可接受的可靠性和質量的時間和努力。於是，度量是第三階段成功的重要關鍵。
另外，度量在構造階段扮演了第二個角色——控制。這是一個不那麼討人喜歡的詞，因爲沒有人喜歡被控制。我們大家都願意無拘無束的！但是記住，我們生活在一個資源有限的世界上，而控制是使我們在這些制約下安全生存的保證。
確定最初的關於努力（人月）、時間進度、以及第二階段結束時的缺陷的評估度量，我們可以預測在構造階段中需要消耗的努力比例和被發現缺陷的比例。我們也可以預測功能——比如代碼行即將完成的比例。除了預測這些度量發生的平均比例之外，我們還可以預測超出或低於平均的波動範圍。
我們現在已經設立了構造階段關鍵變量的“統計控制”的標準。統計控制的意思是我們將職員的實際數量、實際生產的代碼行數和每週發現的缺陷的實際數量加起來，看這些實際數字是否符合統計控制的範圍。如果是，項目正在照計劃執行；如果實際數超出了控制範圍，它也就失去了控制，沒有按計劃執行，這可能是因爲出了什麼差錯，它是尋找問題的一個信號。
在統計控制之下，每週我們都能在問題發生時發現它們。它們是最新的問題。涉及到的人還在附近。傳統方式在系統測試中發現這類問題。在那個時候，項目進度只剩下很少的時間。一些人員已經離開，而其他人不再清晰地記得他們所做的，因爲可能過去幾個月之後才發現結果出了錯。
構造階段是軟件開發的大部分工作完成的地方，也是費用最大的階段。在這個階段度量的重要性有兩個理由：爲任務提供足夠的資源和時間，以及確保資源按計劃利用。
不妨遐想一下空中飛行，在雲層中，你的直覺是靠不住的。飛行教員教導我們“依靠你的儀器，而不是你的直覺。”我們也可以類似地說：“依靠度量法，而不是你的希望和擔心。”
第四階段：遷移
構造階段在內部系統測試管理中結束，獲得了一個被稱爲初始運行性能的系統狀態。然而，系統還不能在使用者或客戶的環境下運行。那是遷移階段的事。這一階段指導產品在用戶的環境下運行，那可能會與內部環境有細微的差別。
從廣義上講，有兩種類型的產品：一種是簡易包裝的產品，定位在大多數客戶。開始時，賣主會選擇有用戶代表進行Beta測試（通常是在構造階段的結束）。另一種產品是針對一位客戶，經常是安裝在一個確定的位置，有時是幾個位置。客戶通常會在自己的環境下進行一個驗收測試。
在通常條件下，會有兩種類型的反饋從用戶環境中產生：
 缺陷出現，既可能是由於新的環境也可能因爲在內部測試中未能發現。軟件組織不得不將其糾正。在有些情況下，它們有可能會保持到下一次發佈。
 軟件有可能未能滿足用戶現在驗收的要求。再次，軟件組織也許能夠更改系統使之適應這些要求，至少那些它能夠在當前架構中迅速地添加的。在其他情況下，更改將加到第二次發佈的考慮列表中。
遷移階段需要的努力和時間總量取決於用戶遇到的新需求和缺陷的程度。如果需求在早先階段謹慎獲取，如果在分析和設計期間就找用戶商議，如果用戶嚴格使用操作原型，如果他們在構造階段早期檢查工作的增量，並且如果這種導致最初的需求改變以適應要求的早期反饋能在中途發現，那麼會有較少的需求在遷移階段發生。最多的是，不管怎樣，軟件組織發現去評估從用戶那裏反饋回來的修改數量是困難的。保留在項目初期發生的記錄可以作爲一種建議。
如果一個項目伴有良好的審查和測試實踐，系統能夠達到最初的運行水平，遺留很少缺陷。無論如何，現在已有了一些評估缺陷數量的度量方法。然後，當用戶在自己的環境中運行系統時，他們會逐漸地發現缺陷。用戶或是系統實施人員，糾正缺陷並且修正仍然保留的評估數據。運用這個辦法，就有可能在缺陷發現過程中做出一個對預期修復工作總量的粗略估計。
總而言之，不管怎樣，核心度量——規模、努力、時間、生產力和缺陷率——在遷移階段的應用要少於前面的幾個階段。以往的項目在這一階段的經驗是最好的指南。在這個基礎上，軟件組織能夠定量地分配時間和努力量。這就能夠在如此的預算下做出修正或缺陷修復，而在下一次發佈或維護預算中更嚴格修改就能爭取更多的時間。
第一階段：初始
很好理解，在花費幾百萬美元之前，被提議的系統在技術上是可行的，並且有一個相關的業務實例。最初，你所擁有的只是一個大幅揮手的高級主管在說“不能將我們所有操作極好地結合到一個獨立系統中去嗎？”，你無法估計時間和努力。對於所需軟件的規模，你沒有足夠的信息去做即使是粗略的估計。
首先你需要做三個準備工作：你必須將雄偉的想象分解成足夠具體去研究的部分；你必須弄清楚什麼是系統之內的，什麼是系統之外的；你必須判斷你的組織是否能生產出你粗略勾畫過的系統。
在當前的技術條件下，系統在技術上可行嗎？這個問題看起來發生在類似國防部、美國聯邦航空局，以及其他善意的非技術型領導們做着產品速成夢的地方。這個問題也發生在新的領域，或稱爲“新生領域”，這些領域我們尚未完成過一個項目。在更多普通的領域裏，許多應用軟件的可行性是十分可靠的。只要認識到項目隨後就能完成，或者開發者以前在這個應用領域工作過，那就已經足夠了。那些經驗讓我們感到放心，因爲這工作至少是切實可行的。
但是，即使一項提案在技術上是可行的，它也不一定適合此刻我們特定的組織者。我們可能缺乏這個項目必要的技能。我們的組織可能無法調動所需的資金。產品也許不能和我們公司的核心能力協調一致。我們將在第九章更深入地研究如此這類的問題。這裏，圖3-1說明了第一階段在項目準備工作開始時的位置。
在第一階段得出的幾個關鍵結果可能會被放在可靠性度量的次要位置。即使是本階段可能作出的對系統規模的粗略估計，也需要根據已有系統規模的相關信息做出。而據此得出的關於構造時間、努力和成本的極其粗略的估計，也包含了如何將規模度量轉變成這種極其粗略的評估的知識。
第二階段：細化
爲了使標價合乎業務基礎，你需要進一步增加對這個項目的瞭解。你需要相當精確地考慮你將要去做的事情。這就是細化階段的目的。該階段有三個目標：
 把需求擴展至能夠設計出絕大多數架構的程度。
 設計出絕大多數架構。
 識別出風險，如果不能減輕，則確定其可能導致的額外成本。
在允許繼續進行架構設計之前，你必須很好地掌握關鍵需求。你所建立架構的基礎正是這些需求。你不必掌握在這個階段所有的細節需求。在熟悉的領域，用它可能足以設計出一些大家知道的子系統。在不太熟悉的領域，你可能需要將架構轉化爲一個較低級別的結構。
對於架構的某些部分，是否會有因爲理解不深刻，以致不能根據實施所需的時間和努力來估計它是否正向制定方向前進的情況呢？如果有，就必須對這些部分進行深入的探索。例如，爲了保證其完成，你可能必須找到某種算法，或者甚至是親自編寫一個。爲了完成項目的這一部分，你可能不得不通過完整的需求獲取、分析、設計、實現、測試一個工作原型，來確定它不僅能夠完成，而且能夠在商業約束下完成。當然，商業約束也是某種類型的度量。
你的評估在什麼時候可以算是足夠好了呢？在第二階段，你找出的關於將要實現系統的內容越多，你的規模評估將會越準確。你相應的時間和努力評估也會變得更精確。你爲項目的架構、設計和風險縮減引入了兩個標準：首先，它應該處於相關業務領域中通常的偏差範圍之內；其次，它有成功完成的可能性。需要注意的是這兩個標準都是基於度量法的。
過程進展到第二階段，規模估計應該足以用於給出一個標價，但問題還沒有完成。在管理者、客戶和市場的壓力下，這一階段通常在進展到可以給出一個報價之後，就被過早地結束了。當然，對於那些在度量法方面的背景知識很少的組織，其所作的估價和由於系統知識的缺乏而做出的估價沒有太大的不同。總之，他們僅僅是在猜想。對於那些使用度量法的組織，經過這一階段的中途規模評估之後，還有一個很大的誤差幅度。在這點上的時間和努力評估，還存在着相對較大的不確定性。評價這些數字導致了我們在第三階段常見的所有問題，即在構造階段時，時間和努力超出限度、質量低劣、甚至是取消項目。
相比於度量法而言，如果標價建立在決策者直覺的基礎上，那麼第二階段無論在哪裏結束都大同小異。對於那些使用了更好的評估技術和了解怎樣去得出更精確的度量的組織，更重要的是在第二階段進展到能夠進行正確的規模評估。
你也許會覺得這聽起來有點道理。然後，進一步你會問，“誰將爲這提前的預備工作提供經費呢？”商業單位有時希望考慮將成本轉移給一些其他的商業單位。在公司之間，請求報價的一方會認爲它需要承擔的成本應該轉移給軟件承包方。同樣地，在一個公司內部，需要軟件的部門有時會試圖將規劃軟件的成本轉移給軟件開發者。如果這些微乎其微的“成就”帶來了對第二階段的忽視，最後遭受劣質軟件苦果的將是使用軟件的公司或部門。因此，無論誰爲第二階段提供了資金，使用軟件的組織需要確保資金，以能夠達到成功完成第三階段——構造時所需時間和努力的資金需求的目的。
爲了達到上述目標而對第二階段的延長，有可能會推遲構造的開始。從心理學角度來說，這種延期很難被接受。我們都希望看到構造在進行中。人們希望計算完成的代碼行。然而，當構造過早開始時，開發者將可能在不充分的估價下開展工作，也就意味着是在不充分的人員配置下的過短的時間內開展工作。那樣無論在商業立場還是技術立場來說都是不好的。在構造中途，開發者意識到架構不能完全滿足需求，這一十足的風險擾亂了時間進度，同時，所需的修改將會比正常情況下花費更多的費用。
降低這類問題的一個方法是保持項目邊界範圍的長度。不要試圖提出一個五年或十年計劃就能永遠解決你的所有問題。太多的因素，如需求、環境、可複用的組件、硬件以及操作系統平臺等，在跨越這麼長的時期內必然會改變。相反，試着去建立一個你可以在其中設立很多短期計劃的靈活的架構。你也許可以控制在兩年時間範圍內的大多數計劃。其訣竅是在設計架構時，考慮其擴展性能夠達到後續的發佈和產品生產。
在第二階段細化中，度量系統甚至比第一階段更加嚴格。在這個階段，根據定義，需要議定一個商業標價。標價是指導項目通過構造和遷移的最重要的度量。但標價不能就象宙斯頭頂的閃電那樣憑空而降。更正確地說，它通過更少的度量，比如規模、生產力水平和可靠性來建立。
第三階段：構造
就如我們在本章開始時提到的那樣，人們解決問題；而不是度量法在解決問題。然而，度量法能夠幫助人解決問題。隨着時間的過去，必然會有足夠多的人，以及一個通過人時或人月來衡量的被稱爲努力的度量。必然會有足夠長的時間，也就是另一個度量——時間進度，用周、月、年來衡量。此外，軟件用戶通常要求人們充分地解決問題——或許我們可以用一個不正式的名稱“質量”來稱呼這種要求。質量有很多方面，有些不能很容易地簡化爲一個數字。而可靠性是可以計量的，也反映了質量的其他方面的範圍。可靠性以缺陷比例（或者它的倒數，指缺陷的次數）的表現方式成爲第三個關鍵度量。
因此，商業投標暗含的時間和努力度量，提供給問題解決人員在第三階段所需要的用來構造可接受的可靠性和質量的時間和努力。於是，度量是第三階段成功的重要關鍵。
另外，度量在構造階段扮演了第二個角色——控制。這是一個不那麼討人喜歡的詞，因爲沒有人喜歡被控制。我們大家都願意無拘無束的！但是記住，我們生活在一個資源有限的世界上，而控制是使我們在這些制約下安全生存的保證。
確定最初的關於努力（人月）、時間進度、以及第二階段結束時的缺陷的評估度量，我們可以預測在構造階段中需要消耗的努力比例和被發現缺陷的比例。我們也可以預測功能——比如代碼行即將完成的比例。除了預測這些度量發生的平均比例之外，我們還可以預測超出或低於平均的波動範圍。
我們現在已經設立了構造階段關鍵變量的“統計控制”的標準。統計控制的意思是我們將職員的實際數量、實際生產的代碼行數和每週發現的缺陷的實際數量加起來，看這些實際數字是否符合統計控制的範圍。如果是，項目正在照計劃執行；如果實際數超出了控制範圍，它也就失去了控制，沒有按計劃執行，這可能是因爲出了什麼差錯，它是尋找問題的一個信號。
在統計控制之下，每週我們都能在問題發生時發現它們。它們是最新的問題。涉及到的人還在附近。傳統方式在系統測試中發現這類問題。在那個時候，項目進度只剩下很少的時間。一些人員已經離開，而其他人不再清晰地記得他們所做的，因爲可能過去幾個月之後才發現結果出了錯。
構造階段是軟件開發的大部分工作完成的地方，也是費用最大的階段。在這個階段度量的重要性有兩個理由：爲任務提供足夠的資源和時間，以及確保資源按計劃利用。
不妨遐想一下空中飛行，在雲層中，你的直覺是靠不住的。飛行教員教導我們“依靠你的儀器，而不是你的直覺。”我們也可以類似地說：“依靠度量法，而不是你的希望和擔心。”
第四階段：遷移
構造階段在內部系統測試管理中結束，獲得了一個被稱爲初始運行性能的系統狀態。然而，系統還不能在使用者或客戶的環境下運行。那是遷移階段的事。這一階段指導產品在用戶的環境下運行，那可能會與內部環境有細微的差別。
從廣義上講，有兩種類型的產品：一種是簡易包裝的產品，定位在大多數客戶。開始時，賣主會選擇有用戶代表進行Beta測試（通常是在構造階段的結束）。另一種產品是針對一位客戶，經常是安裝在一個確定的位置，有時是幾個位置。客戶通常會在自己的環境下進行一個驗收測試。
在通常條件下，會有兩種類型的反饋從用戶環境中產生：
 缺陷出現，既可能是由於新的環境也可能因爲在內部測試中未能發現。軟件組織不得不將其糾正。在有些情況下，它們有可能會保持到下一次發佈。
 軟件有可能未能滿足用戶現在驗收的要求。再次，軟件組織也許能夠更改系統使之適應這些要求，至少那些它能夠在當前架構中迅速地添加的。在其他情況下，更改將加到第二次發佈的考慮列表中。
遷移階段需要的努力和時間總量取決於用戶遇到的新需求和缺陷的程度。如果需求在早先階段謹慎獲取，如果在分析和設計期間就找用戶商議，如果用戶嚴格使用操作原型，如果他們在構造階段早期檢查工作的增量，並且如果這種導致最初的需求改變以適應要求的早期反饋能在中途發現，那麼會有較少的需求在遷移階段發生。最多的是，不管怎樣，軟件組織發現去評估從用戶那裏反饋回來的修改數量是困難的。保留在項目初期發生的記錄可以作爲一種建議。
如果一個項目伴有良好的審查和測試實踐，系統能夠達到最初的運行水平，遺留很少缺陷。無論如何，現在已有了一些評估缺陷數量的度量方法。然後，當用戶在自己的環境中運行系統時，他們會逐漸地發現缺陷。用戶或是系統實施人員，糾正缺陷並且修正仍然保留的評估數據。運用這個辦法，就有可能在缺陷發現過程中做出一個對預期修復工作總量的粗略估計。
總而言之，不管怎樣，核心度量——規模、努力、時間、生產力和缺陷率——在遷移階段的應用要少於前面的幾個階段。以往的項目在這一階段的經驗是最好的指南。在這個基礎上，軟件組織能夠定量地分配時間和努力量。這就能夠在如此的預算下做出修正或缺陷修復，而在下一次發佈或維護預算中更嚴格修改就能爭取更多的時間。
