計畫的制定：包括客戶選擇的專案大小、程式功能的優先順序、各個版本的合成和發布日期。
曾經聽說過乙個關於專案經理的笑話：接手乙個專案，領導問專案需要多長時間，我們的專案經理拍拍腦袋說出乙個時間節點。領導說這個任務很緊張啊，能不能快一點（再加上一些威逼利誘的話
^%$#^%^$#^
），專案經理繼續拍拍腦袋說出乙個時間節點……就這樣一番討價還價，終於領導滿意了，臨走關切的問沒問題吧？專案經理拍拍胸脯說請領導放心。專案經理回來找到技術骨幹，把專案時間節點一說，拍著骨幹的肩膀說，兄弟，靠你了！專案開始後進度一再拖延，遲遲不能完成交付，專案經理著急的拍著大腿，怎麼辦啊
~~~~
最後，專案失敗了，專案經理拍拍屁股，走人！
作為專案經理，幾乎是很難能夠按照自己的意見確定乙個專案計畫的，為什麼？這裡面有多種原因，上司總是會用市場需求等等原因來要求專案週期盡可能的短，而專案經理又不能拿出乙個很有說服力的資料來證明專案就應該有這麼多的時間。於是專案時間節點的確定就完全變成了菜市場上的討價還價，上司盡可能的壓縮，專案經理盡可能的給自己留餘地。
當專案經理的時候，我就碰到過這樣的情況，專案剛開始的籌畫的時候，領導滿口答應派給我的人力資源到了專案開始運作的時候居然都沒有到位！怎麼辦，安排新人吧，領導說人數滿足你的要求了，我聽得差點**。新人需要培訓、需要磨合，這些不花時間麼？！其實很多人都知道在開發過程中並不是
1+1=2
這麼簡單的道理，活幹不完了，加班！還幹不完，加人！人越堆越多，效率卻越來越低，為什麼？因為開發需要溝通，溝通的成本隨著人員的增加會成數倍的增大：兩個點用一條線，三個點要用三條線，四個點需要六條線，五個點需要九條線，六個點需要十五條線……我不敢往下數了，當乙個團隊到了
10個人的規模溝通的工作就很可怕了。
以前做行業軟體的時候，公司會把軟體模組按照功能點列出來，然後針對每個功能點在不同的技術實現方式下需要多少人月估算出來（當然這需要歷史專案的積累）。然後在跟客戶談合同的時候根據使用者選擇的功能點制定出人月，進而得出**。在很多軟體公司都是這麼做的。而我們公司現在也正在向這個方向努力，將來的軟體也會像物料一樣進料單，也會有成本，現在的
it部已經開始做探索工作了，他們的軟體現在都是按照元件為原則進行劃分，建立部件。將來理想模式就是使用者如果需要我們的軟體，那麼只需要在產品結構樹上選擇部件，就可以組成「料單」，我們的開發人員就可以根據這個「料單」進行組合。同樣，我們的專案經理就可以根據這些資訊估算出軟體**和專案人月數了。當然，所有這些夢想實現的前提是這些軟體部件真正做到了元件化，介面真正做到了可以靈活改變。
目前的專案大多數是「背靠一堵牆」進行時間計畫的，這一點在目前競爭激烈，以占領市場為前提，以生存為目標的大環境下是很難改變的。那麼我們作為「底層」人員是不是就放棄了呢？其實，我倒是覺得越是在這種情況下，越能體現敏捷開發、極限程式設計的優勢。不管我們身處專案的哪個崗位、什麼角色，我們都可以以自己微薄之力，從自己開始進行改善。
我們可以抱著積極的心態去參加專案計畫的制定，雖然我們不能推倒那堵大牆，但是我們可以讓每一次專案計畫的同行評審會議變得更加實際、更加有意義。我們用短短的兩個小時認真的分析出各個功能點的人月，分析出功能點的優先級別。即便是經過分析，我們需要的時間遠遠多於公司的要求，也應該有勇氣去發出不同的聲音。我想，也也正是敏捷開發理念中提到的四個原則之一：勇氣。因為我們知道計畫永遠趕不上變化，所以我們要做的是調整態度，勇敢地去做好準備迎接變化，自然，迎接變化不是光憑勇氣，還要有各種具體的、實際的工作，這些工作就包含在我們接下來要解讀的其他原則中。
解讀極限程式設計的十二大原則 編碼標準（全文終）
編碼標準 遵守編碼標準，讓其它程式設計師明白 減少不必要的溝通。通常，在公司中都有編碼規範，然而這些編碼規範執行的好與壞卻很少有人關心，編碼規範有兩個大的方面作用 一是可以使 容易理解，當然這也是最主要的作用 另外就是通過有效的編碼規範可以提高程式的穩定性。下面就給大家介紹一下以前專案團隊中關於編碼...
關於《物件導向六大原則》的解讀
目錄 一 srp 單一職責原則 single responsibility priciple 二 ocp 開閉原則 open close principle 讓程式更穩定靈活 三 lsp 黎克特制替換原則 liskov substitution principle 讓程式擴充套件性更好 四 dip ...
設計原則 物件導向程式設計的六大原則
出處 一 單一職責原則 全稱 single responsibility principle 說明 就乙個類而言，應該只專注於做一件事和僅有乙個引起它變化的原因。所謂職責，我們可以理解他為功能，就是設計的這個類功能應該只有乙個，而不是兩個或更多。也可以理解為引用變化的原因，當你發現有兩個變化會要求我...