※ 本文為 dinos 轉寄自 ptt.cc 更新時間: 2015-11-28 15:37:40
看板 Soft_Job
作者 標題 Re: [討論] 是這間新創公司比較特別嗎?(更)
時間 Sat Nov 28 03:07:38 2015
※ 引述《leafwind (莉芙溫)》之銘言：
: ※ 引述《stevekevin10 (hippo泡)》之銘言：
: : 因此一開始定好的時間就要做完,不然就是你能力不足 fire
: 這條太弔詭，不是其中一方有問題，就是中間有什麼誤會
: 先假設事實上是你說的這樣
: 在回答「一開始定好的時間就要做完,不然就是你能力不足 fire」之前
: 先看一下這篇「軟體工程無法估算時間」
: http://mrjamie.cc/2011/04/11/why-cant-devs-estimate-time/
為什麼軟體工程無法估算時間？ | MR JAMIE ─ 創業者需要的啟發，每日新鮮供應
![[圖]]()
我們都有這樣的經驗：要開發一個東西，請工程師估算時間，大概要五天。結果過了一個禮拜，東西還沒出來。一問之下，碰到了原先完全沒有預期的情況，否則就是某個套件原來不能這樣用，必須要換一個，否則就是一個莫明的錯誤，找了一個下午還是不知道為什麼。久而久之，工程師開始習慣在回報的時間裡面灌水，預留空間給這些「未知數」，而我們也常常把他們給的時間乘以二，來得到最壞情況的數字。問題是這樣的方法之下，最後整個組織開始習慣用最龜的速度前進，因為估算精準、動作快，在這中間一點好處也沒有。更壞的情況，是叫九個女人去生一個小孩，那才是災難的開始。 為什麼軟體工程無法估算時間？ 要了解這件事情發生的原因，你必須要先知道 ...
![[圖]](http://mrjamie.cc/wp-content/uploads/2011/04/4325067780_450ce6b347_o.jpg)
這個題目很有意思，我以前也認為「因為不確定性(uncertainty) 與
複雜度(complexity)很高，所以無法有效估計軟體開發成本」；然而
，事實上並非如此，整理摘要我的筆記如下:
複雜度(complexity)很高，所以無法有效估計軟體開發成本」；然而
，事實上並非如此，整理摘要我的筆記如下:
* 估計軟體成本(software cost estimation)是可行的；然而，一分
錢一分貨是永恆不滅的定律，若不願意投資提昇「估計方法」本身
的品質，且適當地與開發流程整合，那自然會是 GIGO
錢一分貨是永恆不滅的定律，若不願意投資提昇「估計方法」本身
的品質，且適當地與開發流程整合，那自然會是 GIGO
* 估計軟體成本，實際上是綜合了心理學、專案管理學、生產力管理
學、統計學的一門學問。是故，若有人把估計軟體成本這件事一廂
學、統計學的一門學問。是故，若有人把估計軟體成本這件事一廂
情願地倒在軟體工程師頭上，然後高吹 "Practice makes perfect."
的法螺，且沒有提供相對應的資源與時間讓該軟體工程師去學習上
文所述的各門學問的話，這人腦子有病
* 通常來說，能夠作到「四次裡有三次，估計值在實際值加減 25% 內」
，就可算是個「好」的估計方法
* COCOMO 估計法，就今日的軟體開發來說，通常不會直接拿來應用，
但其分析辦法及各項參數仍然十分值得參考
* 書: Software Estimation: Demystifying the Black Art by Steve McConnell
* 認清楚估價(estimate)與目標(target)是兩件不同的事。估價(estimate)
的主要功用是檢視目標(target)是否合理。彌補估價(estimate)與
目標(target)之間的差異，是計畫(planning)的工作。易言之，可
以質疑「評估方法與其參數」，但不要去「喬」評估出來的數字。
* 專案鐵三角: 目標(scope), 時程(schedule), 預算(budget) ；專
案管理人先設定目標，工程師提供估價以檢視時程與預算的合理性
，最後協商確認承諾(commitment)
目標(target)之間的差異，是計畫(planning)的工作。易言之，可
以質疑「評估方法與其參數」，但不要去「喬」評估出來的數字。
* 專案鐵三角: 目標(scope), 時程(schedule), 預算(budget) ；專
案管理人先設定目標，工程師提供估價以檢視時程與預算的合理性
，最後協商確認承諾(commitment)
* 協商四要素: 尊重(respect), 信賴(trust), 溝通(dialog), 耐心(patience)
；信賴最為重要; 專注於雙方利益(interest), 而非立場(position)
尋找共同利益(mutual gain) ；就整體而言，寧可高估(overestimate)
而非低估(underestimate)，因為，低估產生的 tech debt 殺傷力
極大
* 給所有惡意、故意把估價(estimate)曲解為承諾(commitment)的人
的一句話: 去死
註: 筆記原文是英文，有些地方我以達意來翻譯，懶得追求字面上的
精準翻譯 :D
參考:
* https://www.facebook.com/amos.yang.104/posts/1624164124500579
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 70.181.102.71
※ 文章代碼(AID): #1MMAdzcX (Soft_Job)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1448651261.A.9A1.html
推 : 推一個1F 11/28 03:12
延伸討論: https://www.facebook.com/xdite/posts/10153802667928552
這篇裡提出個例子: "Perfect is the enemy of good."
也就是 scope, schedule, budget 鐵三角中，由 scope 這一角開
始崩壞的情形 :D
※ 編輯: AmosYang (70.181.102.71), 11/28/2015 03:18:22
推 : 推推～目前正在辛苦念這塊（跪）2F 11/28 03:46
→ : 真心認為這篇應該要改題目M起來
→ : 真心認為這篇應該要改題目M起來
推 : 推4F 11/28 04:03
推 : 完全同意有方法可以改進 只是我針對"must ontime"回覆:)5F 11/28 10:57
→ : 另外新創的變動程度大 要壓到25%已經是相對穩定的狀態了
→ : 當然台灣對於新創的定義好像不太一樣 那又是另一回事..
→ : 另外新創的變動程度大 要壓到25%已經是相對穩定的狀態了
→ : 當然台灣對於新創的定義好像不太一樣 那又是另一回事..
推 : 推8F 11/28 13:11
--
※ 看板: dinos 文章推薦值: 0 目前人氣: 0 累積人氣: 510
回列表(←)
分享