經驗是很重要的,寶貴的.它是花了時間和金錢獲取到的,它代表着一種歷史,積累和傳承
但是另外一個方面,經驗的產生一定有它的各種條件,於是,很多時候過於被經驗誤導.換個說法叫做"教條主義"
經驗雖然寶貴,但是未必正確! 未必科學! 隨意性太強,無法量化,只能感覺.經驗是差異化的.
還有一個說法是,經驗是拿來束縛我們思想的,什麼時候可以突破,進入下一個循環
----------------------------------------
在實際項目進度中,會有以下情況:
- 其他項目干擾
- 會議干擾
- 業務不熟悉導致的需求變動
- 意外情況
- 人員變動,人員水平預估不足
- 軟硬件問題
- 知識點複雜度預估過低
- ...
上面羅列的這些情況一定會干擾進度,而且基本上會重複出現.
從經驗學上我們都可以預估到這些問題的出現,但是出現的頻率,次數,時間週期是咋樣呢?
我們需要利用統計學來彙總這些嗎?
其實不必要.我們已經提出了一個概念:有效代碼量.
有效代碼量=總代碼量/代碼總時間(建議單位:工作日)
不管項目過程中到底是什麼干擾因素,只認爲它是干擾因素.
它(們)讓我花了更多的時間來寫代碼.
需要你理解的是在提及有效代碼量的時候有兩個概念:
- 個人有效代碼量,用於個人能力評估
- 項目有效代碼量,用於項目複雜度評估
嗯,你可能並不能理解我的思路和想法,那麼我換個思路來描述:
-----------------------
一個註冊頁面(模塊)會有多少行有效代碼,你告訴我? 假設200
一個基本的CRUD模塊會有多少行有效代碼?假設400
(這裏只算後臺代碼)
也就是說我們有600行代碼需要人來完成對吧?
現在我們手裏有A,B兩個人:
A:每工作日200行代碼.那麼600行代碼他需要3個工作日對伐?
B:每工作日400行代碼,他需要1.5個工作日對吧?
但是經過之前的項目迭代,我們統計出的A,B有效代碼量分別是:
A:60行,那麼實際需要 10個工作日;
B:180行,需要3.33個工作日;
這個對比數據可能很誇張.但是事實可能就是這樣:
獨立的看一個模塊,它可能確實只需要N1天.但是如果是10個模塊或者更多,難道這個時間是N1+N2+...N10嗎?
我們的思維習慣老是喜歡把一個孤立的事情簡單想加,而考慮不到這些孤立的東西加在一起的時候構成了網絡
我第一天能寫出來的代碼量假設是400,但是如果第二天我把第一天的代碼改動了20%,其餘時間開會了,第三天我有事請假了,第四天我在修補之前某個系統的代碼,同時新寫了100行代碼;第五天,我在想着馬上放假了,於是寫了200行代碼,改了50行代碼.
一般來說我告訴別人的是:我每天可以寫400行代碼,但是事實是這五天我只完成了700行代碼,也就是說我每天平均只寫了140行代碼!
呵呵,現在知道了爲啥進度總是延期了吧?知道爲什麼你總是要加班了把???