為什麼需要詳細的進度表#
制訂詳細的進度表最好的理由之一，就是它給了你一個取消軟體功能的藉口。當軟體準時發佈與某個功能不可兼得時，你可以很容易地做出選擇——砍掉功能。
Joel 提出三條軟體開發週期的基本規則：
- 確定發佈日期——可以根據客觀情況，也可以根據主觀願望來選擇
- 列出軟體要實現的功能，然後按照優先順序排序
- 每當你落後於預定進程時，就把排在最後的功能砍掉
如果你忘了按照優先順序部署功能，一切就會搞砸。程式員會按照趣味性的順序開發各種功能，導致無法按時發佈，或者無法取消部署某個功能。
發佈日期是固定的情況#
有時候軟體發佈日期是外部限制決定的，例如：
- 證券市場的報價系統從分數改成小數
- Linux 核心不久後要推出新版本，你的應用程式必須跟上
- 外部平台的重大更新迫使你必須相容
這些情況下，發佈日期無疑是固定的。
三種發佈頻率模式#
對於其他情況，可以考慮三種方法：
1. 經常發佈稍作改進的版本#
- 屬於極限編程中的方法
- 適合客戶數量較少的小團隊開發項目（如公司內部 IT 項目）
- 較短的發佈週期能更快獲得顧客反饋
2. 每 12 到 18 個月發佈一次#
- 適用於上架銷售的商業軟體和桌面應用程式
- 適合有大型開發團隊和成千上萬名顧客的軟體
- 如果每年推出全新版本，實際只有約 3 個月用於寫新代碼，升級版軟體往往不夠吸引人
3. 每 3 年到 5 年發佈一次#
- 常見於超級龐大的軟體系統和平台（作業系統、.NET 框架、Oracle 資料庫）
- 開發人員可達數千名，與其他軟體之間存在極其複雜的互動關係
不要太頻繁地發佈新版本。如果你已經有大量付費用戶，頻繁發佈會讓用戶對 1.0 版的印象很難更新。Marimba 公司就是反面教材——過早發佈了一個功能不足的產品，六年後人們仍然只記得它是一個下載軟體的列表框。
關於品質與發佈的平衡#
如果你已經做了大量的驗證（validation）和單元測試，而且編寫代碼時很仔細，那麼每天工作結束後編譯出來的版本可能已經品質很高了，隨時都可以對外發佈。
- 不要高估每天編譯出高品質版本的重要性——即使軟體永遠不存在代碼錯誤，倉促投入市場仍可能發現相容性問題
- 一次完整的 beta 測試至少需要 8 週
- 如果你的軟體是網路服務，降低發佈頻率、把多處修改一次發佈可能比頻繁發佈更好，因為頻繁改變會降低易用性（使用者期待一致的行為方式）