在敏捷軟體開發估算相關材料、培訓和交流中，常常見到聽到「昨日天氣」這個說法。我一直不是特別理解 敏捷裡提出「昨日天氣」是出於什麼目的。
可能的目的有：
1，昨日天氣情況很容易觀測，拿來推斷今日天氣，很是方便。
2，根據昨日天氣來推測今日天氣，對於普通人來說，錯誤率極高，所以這個方法效果不好，所以記錄昨日天氣的效果不好。
這兩個目的是矛盾的。
長期的困擾在敏捷中國大會被聽眾提問時，我貌似有所悟。當時的問題的大意是「有領導擔心 如果從cmmi轉向敏捷，估算會不準確，怎麼辦」？
首先這個問題的表面是有歧義的。他所說的「從cmmi轉向敏捷」是指原來在cmmi推進下建立的相應方法轉變到敏捷軟體開發下推薦的相應方法。
當時我回答的大意是基於cmmi4開展的估算的精確度是高於一般的敏捷開發的估算，而達到cmmi3所開展估算的精確度恐怕還比不上採用燃盡圖。
第2天，我繼續思考了這個問題，將昨日天氣的疑惑代入，得到了如下的文字。
天氣預報的7重境界
1，像我一樣的普通人，能夠在夏天看到烏雲蓋天時預報雷陣雨。
2，經驗豐富的老農，多年經驗讓他能夠通過觀察雲朵、風向、太陽、月亮、星星來判斷第2天的天氣。
3，氣象愛好者團體，比如多位在一起交流的氣象愛好者或者經驗豐富的老農
4，縣級氣象台 開展本地氣象記錄，預報本縣天氣，氣象台技術人員數量不超過10個。
5，省級氣象台
6，國家級氣象台，擁有衛星、超級計算機
7，全球頂尖氣象台，擁有覆蓋全球的天氣觀測和15天預報能力
關於軟體工程中規模和工作量的估算
規模是指軟體工作的大小，一般有兩類表示法：1類是諸如**行數、功能點數等等，另1類是直接採用工作量。
工作量一般也分兩類：1類是全部工作量，另1類是理想工作量， 理想工作量與全部工作量存在數學關係， capacity = 理想工作量/全部工作量 。
常見的估算方法有如下，說明：以下方法並不是孤立使用的，不少地方是組合使用的，為了方便敘述，就羅列在下面了。
1，個人憑經驗估計，俗稱拍腦袋，據說此方法的誤差範圍是1/4~4。
2，群體憑經驗，比如delphi方法，比如撲克遊戲，當然撲克遊戲一般也基於story point。
3，按照一定的方法，比如ifpug，ucp(use case point)，user story point, cocomo, cocomoii, nesma，mkii等等
4，cmmi2 上個專案的資料可以拿來作參考, 採用一些方便獲得的資料。
5，cmmi3 專案資料被組織採集，組織經分析後提供一些估算的引數，估算的結果一般帶有中值和上下限。規模表達的方法要求得到定義。
6，cmmi4 收集大量資料，通過統計學分析得到過程績效模型和能力基線，裡面幾乎必然用到了數學建模方法，典型的給出帶有概率判斷的**。
7，scrum中利用理想人天或理想工時估計
8，scrum中利用story point的估計
9，cmmi5 在cmmi4的基礎上，能夠對主動變化進行可控制、可預期的估算，模擬到氣象的話，就是通過計算分析進行人工降雨或驅雨，選擇合適的氣象條件，在適當的位置釋放適量的、適當的材料，讓雨能如預期的來或者不來。
根據大量資料、進行數學建模得到的估算的偏差比例一般來說是小於簡單方法的。但如果估算的物件本身是很大的話，那麼小偏差比例會被放大，所謂「差之毫釐，謬以千里」。
敏捷對估算是擁有天然優勢的，就是在於短迭代和小團隊，在小團隊短迭代的情況下，估算物件本身不大，誤差會及時發現，在下個迭代中有機會去調整。
換句話說，在敏捷小團隊短迭代下，偏差比例就算大一些，絕對的偏差並不大。也就意味著，在敏捷環境下，不必使用高精度偏差比例很小的估算方法。
對照到天氣預報的7重境界，我把真正滿足cmmi4模擬到國家級氣象台，cmmi2也就在縣級，cmmi3在縣級到省級之間，一般的敏捷估算放在氣象愛好者團體級別到縣級到省級之間。
通過分析天氣預報的七重境界，發現「昨日天氣」很不簡單，複雜度不必軟體估算低。敏捷估算中拿「昨日天氣」來做隱喻，如果是整體全面考慮，真的是很恰當。
但如果是把昨日天氣對比為「把上幾個迭代完成的故事點數的平均值作為當前迭代的估算」，那麼也許就是用錯了，這帶給我長達3年的困惑。
------
從天氣預報來看軟體開發的估算
在敏捷軟體開發估算相關材料 培訓和交流中，常常見到聽到 昨日天氣 這個說法。我一直不是特別理解 敏捷裡提出 昨日天氣 是出於什麼目的。可能的目的有 1，昨日天氣情況很容易觀測，拿來推斷今日天氣，很是方便。2，根據昨日天氣來推測今日天氣，對於普通人來說，錯誤率極高，所以這個方法效果不好，所以記錄昨日天...
從資訊的角度來看待軟體開發
個人感覺，程式開發，是乙個處理資訊的過程。一開始，我們什麼都不知道，需求也是模糊的。在需求分析過程中，我們漸漸能夠看清到底需要完成什麼功能。但是如何實現這樣的功能，我們還是不了解。在設計階段，我們根據需求的內容，嘗試乙個個原型，直至找到合適的，或者根據需求 創造出乙個。事實上，需求的資訊量如此之大，...
通過哲學的視角來看軟體開發
做了兩年的.net 的開發，回過頭來看c 錢能的 c 書讀了好幾遍，每次都有不同的收穫。上學的時候讀了兩邊，沒有學到什麼書，等工作了，再看了幾次，越來越感到c 的偉大 語言本身沒有，這個語言的思維，是偉大的，這個語言在架構到執行的平台上就是更了不起的事情。類的機制，物件導向的機制，訊息驅動的機制，在...