估算的應用
估算是軟體開發團隊的日常工作，幾乎每個人都會涉及各種估算，程式設計師要對任務進行估算，專案經理或者架構師要對專案或者方案進行估算。這是因為估算是軟體開發過程中的乙個核心概念，它是所有計畫與管理的基礎。比如我們需要估算乙個專案的投入與回報來確定是否值得啟動這個專案；我們會依據估算來確定專案的交付或者上線日期，並把這個大的目標分解為很多階段性的控制點，並以此作為專案計畫和日常管理與監控的依據。
追求估算的準確性
基於這些原因，很多人相信並致力於追求估算的準確性，業界也相應的創造應用各種估算的方法和模型，比如：專家判斷、模擬估算、引數估算、自下而上估算、三點估算等等。最常見的是依靠資深人士比如架構師、專案經理、技術主管的個人經驗和能力，甚至結合公司內外可以參考的各種「類似」的資料或者標準來進行估算。
估算成為度量、管理和考核的標準
追求估算的準確性本身好像無可厚非，但是一旦得到這個神奇的數字後，往往就成為了各種度量、管理和考核的基準。我至今還記憶猶新，第一次做
pm的時候，每兩周就要向領導做專案匯報，如果基於掙值分析出現進度或者成本的偏差超過了基於估算的控制線的時候，就猶如過堂，必須有個交代。因為估算是「準確」的，所以如果在執行過程中的實際進度與依據估算所做的計畫有偏差，一定是執行的人或者團隊出現了問題。
遇到這種情況，我們往往會惶惶不安的自我檢討：是不是我們開發人員的能力沒有達到要求？是不是我們的開發團隊不夠努力？為什麼我們沒有預見到影響我們工作的各種依賴，是不是我們的風險管理沒有做好，是不是我們的
contingency
留的不夠？我們也可能會把問題歸咎於自己的估算能力，為什麼我們的估算不準確？當然，我們也很擅長找別人的問題，比如，因為需求不清楚，所以我們花了很多的時間去澄清需求；這個問題是乙個新需求，而不是乙個
bug；因為
ux/ui
設計交付延遲，所以導致我們的工作滯後。無論什麼樣的解釋，我們最終幾乎都無法避免加班加人這個軟體開發的魔咒。即使一些做「敏捷」的團隊，仍然受困於估算。我自己就遇到過這些情況：有
manager
或者po
要求度量每個
sprint
的完成情況，甚至比較各個團隊之間的
velocity
；有的manager
或者po
要求團隊提高
velocity
以便達到
release date
的目標。
估算，就這樣成為了管理者和客戶的利器，也成為了套在開發團隊頭上的枷鎖。開發團隊為求保險，往往會放大估算，而管理者和客戶又自然會壓縮估算，這就成了雙方對估算的博弈。
敏捷中的估算
敏捷產生於應對軟體開發過程中的各種不確定性，認為估算只能是就目前已知的情況對開發活動進行乙個大致的**，而且估算一定是整個團隊的集體活動，而不是某個專家的個體行為。即使使用
planning poker
進行估算，也並不是為了追求估算的準確性，而主要是為了激發團隊對
story
的集體討論。既然各種不確定性不可能體現在估算裡面，那麼估算也就不應該成為度量和考核的標準。比如，在
scope
確定的情況下，
release date
一定是乙個可以變動的範圍；在乙個
sprint
中，如果有
story
沒有完成，也是正常的現象，當然團隊可以在
retrospective
活動中對此進行討論，看看是否有提高和改進的可能；團隊成員對某個具體任務的估計，也是其對完成這個任務的乙個大致的估計，而不會是衡量其工作的依據。有些敏捷團隊認為估算是一種浪費，主張把
story
分解為大體相當的尺寸而節省估算的時間，有的甚至乾脆就不做估算。也許要準確的做估算，就只能是把這個
story
做一遍。
軟體開發活動的本質
為什麼傳統軟體開發管理和敏捷對估算是不同的態度呢？這是因為它們對軟體開發活動的認識有根本的區別。傳統軟體開發管理的思想認為，軟體開發活動是可以進行**和計畫的，只要專家（專案經理，架構師，資深程式設計師）做好估算和計畫，團隊成員嚴格遵守**於「最佳實踐」的開發和質量管理流程，就可以複製專案的成功，其本質上是受到泰勒的科學管理的影響。敏捷則更強調軟體開發的不確定性，應對的辦法就是信任並授權團隊，從側重**轉變為側重調整適應的能力，以小步迭代增量的方式來尋求各種反饋以修正前進的方向。
那麼軟體開發活動的本質到底是哪一種呢？這當然是仁者見仁，智者見智。下面以乙個簡單的例子來討論。假設，我們需要在下班的高峰期，從西安軟體園零壹廣場，開車到市中心吃飯。那麼從開車出發開始，每一時刻我們都需要眼觀六路，耳聽八方，獲得各種資訊，同時手腳並用，修正我們的車速與方向；而每到乙個路口的時候，我們都需要對前方的路況做出判斷，重新實時規劃路徑。其實任何乙個有經驗的老司機也不能事先準確的**出我們需要花多少時間才能夠到達目的地，我們事先只能大概估計可能需要花
40-60
分鐘左右到達。開車尚且如此，軟體開發呢？
軟體工程的本質
軟體工程的本質 問題域到不同抽象層之間概念和計算邏輯的對映.從問題域到開發平台直接進行對映，勢必存在一定的複雜性。為了控制這一複雜性，需要確定多個抽象層，例如需求 設計 實現 和部署等，每乙個抽象層均由自己特定的術語定義，形成該抽象層的乙個術語空間。如果按照自頂向下的途徑進行軟體開發的話，首先就是通...
軟體工程 成本估算
1.某軟體公司統計發現該公司研發部門每一萬行c語言源 形成的原始檔 c和.件 約為250k。某專案的原始檔大小為3.75m。問該項目的規模是多少kloc 源 行數 該公司研發部門的生產率是0.625kloc 人月，人工價是10000元 人月。問工作量和總成本是多少？每行 的價值是多少？3.75m 2...
軟體的本質與軟體工程科學（二）
專案管理實踐 分析就是對軟體產品的需求 可行性進行分析。確定要做什麼功能，需要什麼成本，承擔什麼風險，能否成功，有怎樣的收益，值不值得這麼做。設計是在軟體產品完成分析階段並決定繼續開發之後，將更加實際地 系統地 細緻地考慮和規劃實現層面的細節，比如確定要用什麼樣的系統架構，什麼樣的管理體系，介面怎麼...