> > by [Steve McConnell](http://www.evanlin.com/exec/obidos/search-handle-url?%5Fencoding=UTF8&search-type=ss&index=books&field-author=Steve%20McConnell) (Author) > > > > Covers software estimation techniques with information on how to successfully estimate scheduling, cost, and project activities. > > > > 圖片提供Amazon: [http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351](http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351) > > 其實前兩天就把這本書買回來了,由於工作關係,其實到了現在也才看完三分之一而已。不過還是覺得可以先把一些心得做一個簡單的整理。首先先來提提這本書的作者吧。Steve McConnell 已經被公認是軟體研發裡面相當具有經驗的人,而他所寫的Code Complete更是聖經中的聖經。不過我個人比較喜歡的書則是Rapid Development: Taming Wild Software Schedules (Paperback),因為這本書裡面利用故事講解了許多關於軟體開發上會遇到的現象與問題。 回頭來談談買這本書的原因吧,主要是因為最近組織調整的關係,原本我們是負責主要軟體研發與設計的部分(當然有所謂的除錯)。工作調整後,現在則專心在做專案管理與主要產品的控管部分。套句主管常說的話,除錯的能力人人都有,但是專案管理的能力可以讓你一輩子帶著走。不過仔細下去開始做,每個同事都是做得唉唉叫。比起以前硬著頭皮下去改程式碼、修臭蟲,原來專案管理與軟體研發的時間管理是更佳的困難。以前只要開程式開發工具毛起來去解問題,解不出來就加班到死~其他人也跟著你拼到死把產品交出去。現在則要好好的安排各種研發的時間與測試需要的時間與風險管理。如果需要別人加班,還需要有相當大的理由去說服人家~ 你當初在專案管理的時候怎麼沒有把加班排進去你的計畫中。除此之外,每天的報告與分析計畫更是少不了。不過~ 可能是以前做整理與分析資料的工作習慣了,我反而相當適應這樣的工作。 心得: 這本書~ 就如同他的標題一樣,主要就是講解如何去對你的軟體開發去做”評估”。怎麼樣才是一個好的評估呢? 在他的第一章先解釋”評估”與”計畫”的關係。(Relationship between estimation and plan)。裡面開宗明義開始解釋一下這本所提到的評估是甚麼,還有不要把評估當成是計畫。因為評估的時候往往是沒有了解全部資訊的,而計畫才是。(當然我們往往犯下錯誤~ 在沒有全部消息的時候就開始做計劃、或是被要求做計劃)。 個人相當的喜歡他的第二章想要傳達的重點,你是一個多好的評估者? (How good an estimator are you?) 裡面就有一個小試驗(算事小測驗)如下: Table 2-1: How Good an Estimator Are You? [Low Estimate - High Estimate] **Description** [ _____ - _________ ] Surface temperature of the Sun [ _____ - _________ ] Latitude of Shanghai [ _____ - _________ ] Area of the Asian continent [ _____ - _________ ] The year of Alexander the Great’s birth [ _____ - _________ ] Total value of U.S. currency in circulation in 2004 [ _____ - _________ ] Total volume of the Great Lakes [ _____ - ________ ] Worldwide box...