最近貓咪在學習Grails。但是從網上找到的《Grails入門指南》看着太累。特別是做測試的時候，要一邊看書一邊幹活，來回切換桌面實在麻煩。就去卓越網（現在已經是亞馬遜中國了）訂購《Grails權威指南》。在買書的時候，發現了《軟件估算-“黑匣子”揭祕》一書。是講如何成功進行軟件估算的。感覺比較新鮮，而且自己以往在開發中對應該如何估算工作量也一直沒有頭緒（基本上是想當然一個可能的大概值，但是基本上沒有任何數據去支持這個大概值），看了一下價格，標價49，打折後36.7。覺得價格不貴，就一同買下打算閒着沒事的時候看看。28號下單，卓越網給出的是《軟件估算》約31日送達，《Grails權威指南》倒要2月4日送到。昏死。結果今天早上《軟件估算》就來了。得了，反正《Grails權威指南》還要好幾天，貓咪就先看《軟件估算》好了。
估算，定義是：對項目將持續多長時間或者將花費多少成本的預測。
我們一般做項目的都是某某領導給出一個時間點，然後大家針對這個時間點開始幹活。無論遇到什麼問題，都要在這個點之前完成。如果不能在正常工作時間完成，那麼就要不斷加班加點。結果就是對老闆的怨氣，因爲這代表每天要回去得更晚，星期六、日不能在家好好打遊戲、甚至節假日也要幹活。同時國內很多公司對加班費不能按時按量給付和加班時間超過正常承受能力，更是讓大家的怨氣沖天。消極怠工者有之、邊罵邊幹者有之，還有到勞動部門舉報的。呵呵，貓咪也是深受這種荼毒。
貓咪以前基本上沒有寫過讀書心得筆記之類的東西，這裏也就是一些感想，可能很混亂，大家多多包涵。
一般情況下，我們開發一個項目的時候，客戶提出一些已知的需求。然後我們根據這些需求得到一個大概的時間。然後我們會和客戶就這個時間進度進行扯皮。我說需要3個月，然後客戶告訴我只能2個月。然後兩邊開始扯皮，互相要求對方答應自己的條件。不過國內多是買方市場。唉，誰叫中國人多呢。客戶經常用“你不做有人做”的理由壓縮工期、壓縮報價。你呢，多半在壓力下屈服，先答應下來，以拿到合同。開工後再和客戶溝通，以圖把壓縮的時間要回來。如果要不回來，就用加班壓榨程序員的辦法趕時間。什麼軟件工程、結構分層、領域建模、足夠的測試等等都儘可能不要，只要到時候能跑起來就可以。
客戶覺得項目到時候不能用，就告訴他以這個時間就能做到這個程度，而且有證據。看，項目組的程序員已經因不堪重負而病倒若干、住院若干、辭職若干。甚至於殉職若干。而且客戶到了這個地步，也不可能停下來。已經投入了這麼多了，不做下去就全費了，所以只能先湊合着用，然後再改進。但是項目組又有了新項目，去加班加點幹新項目去了。繼續完善維護這個項目的人員大幅度縮水，而且因爲開發時趕工期，沒分析、沒設計，代碼混亂，結構亂七八糟，幾乎無法繼續，最後下一版只能重新開發。唯一獲得的就是第二次的需求比第一次要明確得多（畢竟用過了一個半成品）。但是，如果第一次積累了大量的數據，而這些數據的結構因爲當初趕工設計得不合理，結果新項目因爲要保留舊數據，不得不繼承原來的不合理結構。
說得有點跑題。但是這就是貓咪對現在國內開發的現狀的看法。貓咪希望能通過讀《軟件估算》，學到如何計算有大量不確定因素的情況下能夠合理估算需要花費的時間和資源。以免自己給出一個自己無法完成的承諾。貓咪希望能夠在上面給出一個目標的時候，能夠估算出一個合理的工作量。如果兩者偏離太大，那麼可以和對方討價還價。就好像買辦公用品，桌子、椅子、電腦、筆、紙張或者打印機什麼的，需要很多。但是預算就那麼多，大家就坐下來，把那些不太重要的先去掉。以在一個可以接受的預算買到最需要的東西。如果你能拿出一個有足夠科學支持的理由，就很可能說服客戶，修改目標。比如在時間點不能變更的時候，是否去掉一些不太重要的功能。貓咪覺得只要你能提出足夠的，有依據的理由，客戶還是很容易說服的。客戶希望的是應用能夠給他帶來效益，趕工出來的半成品除了讓雙方承受損失之外，沒有任何價值。當然，不排除遇到蠻不講理的傢伙，貓咪覺得與其到時候完不成被開掉，不如現在就另謀高就。畢竟身體是自己的，如果答應了對方的要求就是做出了承諾，多累也得去完成。結果到時候仍然完不成，錢當然也沒有（沒有人會爲廢品買單），身體也完了。
軟件估算，首先就要把估算與目標、承諾區分開。不要隨便用自己直覺估算出來的東西作爲承諾。同時也要明白對方要的是對目標的估算還是對目標的承諾。還有就是估算、目標和承諾的溝通，也就是明確對方要的到底是完成這個目標的估算還是完成目標的計劃。比如上面要求爲3個月後的展示會完成一個軟件，問你大概需要多少時間。但是你卻估出了5個月的工作量。不好的溝通就是雙方都沒有明確對方要什麼，在什麼時候完成上面扯皮。其實展會並不等於軟件上市，拿出一個測試版本，能夠把需要展示的部分完成就可以了。但是你卻總說需要5個月。其實是沒搞明白對方要的是什麼，對方要的是3個月的時候能拿出一個能讓大家看的應用的計劃，當然能夠全完成就此上市更好。
所有估算出來的單點值不是100%的。如果說需要10個人月，那麼這個值到底有多少可能性呢？100%是不存在的。書上給出的是一個理論上是鍾型的曲線。如果你要告訴對方一個估算結果，最好是帶有可信度的單點值，或一個多點範圍。比如“70%可信度在20人月完成”或需要“15-30人月”之類的。承諾應該在估算區間內，並根據承諾指定計劃。
一個“良好的估算”，大師提出一個好的估算可以做到正負10%。但是，這是和CMM成熟度相關的。沒有良好控制的項目是無法做到的。考慮到國內的情況，能到CMM2都是燒高香了（真正達到，那些爲評級而搞出來的作秀品不算）。
估算對項目控制會產生很大影響。只要你做出了估算，那麼你就會根據估算做出承諾並制定完成這個承諾的計劃。一般只要最後完成時的花費在“估算”之內，大家就會說估算是成功的。但是實際上開發過程中不確定的事情太多，而且因爲需求的不斷更改，可能最後完成的東西和最初定義的東西完全不是一個東西。所以估算的真正目標是確定項目目標是否足夠現實，而不是預測項目的結果。
書中第一章的最後給出了一個“什麼是良好的估算”的定義：良好的估算是對項目實際情況有足夠清晰看法的估算，它讓項目負責人可以做出控制項目達到目標的好的決策。
估算，定義是：對項目將持續多長時間或者將花費多少成本的預測。
我們一般做項目的都是某某領導給出一個時間點，然後大家針對這個時間點開始幹活。無論遇到什麼問題，都要在這個點之前完成。如果不能在正常工作時間完成，那麼就要不斷加班加點。結果就是對老闆的怨氣，因爲這代表每天要回去得更晚，星期六、日不能在家好好打遊戲、甚至節假日也要幹活。同時國內很多公司對加班費不能按時按量給付和加班時間超過正常承受能力，更是讓大家的怨氣沖天。消極怠工者有之、邊罵邊幹者有之，還有到勞動部門舉報的。呵呵，貓咪也是深受這種荼毒。
貓咪以前基本上沒有寫過讀書心得筆記之類的東西，這裏也就是一些感想，可能很混亂，大家多多包涵。
一般情況下，我們開發一個項目的時候，客戶提出一些已知的需求。然後我們根據這些需求得到一個大概的時間。然後我們會和客戶就這個時間進度進行扯皮。我說需要3個月，然後客戶告訴我只能2個月。然後兩邊開始扯皮，互相要求對方答應自己的條件。不過國內多是買方市場。唉，誰叫中國人多呢。客戶經常用“你不做有人做”的理由壓縮工期、壓縮報價。你呢，多半在壓力下屈服，先答應下來，以拿到合同。開工後再和客戶溝通，以圖把壓縮的時間要回來。如果要不回來，就用加班壓榨程序員的辦法趕時間。什麼軟件工程、結構分層、領域建模、足夠的測試等等都儘可能不要，只要到時候能跑起來就可以。
客戶覺得項目到時候不能用，就告訴他以這個時間就能做到這個程度，而且有證據。看，項目組的程序員已經因不堪重負而病倒若干、住院若干、辭職若干。甚至於殉職若干。而且客戶到了這個地步，也不可能停下來。已經投入了這麼多了，不做下去就全費了，所以只能先湊合着用，然後再改進。但是項目組又有了新項目，去加班加點幹新項目去了。繼續完善維護這個項目的人員大幅度縮水，而且因爲開發時趕工期，沒分析、沒設計，代碼混亂，結構亂七八糟，幾乎無法繼續，最後下一版只能重新開發。唯一獲得的就是第二次的需求比第一次要明確得多（畢竟用過了一個半成品）。但是，如果第一次積累了大量的數據，而這些數據的結構因爲當初趕工設計得不合理，結果新項目因爲要保留舊數據，不得不繼承原來的不合理結構。
說得有點跑題。但是這就是貓咪對現在國內開發的現狀的看法。貓咪希望能通過讀《軟件估算》，學到如何計算有大量不確定因素的情況下能夠合理估算需要花費的時間和資源。以免自己給出一個自己無法完成的承諾。貓咪希望能夠在上面給出一個目標的時候，能夠估算出一個合理的工作量。如果兩者偏離太大，那麼可以和對方討價還價。就好像買辦公用品，桌子、椅子、電腦、筆、紙張或者打印機什麼的，需要很多。但是預算就那麼多，大家就坐下來，把那些不太重要的先去掉。以在一個可以接受的預算買到最需要的東西。如果你能拿出一個有足夠科學支持的理由，就很可能說服客戶，修改目標。比如在時間點不能變更的時候，是否去掉一些不太重要的功能。貓咪覺得只要你能提出足夠的，有依據的理由，客戶還是很容易說服的。客戶希望的是應用能夠給他帶來效益，趕工出來的半成品除了讓雙方承受損失之外，沒有任何價值。當然，不排除遇到蠻不講理的傢伙，貓咪覺得與其到時候完不成被開掉，不如現在就另謀高就。畢竟身體是自己的，如果答應了對方的要求就是做出了承諾，多累也得去完成。結果到時候仍然完不成，錢當然也沒有（沒有人會爲廢品買單），身體也完了。
軟件估算，首先就要把估算與目標、承諾區分開。不要隨便用自己直覺估算出來的東西作爲承諾。同時也要明白對方要的是對目標的估算還是對目標的承諾。還有就是估算、目標和承諾的溝通，也就是明確對方要的到底是完成這個目標的估算還是完成目標的計劃。比如上面要求爲3個月後的展示會完成一個軟件，問你大概需要多少時間。但是你卻估出了5個月的工作量。不好的溝通就是雙方都沒有明確對方要什麼，在什麼時候完成上面扯皮。其實展會並不等於軟件上市，拿出一個測試版本，能夠把需要展示的部分完成就可以了。但是你卻總說需要5個月。其實是沒搞明白對方要的是什麼，對方要的是3個月的時候能拿出一個能讓大家看的應用的計劃，當然能夠全完成就此上市更好。
所有估算出來的單點值不是100%的。如果說需要10個人月，那麼這個值到底有多少可能性呢？100%是不存在的。書上給出的是一個理論上是鍾型的曲線。如果你要告訴對方一個估算結果，最好是帶有可信度的單點值，或一個多點範圍。比如“70%可信度在20人月完成”或需要“15-30人月”之類的。承諾應該在估算區間內，並根據承諾指定計劃。
一個“良好的估算”，大師提出一個好的估算可以做到正負10%。但是，這是和CMM成熟度相關的。沒有良好控制的項目是無法做到的。考慮到國內的情況，能到CMM2都是燒高香了（真正達到，那些爲評級而搞出來的作秀品不算）。
估算對項目控制會產生很大影響。只要你做出了估算，那麼你就會根據估算做出承諾並制定完成這個承諾的計劃。一般只要最後完成時的花費在“估算”之內，大家就會說估算是成功的。但是實際上開發過程中不確定的事情太多，而且因爲需求的不斷更改，可能最後完成的東西和最初定義的東西完全不是一個東西。所以估算的真正目標是確定項目目標是否足夠現實，而不是預測項目的結果。
書中第一章的最後給出了一個“什麼是良好的估算”的定義：良好的估算是對項目實際情況有足夠清晰看法的估算，它讓項目負責人可以做出控制項目達到目標的好的決策。
