2.3 計劃是什么樣

所有的計劃都有一個根本原則：三分法。這只是一種極端粗略的估計，類似于“信封背面計算法”，但這可以說是理解明白計劃最簡單的方法。如果你經歷過作計劃，并且正要退縮的話，我力圖使整個過程簡單化。我要提供一個最簡單的立足點，用來討論什么容易出錯，為什么會發生，以及怎樣解決。

這里是一個用來計劃工作的極端簡化的模型：對于任何項目，將可以利用的時間分成三份，一份用來設計，一份用來實現，一份用來檢驗。根據你使用的方法論的不同，這些階段也有不同的叫法，也許它們在某些方法上互相有交迭，但所有的方法論都有負責這三種活動的時間段。任何一天，你不是在弄清楚要做什么（設計），就是在實際做事情（實現生產代碼），要不就是核實，分析，優化已經做好的結果（檢驗）。

2.3.1 應用三分法

按照一般性原則推論，你每計劃一天的時間寫代碼，就應該花費一天時間搞計劃和設計，還有一天時間測試和優化結果（參見圖 2-1）。這樣可以很容易的檢查任何已經存在的項目或者從頭開始一個新的項目。如果總的時間沒有被大概的分成這樣的三等份，就應該有一些可理解的原因，說明為什么這個項目需要的工作劃分是不平均的。只要是經過了考慮，在測試上比在實現上多花20%的時間也是合理的。

圖 2-1. 項目計劃三分法

設想一個虛構的網絡項目：如果你有6周的時間來開發它，第一步，你要把時間大致分成三份，然后根據劃分，計算出工作完成的時間。如果在較高的預期水準上，還不能提供足夠的時間來完成任務，那就是出現了某些根本性的錯誤了。不是改變計劃，就是要減少預期要完成的工作數量（或者降低質量要求）。肖建削減設計或檢驗時間只會增加寫代碼被誤導或者代碼難以管理維護的幾率。 三分法對于揭示項目的零和性質很有用。添加一個新特性需要不止一個程序員來完成；設計和檢驗的花費是無法避免的。當計劃變動，這是因為有一些隱藏的或者忽略的花費沒有被統計到。

2.3.1.1 漸進開發（反項目的項目）

出于完整性，考慮一個最簡單的情況是很有意義的,那就是沒有項目的情況。所有的工作都是基于要求的出現漸進的被完成，它們的評估基于其他工作，然后被投入到計劃的下一個空隙中。有些開發組，網站開發人員，或者IT程序部門都是這樣工作的。這些組織很少對大的增量進行投入和承諾。敏捷方法（稍候討論）經常被推薦給這樣的團隊作為組織工作最適宜的體系，因為這些方法都強調適應性，簡潔性，和對變化的可預見性。如果你同時被分配了幾個任務，你就要從本書以項目為中心的例子中自己進行推理了。

三分法仍然適用于這些情況。即使是每一個程序員都在獨立的進行很小的任務，他還是要劃分大約三分之一的時間來指出要做什么，三分之一的時間用來做事，最后三分之一的時間用來保證工作的正確性。他可能會在這些時間的使用上做一些調整，但是作為一種理解任何工作的大概的方法，三分法適用于任何規模的項目。

2.3.2 劃分和控制（大計劃 = 許許多多小計劃）

如果你研究了絕大多數的軟件開發方法論，就會明白三分法的大致概念。設計的目的和實現的具體方法可能不盡相同，但是在最高層上，最終的目的都是相似的。

項目越大，時間越長，就越復雜，這就需要將計劃劃分成小一點的片斷，每個片斷都有自己設計，實現和檢驗時間。極限編程（也稱為XP）稱這些片斷為迭代；螺旋模型中稱做階段；還有一些組織則稱它為里程碑。在XP中，這些時間段可能只表示幾個星期，在螺旋模型中可能就意味著幾個月，但是基本的理念的相同的：為有限的時間范圍作詳細的計劃。

項目的變化越多，越不穩定，里程碑就應該越短。這樣才能降低計劃的風險數，因為主計劃已經被劃分為可以管理的片斷。計劃片斷之間的間隔提供了做調整和改進的機會，從而使下一個里程碑能正確的指導自己的工作。（我們將在14章討論怎樣去做。）

2.3.2.1 敏捷和傳統方法

XP 和其他的敏捷方法都假定未來是不穩定的，所以它們更看重能容易體現方向變化的過程。那些具有很大生產消耗的項目（比如說，蓋摩天大樓，生產視頻游戲終端，或是制作嵌入式操作系統）走的則是另一條路，它們在計劃和設計活動中作了很大投入。它能夠被完成，但每個人都要致力于計劃中做出的決定，而且為變化付出高昂代價是不可避免的。

大多數的軟件項目都是出于兩者的中間。它們有初始的計劃，要應付未來用戶需求的不穩定性，工作按階段劃分，每個階段都有設計，實現和質量保證的時間。如果出現一個新問題，可以考慮把它放在當前階段，也可以安排在下一個階段研究理解。

對于絕大多數項目，初始計劃時間是用來從客戶和業務人員那里獲取足夠的信息，從而來定義需要多少階段，每個階段的重心是什么（見 圖2-2）。按照大計劃，每個階段都要花很多時間來設計和檢驗。一個階段可以被劃分為兩個更小的階段（采用更加敏捷的開發方式），或者兩個階段可以被合并起來（采用更集成的方式）。但是在所有情況下，都要在階段之間分配時間，從而對變化加以利用。這包括了對那些在前一階段出現但無法全面解決的問題的處理。

圖 2-2 大項目就是小項目組成的序列

這些就是我要講的高層的計劃方法論。14章和15章將講述怎樣通過整體計劃管理項目，但是它們都將重點放在管理和領導的角度，而不是具體描述怎么樣應用一個特定的方法論。如果你能看完下面幾段（即使你不完全同意其中的觀點），那么不管你怎樣組織和計劃你的項目，14章和15章里面的意見都是相關的，實用的。

總之，我對那些在這一節退出的人表示抱歉。現在，一切都結束了，我保證這個輕量的，簡單的計劃視圖正是你所需要的，你可以以此來更好的理解本章余下部分的原理。

所謂「信封背面計算法」，便是當你對某個問題的答案不確定時，可以拿出一個舊信封，思考一下基礎的原理，然后在信封背面寫下幾個近似方程序，互換幾個可能數值，看看求出的答案可否解釋這個難題。如果無法解答，便繼續找尋其它答案。這種算法就好像拿刀子切奶油一樣，可以去掉一些無價值的答案。