文档讨论了估算的重要性及其在软件开发中的挑战，包括承诺与不确定性之间的关系。作者提供了几种估算方法，如PERT和德尔菲法，并强调合理估算需要时间和经验。为了应对压力，建议避免轻易承诺，积极沟通，以及保持工作整洁和遵循纪律。

1. The Clean Coder
預估與壓力 (書摘)
2013/12/12 SJ
Email: sj@toright.com
Blog: http://blog.toright.com
http://www.amazon.com/The-Clean-Coder-Professional-Programmers/dp/0137081073

2. 預估 (Estimate) 的定義
什麼是「預估」？
● 業務：是承諾！
● 開發者：是猜測！
● SJ：撈錢的籌碼，或是一場鬧劇的開幕典禮

3. 該死的承諾與預估
承諾
● 承諾不能兌現也是一種欺騙
● 避免對「不確定」的事情進行承諾
預估
● 沒有承諾色彩
● 因為不知道要花多少時間，所以叫「預估」

4. 該怎麼「預估」？
話說在前頭
● 墨菲定律 - 凡是可能出錯的事就必定會出錯
● 除非你已經做過這件事，否則皆無法有效預估時程
預估方法
● PERT (計畫評審技術)
● Delphi (德爾菲法)

5. PERT (Program Evaluation and Review Technique)
三元分析法
O: 樂觀預估 (Optimistic Estimate)
N: 常規預估 (Nominal Estimate)
P: 悲觀預估 (Pessimistic Estimate)
期望值
μ = ( O + 4N + P) / 6
機率分佈標準差
σ=(P-O)/6

6. 數學時間
任務
樂觀預估 O
常規預估 N
悲觀預估 P
期望值 μ
標準差 σ
Alpha
1
3
12
4.2
1.8
Beta
1
1.5
14
3.5
2.2
Gamma
3
6.25
11
6.5
1.3
這三件任務的預估值：14 天, 17 天 (σ), 20 天 (2σ)

7. 德爾菲法
●
●
●
●
先定好規則（乘以二 / 平方）
亮手指大家一起參與預估
討論偏離值發生的原因（取得共識）
好處是避免別人的預估影響到自己的判斷

8. 討論與結論
PERT 法
●
科學量化，但有工具輔助會更好
德爾菲法
●
耗時，不容易聚集一群專業人士
大數定理 (切分工作)
●
問題：經驗不夠的我們，如何掌握開發範圍？
關於預估
●
預估這項工作需要時間與經驗，有效的預估比隨便估好的多

9. 殘酷的事實
官：請幫我看一下做這個要多久？
Me：大約兩個月可以完成部分比較確定的功能 (回答的相當保守)
官：我們只有兩週，可否用簡單的方法搞定？
Me：...（OS：那你幹嘛還問我）
Me：好吧，那我們挑些重要的功能來做！
官：這些、這些、還有那些、順便做這個
Me：...（OS：這不就全部了嗎）
Me：太多了，我還要進行測試與整合，兩週內絕對無法完成！
官：那麼只做這些、這些、還有那些，這以前做過，直接拿來改應該很快！
Me：...
Me：...
官：如何？
官：不管品質，先求有再求好！
Me：我好像也不能說不好...

10. 這故事的結果是...一場災難
●
●
●
●
開發期間，功能一再增加，品質持續下滑
兩週後，想「求有」的功能，一項也沒出來
兩個月後，一個充滿 Bug 且奇怪的系統誕生了
兩年後，新的工程師加班罵髒話改 Code

11. 避免壓力
● 最有效的方法就是「規避壓力」
● 別輕易承諾
○
○
避免對沒有把握的事情進行承諾
主動幫助業務找到方法兌現承諾，但絕不能接受承諾
● 保持整潔
○
「快速但髒亂」是矛盾的說法
● 危機中的紀律
○
足夠的「信念」讓我們遵循紀律

12. 應對壓力（逃不了，就面對它！）
●
●
●
●
不要驚慌失措
溝通
依靠你的紀律原則
尋求幫助

13. The End
Thanks
Email: sj@toright.com
Blog: http://blog.toright.com