【推薦】極限編程的十二大原則——計劃的制定

計劃的制定：包括客戶選擇的項目大小、程式功能的優先順序、各個版本的合成和發布日期。

曾經聽說過一個關於專案經理的笑話：接手一個項目，領導問項目需要多長時間，我們的專案經理拍拍腦袋說出一個時間節點。領導說這個任務很緊張啊，能不能快一點（再加上一些威逼利誘的話^%$#^%^$#^），專案經理繼續拍拍腦袋說出一個時間節點……就這樣一番討價還價，終於領導滿意了，臨走關切的問沒問題吧？專案經理拍拍胸脯說請領導放心。專案經理回來找到技術骨幹，把項目時間節點一說，拍著骨乾的肩膀說，兄弟，靠你了！項目開始後進度一再拖延，遲遲不能完成交付，專案經理著急的拍著大腿，怎麼辦啊~~~~最後，項目失敗了，專案經理拍拍屁股，走人！

       作為專案經理，幾乎是很難能夠按照自己的意見確定一個專案計劃的，為什嗎？這裡面有多種原因，上司總是會用市場需求等等原因來要求項目周期儘可能的短，而專案經理又不能拿出一個很令人信服的資料來證明項目就應該有這麼多的時間。於是項目時間節點的確定就完全變成了菜市場上的討價還價，上司儘可能的壓縮，專案經理儘可能的給自己留餘地。

       當專案經理的時候，我就碰到過這樣的情況，項目剛開始的籌劃的時候，領導滿口答應派給我的人力資源到了項目開始運作的時候居然都沒有到位！怎麼辦，安排新人吧，領導說人數滿足你的要求了，我聽得差點吐血。新人需要培訓、需要磨合，這些不花時間嗎？！其實很多人都知道在開發過程中並不是1+1=2這麼簡單的道理，活幹不完了，加班！還幹不完，加人！人越堆越多，效率卻越來越低，為什嗎？因為開發需要溝通，溝通的成本隨著人員的增加會成數倍的增大：兩個點用一條線，三個點要用三條線，四個點需要六條線，五個點需要九條線，六個點需要十五條線……我不敢往下數了，當一個團隊到了10個人的規模溝通的工作就很可怕了。

       以前做行業軟體的時候，公司會把軟體模組按照功能點列出來，然後針對每個功能點在不同的技術實現方式下需要多少人月估算出來（當然這需要曆史項目的積累）。然後在跟客戶談合約的時候根據使用者選擇的功能點制定出人月，進而得出報價。在很多軟體公司都是這麼做的。而我們公司現在也正在向這個方向努力，將來的軟體也會像物料一樣進料單，也會有成本，現在的IT部已經開始做探索工作了，他們的軟體現在都是按照組件為原則進行劃分，建立組件。將來理想模式就是使用者如果需要我們的軟體，那麼只需要在產品結構樹上選擇組件，就可以組成“料單”，我們的開發人員就可以根據這個“料單”進行組合。同樣，我們的專案經理就可以根據這些資訊估算出軟體報價和項目人月數了。當然，所有這些夢想實現的前提是這些軟體組件真正做到了組件化，介面真正做到了可以靈活改變。

       目前的項目大多數是“背靠一堵牆”進行時間計劃的，這一點在目前競爭激烈，以佔領市場為前提，以生存為目標的大環境下是很難改變的。那麼我們作為“底層”人員是不是就放棄了呢？其實，我倒是覺得越是在這種情況下，越能體現敏捷開發、極限編程的優勢。不管我們身處項目的哪個崗位、什麼角色，我們都可以以自己微薄之力，從自己開始進行改善。

       我們可以抱著積極的心態去參加專案計劃的制定，雖然我們不能推倒那堵大牆，但是我們可以讓每一次專案計劃的同行評審會議變得更加實際、更加有意義。我們用短短的兩個小時認真的分析出各個功能點的人月，分析出功能點的優先順序別。即便是經過分析，我們需要的時間遠遠多於公司的要求，也應該有勇氣去發出不同的聲音。我想，也也正是敏捷開發理念中提到的四個原則之一：勇氣。因為我們知道計劃永遠趕不上變化，所以我們要做的是調整態度，勇敢地去做好準備迎接變化，自然，迎接變化不是光憑勇氣，還要有各種具體的、實際的工作，這些工作就包含在我們接下來要解讀的其他原則中。