從天氣預報來看軟體開發的估算

2021-05-28 01:46:15 字數 2037 閱讀 8922

在敏捷軟體開發估算相關材料、培訓和交流中,常常見到聽到「昨日天氣」這個說法。我一直不是特別理解 敏捷裡提出「昨日天氣」是出於什麼目的。

可能的目的有:

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 的偉大 語言本身沒有,這個語言的思維,是偉大的,這個語言在架構到執行的平台上就是更了不起的事情。類的機制,物件導向的機制,訊息驅動的機制,在...