貓讀《軟體估算》三

wlmouse發表於2008-01-31
　　貓咪繼續發自己的感想。《Grails權威指南》還沒有送到。繼續讀《軟體估算》。
　　喵。大家有做我上一篇文章的測試題嗎？我會在本篇的最後公佈答案，以免有人透過預覽之類的功能作弊。當然，也許有人已經透過搜尋引擎找到了正確答案和自己的對比。那麼你得了多少分？
　　你的得分很低的話，那麼你就要好好想想為什麼會這樣了。人們為什麼會低估呢？低估的壓力來自於哪裡？是否是因為怕因為自己估值估的太寬了讓別人笑話？是否是自己的榮譽感、自尊心作祟？因為你會想，太陽表面溫度？我不知道。不過把從宇宙絕對零度到1億度都估算進去，總能包上。呵呵，這當然正確。但是你會覺得自己會成為別人的笑柄。書上這裡給出一個忠告，如果“感覺到有進行過窄估算的壓力，請確認其不是來自自身”。
　　進行估算的時候，是高估好還是低估好？
　　首先是高估。當然，不是漫天要價。比如把一個100W的專案要1億的資金。而是說一個專案如果估算可能在2到3個月完成，那麼我們應該取那個值比較好呢？3個月完成的可能性比較大，但是時間長。2個月完成的可能性比較小，但是如果按時完成，成本比價低（少花一個月薪水）。反對高估的理由是所謂的“帕金森法則”，用我們們的話來說就是磨洋工。1天干的活給了2天時間。所以程式設計師會在第一天把活幹完後去玩《魔獸》、看動畫片。因為給的指標是2天，到2天上我給出了產品，所以你管我怎麼用時間（對管理者來說浪費一天）。還有就是“學生綜合徵”，程式設計師會在開始的時候浪費時間，最後的時候趕工。其實我們小時候放寒暑假就經常這麼幹。剛放假的時候盡情的玩，反正時間很長，假期作業晚點寫也沒關係。結果到快開學的時候發現，一點也沒有動。於是點燈熬油的徹夜奮戰趕作業。
　　所以，很多客戶和管理者都覺得程式設計師給出的估算是一個超樂觀估算。如果要求1年的時間的話，最快6個月就可以。而且很多人喜歡看到別人每天緊張地忙碌，美其名曰“有緊迫感”。所以更加壓縮時間。1年的話我壓到6個月，最多再多給2個月。雖然我不相信他們能在6個月內完工，但是8個月應該夠了。反正最後1年無論如何也完了。而且我還可以以此打擊他們，比如要求賠償（雖然我實際上不在乎1年開發完，但是給你們的是6-8個月，所以不能要那麼多錢）、要求增加新功能（我已經給了足夠寬的時間，所以要多幹一些）。
　　然後是低估。也就是說按照估值的低點做計劃。2-3個月的估2個月，甚至1個半月。反對低估的一般情況下主要是程式設計師。因為人微言輕，所以很難反抗成功。反對的理由是太過樂觀的假設會造成計劃的有效性降低、趕工造成無法做出正常的系統。
　　估算的偏差理論上最好的是正負10%，實際上能有一倍的誤差就燒高香了。統計學顯示，程式設計師的估值一般比實際低20%到30%。也就是說程式設計師提出的估算實際上多半都已經是估算的低點了（實際工作量可能比估算的最高點還要高很多），那麼這麼大的實際和計劃偏差，計劃也就是讓客戶養養眼的廢紙而已。還有，低估會引發大量問題，專案團隊為了趕進度無休止的加班，造成大量錯誤程式碼，而為了修正這些錯誤，要花費大量的時間。為了到時候能夠有東西拿出來，什麼分析、設計的統統一邊站。單元測試、持續整合？每天連吃飯到睡覺都不夠6小時了，寫程式碼都來不及，誰還有工夫管這些。怎麼寫快怎麼寫。只要能跑起來就成，什麼BUG、設計不合理、效能低下以後再說。到時候指不定是哪個倒黴蛋接手呢，反正多半不是我（已經決定專案完成後就跳，什麼？你說跑不掉？這麼多加班、沒加班費。只要有證據，去勞動部門一告一個準，敢不放我走！）。最後的結果就是留給客戶一個只能扔到垃圾箱的“半成品”。
　　貓咪就當過那個倒黴蛋。維護過一段時間一個噁心的產品。這是一個從需求到完成只有2個月的中型專案。所有成員沒日沒夜，不眠不休製造出來的垃圾。Java的分層設計什麼的根本沒有。設計上到處都是BUG。資料庫表亂七八糟，如果不是因為資料庫第一正規化違反了表就建不起來了，他們估計連第一正規化也不打算遵守了。冗餘欄位到處都是，有時候居然一表多用。比如把新聞的分類和考試試題的分類用一張表存，班級通訊錄不是去使用者表讀使用者資訊，而是單建了一張。程式裡也是，重複混亂的程式碼到處都是。表現層的Action大家都知道，應該是一個功能一個Action（或Action中的一個方法）。他們倒好，一個Action中塞3、4個差不多的業務邏輯，而且用醜陋的if...else判斷。每個分支裡面的程式碼都是重複貼上的。還好我那段時間沒什麼趕進度的事情，不然非要了貓咪的老命。
　　最佳的專案結果來自最佳估算。如果估算過高，那麼就會出現“帕金森法則”和“學生綜合症”，過低則出現“專案計劃誤差”、大量缺陷和使用不成熟產品造成的損失。所以，作者提出的結論是，無論如何都不要低估。寧可高估也不要低估。因為即使高估，造成的損失是可以預期的。最多就是把預算花光、程式設計師比較清閒而已。這些問題可以透過積極的管理和專案控制解決。但是如果低估就不成了，大量的錯誤和返工、程式設計師的抱怨、法律風險（因專案延期的客戶索賠、程式設計師因為加班過多的法律訴訟和罷工）等等都會找上門。你無法預測低估到底會造成多大損失。
　　喵。貓咪多麼希望客戶和管理者能多高估而不要低估。可惜國內的客戶最愛低估了。貓咪參與過一個專案，還好只是調研需求。這個專案，客戶自己先進行了一年多的調研（真不知道為什麼用了這麼長時間）。然後是幾個月的招標。最後是不到3個月的開發。領導下令，必須按期完成，不許講條件。還好貓咪只是借調過去敷衍客戶，不然不死也這身貓皮也保不住了（是謂“不死脫層皮”）。之所以是去敷衍客戶，其實是因為招標結束後才開始組建開發團隊。但是銷售的對客戶大包大攬，客戶以為團隊已經開始工作了，所以只好把貓咪借調過去擋槍。客戶對貓咪說，不許說3個月不夠。你們應該招標完成前就開始工作的（昏死，合同還八字沒一撇就幹活？那要是沒中標不是白乾了！）。
今天就說到這裡了，貓咪繼續看書。
　　下面是上一篇測試題的答案：
1.10,000華氏度/6,000攝氏度
2.北緯31
3.17,139,000平方英里/44,390,000平方公里
4.公元前356年
5.7,199億美元
6.5,500立方英里、23,000立方公里，24*10(22)立方英尺、6.8×10（20）立方米、
7.18.35億美元
8.135,663公里
9.2千2百萬冊
10.170噸

文章引用自：
http://blog.sina.com.cn/wlmouse

[該貼被wlmouse於2008-01-31 14:03修改過]

相關文章