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

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

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

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

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

數學時間 這三件任務的預估值：14 天, 17 天 (σ), 20 天 (2σ) 任務 樂觀預估 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 

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

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

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

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

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

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

The End Thanks Email: [email protected] Blog: http://blog.toright.com