核心概念#

美國國會圖書館目前有大約 75 TB 的數位資訊在線上。透過 1Gbps 網路傳送所有資訊需要多久?壓縮 100MB 文字需要多久?交付你的專案需要多少個月?

在某個層面上,這些都是無意義的問題——都缺少資訊。但只要你掌握了估算技巧,它們都可以被回答。而且在產出估算的過程中,你會更了解你的程式所處的世界。

Tip 23 - Estimate to Avoid Surprises(估算以避免意外)

多準確才算夠準確?#

所有的回答在某種程度上都是估算。首先要問的是估算將在什麼脈絡中被使用——他們需要高精確度,還是只是一個概略數字?

估算單位的選擇很重要#

你使用的單位會影響結果的解讀。如果你說某件事需要約 130 個工作天,人們會期望它相當接近。但如果你說「大約六個月」,他們會預期是五到七個月之間。

時間長度使用的估算單位
1-15 天
3-6 週
8-20 週
20+ 週給估算前要仔細想想

估算從哪來?#

所有估算都基於問題的模型。在深入模型建構之前,有一個基本的估算技巧:問問已經做過的人

估算步驟#

步驟名稱說明
1理解正在被問的問題思考範圍,把範圍作為答案的一部分
2建立系統的模型建立一個粗略的基本骨架心智模型,模型建構本身可能帶來發現
3將模型分解為元件找出描述這些元件如何互動的數學規則,識別每個參數
4給每個參數賦值找出哪些參數對結果影響最大,集中精力把它們弄對
5計算答案系統複雜時對答案進行避險——做多次計算,變動關鍵參數
6追蹤你的估算能力記錄你的估算,看看有多接近。當估算出錯時,找出原因

估算專案時程#

Painting the Missile 方法#

真實世界的人估算不是用單一數字,而是用一系列情境(最佳、最可能、最差)。美國海軍在規劃北極星潛艇專案時採用了這種方式,稱為 PERT(Program Evaluation Review Technique)。每個任務有樂觀、最可能和悲觀的估算。

Eating the Elephant 方法#

作者認為往往決定專案時間表的唯一方式是透過在該專案上獲得經驗。透過增量式開發,重複以下步驟:

  • 檢查需求
  • 分析風險(優先處理風險最高的項目)
  • 設計、實作、整合
  • 與使用者驗證

Tip 24 - Iterate the Schedule with the Code(讓時程隨程式碼迭代)

在每次迭代結束時根據經驗精煉時程估算。精煉會越來越好,對時程的信心也隨之增長。

被問到估算時該說什麼#

你說:「我回頭再告訴你。」

放慢速度、花時間走過估算步驟,幾乎總是能得到更好的結果。在咖啡機旁隨口給出的估算(像咖啡一樣)會回來找你麻煩。

相關章節#

  • Topic 7,溝通
  • Topic 39,演算法速度