軟體開發的計畫應該由技術人員來做，專案計畫應該由專案管理人員來做。軟體開發計畫和專案計畫分別包含哪些具體的內容，這不是本書討論的重點（略有涉及），我們關注的是計畫的本質。 什麼是計畫？
預見是指從現實事物的發展規律中把握其未來發展的趨勢。和猜測不同，預見必定基於現實事物的發展規律。這些發展規律往往表現為嚴密的邏輯推理和科學的計算方法。
例如，圍棋棋手預見到10步棋後的中腹局面，這是經過了大量計算得到的。再例如，氣象局預報3天後的天氣狀況，也是經過了衛星採集的資訊並經過大量計算得到的。而猜測，是通過經驗性的直覺來完成的。
所以，按照計畫的定義，由猜測產生的計畫不是真正的計畫。
我所遇見過的絕大多數計畫都不是真正的計畫。這些計畫的制定沒有自圓其說的邏輯推理，沒有嚴格的計算過程。它們往往是專案管理人員拍腦袋（甚至是拍大腿）的結果。很明顯，這種基於猜測的計畫和事物的實際發展趨勢相去甚遠。
在如何有效地制定計畫上，cmm正嘗試為專案管理人員提供一些幫助。
cmm建議，軟體開發組織應該好好地維護自己的知識資產庫。一般地，組織的知識資產庫中包括以往專案的各種統計資料、軟體開發人員的生產率資料、專案上曾經遭遇到的風險以及相應的解決方案等。
按照cmm的說法，基於這些資訊，並通過一定的計算方法和邏輯關係來制定計畫，可以得到比較好的效果，換句話說，按照cmm的說法，用它推薦的方式來制定的計畫，與事物的實際發展趨勢更接近。
事實上呢？接近了一些，但是離預見性的目標還很遠。
這些年，在軟體開發領域中，基於預見性的軟體開發方法，例如，瀑布模型 ，正在被越來越多的軟體開發人員質疑。
瀑布模型是乙個非常理想化的模型。它的出現是基於這樣一種假設，我們預見的每一步都是正確的。 按照瀑布模型制定的計畫是乙份長期的、靜態的、精細的計畫。在這份計畫中，各個任務之間環環相扣，乙個任務的失敗，會對計畫造成很大的影響。這種影響體現在，乙個任務的失敗，會使相關任務的時間點發生改變，會使開發成本發生改變，會使人員安排發生改變等。為了保持計畫對行動的指導性，我們必須重新預見未來，並調整計畫。
可是，由於任務失敗或延遲完成是經常發生的，所以，計畫也必須經常進行調整，而每一次調整都幾乎無一例外地牽涉到大量的人力和時間。 這種精細計畫有意義嗎？它對行動的價值究竟有多大？
根據我們的實踐經驗，計畫總是處在不斷的變化之中。因此，我們有理由懷疑，未來真的是可以預見的嗎？如果可以預見，又可以預見到什麼程度呢？
有一種理論認為，非線性系統具有多樣性和多尺度性，換句話說，未來是無法確定的，如果你某一天確定了，那是你撞上了。這就是混沌理論，由美國氣象學家愛德華•諾頓•勞侖次 於2023年提出。
混沌理論認為，在乙個動態的系統中，即使初始條件發生了十分微小的變化，但是，經過不斷放大，對其未來狀態會造成極其巨大的差別。 有一首流傳的西方民謠，非常形象地說明了這個理論。
這首民謠說： 丟失乙個釘子， 壞了乙隻蹄鐵； 壞了乙隻蹄鐵， 折了一匹戰馬； 折了一匹戰馬， 傷了一位騎士； 傷了一位騎士， 輸了一場戰鬥； 輸了一場戰鬥， 亡了乙個帝國。
混沌理論可以解釋很多現象，我們也完全可以用它來解釋軟體開發過程中的一些問題。
例如，由於沒有考慮（或考慮不周全）使用者的乙個潛在需求，導致軟體架構的變化；軟體架構的變化，導致開發成本的增加；開發成本的增加，導致專案虧損；專案虧損，導致相關人員利益受損；相關人員利益受損；導致人才流失；人才流失，導致新專案的開發成本增加。 以此類推，沒有誰知道這件事的影響到底有多大。
話說回來，我在上面舉的例子或許有點誇張，但是，混沌理論的科學性已經在很多領域中得到了驗證，卻是乙個不爭的事實。有興趣的讀者可以去查閱相關的資料。
蓋公尺尼諮詢公司的諮詢顧問奈爾•格拉斯在談到企業決策時指出：
過去作為決策基礎的三個主要假定已經不再成立。
這些假定是：
假定1：企業是乙個「說到做到」的封閉系統。外界對企業決定採取的行動沒有多大干擾。
假定2：經營環境是穩定的。管理者能夠充分把握經營環境，從而制定出詳盡具體的戰略。
假定3：管理者對事件的因果關係有著足夠的認識。他們能夠順藤摸瓜，找出每一事件將會導致的變化。
這些舊的假定已經被三個新的現實所代替：
現實1：企業是複雜的「開放」系統，既影響著其所處的環境，又在很大程度上受環境的影響。這意味著，企業的行動可能無法達到它所預期的結果。 現實2：環境是瞬息萬變的（不斷創造著機會和威脅）。高層管理者不能指望制定出在付諸實施時仍完全有效的詳盡戰略。
現實3：作為傳統決策理論基礎的簡單線性因果關係模型已經失靈。因此，各種事件的後果是無法預料的。
混沌學家總是自豪地說：「相對論，消除了關於絕對空間和時間的幻想；量子力學，消除了關於可控測量過程的牛頓式的夢；而混沌，消除了拉普拉斯關於決定論式可**的幻想。」 的確如此，混沌理論在如今的氣象、航空及航天等領域的研究中，都正在發揮著重大的作用。
我們不妨對前面討論的思路做一次重新整理。
我們說，首先，建立在猜測基礎上的計畫是沒有任何預見性的；其次，完全基於科學計算產生的計畫（拉普拉斯的決定論是可**理論）不適用於動態系統；再次，混沌理論提供了一種兼具質性思考與量化分析的方法，它建議用整體、連續的資料關係對未來進行**；最後，從混沌中理出規則存在著可能性，但對於軟體開發這類工程沒有實用性。
基於上面的思路，我們也許要重新考慮軟體工程中的計畫的作用。該如何來為軟體專案制定計畫呢？
在這一點上，敏捷方法似乎走在前面，它非常明智地強調計畫的適應性而非預見性。
適應性的計畫不會描述中長期的具體工作內容（會有個輪廓），它更多地描述短期的、可以預見的工作內容，更重要的是，它時時刻刻都在準備著對計畫進行調整。
我贊同敏捷方法的思想，也想用簡單的一句話來表明自己的結論：對於軟體專案來說，制定長期的、靜態的、精細的計畫是沒有價值的；最有效的方法是建立短期的、精細的計畫，以及長期的、粗放的計畫。
測試計畫和測試方案的本質區別
測試計畫和測試方案的本質區別是內容不同。測試計畫的核心內容 1，進行測試任務劃分 2，進行測試工作量估計 3，人員資源和資源分配 4，明確任務的時間和進度安排 5，風險估計和應急計畫 6，測試失敗 通過的標準 測試方案的主要內容 1，測試策略選取，明確策略 測試策略就是如何用最少的資源滿足測試質量的...
本質啊本質之四 陣列的本質
陣列 1.陣列是同型別的聚合 2.定義乙個陣列，如 type x n 意思是記憶體裡有 n個連續的 type 型變數，連續的排列在一起。x 是第乙個元素的位址，是乙個立即數，是右值，不是變數。x x 0 這是編譯器處理的，因為當你將 x 賦值給乙個指標時 編譯器實際上就用的 x 0 3.多維陣列也是...
控制代碼的本質
handle就是pvoid，也就是無型別指標，上面這些資源的控制代碼handles都不過是指向struct的指標，至於這個struct的用處，連m 都說unused了，現在解釋下m 這麼做的意義，這就是所謂資料封裝，你可以在你的程式中把m 的內部結構指標傳來傳去，可是你卻不知道它到底指向的內容是什麼...