方案是為了解決乙個問題而存在的，因此所有的方案都有其原因，那我們今天的話題也不例外。
作為軟體工程的一部分，計畫在整個過程中占有舉足輕重的地位，可以用一句官僚的話來說就是，它是一場戰爭的排頭兵，直接影響了任務的成敗。
讀過《軟體估算》這本書的朋友應該還記得這句話：估算和計畫是兩個相關的話題，但估算不是計畫，計畫也不是估算。估算應該看作是客觀的（
unbiased
）分析過程；而計畫應該看作是主觀（
biased
）目標求解過程。
那麼在這裡，我們討論的只是主觀求解的若干想法，而其依據則是「估算」以及「經驗」這兩個資料**（在《軟體估算》一書中，「經驗」也是估算的一種資料**，《軟體估算》.引言
.p v）。
文中若干假設及資料大多來自此書，在此則不予以贅述。
翻開《軟體估算》的引言頁，其楔子便是這個經典的「
6拍」黑色幽默：在專案開始之前，你總是先「拍腦袋」得出進度和成本的承諾；在開工大會上領導「拍拍你肩膀」，是那樣的語重心長、充滿期待；而小酒剛下肚、春風正得意時，你不由得「拍胸脯」以表決心和能力；但在專案進展過程中遇到這樣、那樣的困難時，客戶和業主不能不「拍桌子」了；這時充滿悔意的你，只能「拍大腿」以示自責；而到了一切都覆水難收時，恐怕也只能「拍屁股」另謀高就了。（《軟體估算》.引言
.p iii）
故事誠然是故事，此作也基於這個故事對客觀資料進行了深入的歸納。但客觀之於主觀也僅僅是個皮球，事情常常陷入「資料你不妨估算，但腦袋我照樣拍」的窘地。那麼原因在**呢？對，就在這個「拍腦袋」之前的計畫。
在進入正文之前，我們有必要把幾個基本概念澄清一下。
計畫工作量即專案開始前，通過估算等手段對專案工作進行量化細分產生的成本。
計畫工作重點考慮專案的設計以及創造性工作，可以由實際工作資料確定，具有計畫性和高彈性。
為降低專案錯誤量、降低未知風險量而提前做出的預防性工作，由此產生的成本即為預案工作量。
對於軟體專案，其主要體現在系統的規範性設計、標準化管理、防禦性重構等工作上。其工作量會隨專案的程序而減少。
風險即未知（未預期），風險工作量即為解決未知（未預期）原因造成的損害而產生的工作量。
對於創造性專案，該工作主要體現在解決已有錯誤和處理使用者需求變動上。而對於不同級別的創造性專案，其風險的影響程度也不同，那麼我們又可以引出「風險係數」的概念。
對於創造性的專案，眾所周知的是，錯誤的修正成本與系統規模成正比，而專案規模則與時間成正比，即，今天的工作與昨天（以及昨天的昨天）有關，錯誤修正越晚，修正成本越高，那麼這一事實我們可以用乙個簡單的公式表示：
修正成本：
f(t) = a·t
·(t-1)
·(t-2)…(a
為正常數，
t為錯誤修正所推遲的時間
)
同樣，對於處理使用者需求變動的工作量也有類似公式：
變更成本：
f(t) = b·t
·(t-1)
·(t-2)…(b
為正常數，
t為錯誤修正所推遲的時間
)
那麼對於整個開發工作的風險工作量可以用這樣的函式來表示：
風險工作量：
f(x) = xp (p>0)
其中x為專案規模（進度），
p為風險帶來的影響係數，即風險係數，其與專案的性質有關，與進度無關。該公式表示，風險係數越大，其風險工作量隨專案規模增長所出現的增量越大。
p>0
說明了任何專案都會有風險。
有一點值得我們欣慰的是，一般（或者是大多數的）管理人員都會在拍腦袋前對專案做一下總體的部署和分配。作為乙個管理者，這個工作確實比拍腦袋要來的困難，但也並不是讓人寢食難安的事情――或者這也是很多人都想做管理的原因。所以，業界通用的計畫模型還不至於讓這些管理者丟掉飯碗。
恰恰是因為這些似乎是已成定式的工作方式，才導致了現在這種傻瓜式的計畫：平均式計畫模型。如下圖所示。
平均式計畫模型
圖中所示，實線部分是我們的管理者（或者計畫部門）為開發人員（或者實施人員）制定的工作計畫，一般可以認為是乙個工作崗位能夠承受的（人力或者資源成本）限度。而虛線部分則是在此計畫之外出現的工作。那麼兩部分相加的和便是我們在單位時間內的工作量，我們可以看到它隨著風險曲線的增長而增加。（具體的實況描述可以參閱我的另一篇拙作《今天還是明天――乙個人的軟體工程》）
在這種計畫模型下工作，一開始我們會感覺到事情很順利，很輕鬆，而專案經理也可以胸有成竹的跟老闆「拍胸脯」，但隨著專案程序的不斷推進，產出規模迅速增加，其缺陷、風險被成倍成十倍的放大之後，事先計畫的工作量已經越來越不夠用，那下面兩種結果的出現應該是必然的了： ÿ
專案延期 ÿ
持續加班
基於前述的平均式計畫模型，我們可以基本確定，計畫工作量平均分配會給後期工作帶來較大困難――風險成本是無法避免的。
那麼或許大家都已經想到了解決的辦法――至少是一種想法――就是將工作量按實際需要而靈活分配，那麼，這正是我們今天要討論的話題，梯式模型。而針對不同的工作型別，我們有三種模型：被動梯式模型、主動梯式模型和混合梯式模型。
被動梯式模型主要是考慮了風險成本，而將計畫工作量逐級提到設計初期，以便使專案後期餘出充分的空間和資源來應對逐級增長的風險工作量，如下圖所示。
被動梯式模型
從圖中我們可以看到，隨著專案程序的推進，標準工作量並沒有發生變化，兩種工作量之和滿足標準工作的要求，資源能夠被合理使用。
主動模型考慮了預案工作量能夠化解未來風險的作用，在專案初期投入較大預案工作，並隨著專案程序逐級減少，如下圖所示。
主動梯式模型
該模型採用主動化解風險的方式，將未來可能被放大的風險工作量，提前到設計初期，消耗更少的成本進行解決，以降低專案程序中未知風險帶來的影響，使之趨於水平。
從圖中我們同樣可以看到，隨著專案程序的推進，標準工作量並沒有發生變化，兩種工作量之和滿足標準工作的要求，資源能夠被合理使用。
混合梯式模型則同時考慮了風險成本及預案成本，將風險工作量（逐級增加）和預案工作量（逐級減少）進行混合，使之形成相對平均的工作量之後，再與計畫成本共同消耗標準工作。
混合梯式模型
從圖中可以看到，該模型吸取了被動和主動兩種梯式模型的優點，使風險及預案進行合理互補，在保證標準工作進度的同時，將風險降低到專案可以接受的範圍。
細心的你可能已經看到了一些端倪，的確，我們這個模型已經接近了目前流行的
xp開發模式的工作模型：計畫工作量只佔標準工作的一部分，雖然存在風險，但另一部分的互補工作有效的化解了風險，保證了專案的質量和進度。
前面我們講到了「風險係數」這個概念，而在梯式模型中並沒有使用到它，因為在我們的模型中無法量化的體現它的作用，在此單獨釋之。
在前面的公式中，我們定義了
p的概念，而且定義了
p>0
這個範圍，而作為乙個指數，0、
1和大於
1的數字，其函式模型並不相同，那我們來看這兩個極端的情況：pà
0和p>1。
當pà0
的時候，我們的函式曲線是乙個趨於水平的曲線（即無限趨近於水平線），這個時候我們可以說，風險不隨或者幾乎不隨專案的程序而增加成本。 而當
p>1
的時候，我們得到的卻是乙個向上發散的無限增長曲線，風險幾乎會在前一階段的基礎上增長另乙個數量級。
在創造性專案中，確切的需求、規範的管理、良好的習慣都可以有效降低p值。
前面我們說到，
p風險係數是乙個專案的固有性質，無法更改，其值也不可能小於等於
0（任何專案都會有風險），因此我們的工作是怎樣去在計畫中，盡量使其對專案的影響降到最低。
基於不同的
p值，我們可以選擇不同的模型。
如果專案的
p值較小（比如外包專案），則我們可以選擇被動梯式模型，因為畢竟對於此類專案，需求較為明確，管理機制相對健全，過度的防禦性工作則顯得過於浪費。
如果專案的
p值較大（比如需求不明的終端使用者專案），我們可以選擇主動梯式模型，因為對於需求不明確的專案，使用者的需求存在較大變數，這對於專案的整體設計影響較大，因此應將防禦性的預案工作提到首位，以最大程度降低專案的風險。 對於
p值適中的專案，則可以考慮混合梯式模型。
而今眼目下，對於成本和風險的控制，已經成為了每乙個管理者甚至開發者關心的事情，甚至已經成為了這個時代的標誌性語言――即便是拿這兩個詞來裝點門面――但如火如荼的討論卻讓人感覺到很少有人將其討論到點上。或許是個人水平有限，無法參透那些高深莫測的符號曲線；也或許是人們習慣於只顧眼前而置將來於不顧。如果是前者，倒是比較讓人放心，但諸多事實卻一次次告訴我們，後者是對的。
計畫對任何人都是乙個考驗，乙個經驗和魄力的考驗，如此重要的乙個環節，我們應該有充分的理由告訴自己在做什麼，將要做什麼。那麼希望不才的一點點想法，能夠讓大家在探索之路上尋到些許的線索――哪怕是往深淺未測的河裡扔下幾塊石頭來墊腳。
jmeter 梯式加壓測試
效能測試中，有時需要模擬一種實際生產中經常出現的情況，即 從某個值開始不斷增加壓力，直至達到某個值，然後持續執行一段時間。在jmeter中，有這樣乙個外掛程式，可以幫我們實現這個功能，這個外掛程式就是 stepping thread group stepping thread group是jmete...
判別式模型與生成式模型
判別式模型 該模型主要對p y x 建模，通過x來 y。在建模的過程中不需要關注聯合概率分布。只關心如何優化p y x 使得資料可分。通常，判別式模型在分類任務中的表現要好於生成式模型。但判別模型建模過程中通常為有監督的，而且難以被擴充套件成無監督的。常見的判別式模型有 logistic regre...
判別式模型與生成式模型
產生式模型 generative model 與判別式模型 discrimitive model 是分類器常遇到的概念，它們的區別在於 對於輸入x，類別標籤y 產生式模型估計它們的聯合概率分布p x,y 判別式模型估計條件概率分布p y x 產生式模型可以根據貝葉斯公式得到判別式模型，但反過來不行。...