作者AmosYang (泛用人型編碼器)
看板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/
這個題目很有意思，我以前也認為「因為不確定性(uncertainty) 與
複雜度(complexity)很高，所以無法有效估計軟體開發成本」；然而
，事實上並非如此，整理摘要我的筆記如下:
* 估計軟體成本(software cost estimation)是可行的；然而，一分
錢一分貨是永恆不滅的定律，若不願意投資提昇「估計方法」本身
的品質，且適當地與開發流程整合，那自然會是 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)
* 協商四要素: 尊重(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
※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1448651261.A.9A1.html
1F：推 haha02: 推一個 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：推 locklose: 推推～目前正在辛苦念這塊（跪） 11/28 03:46
3F：→ locklose: 真心認為這篇應該要改題目M起來 11/28 03:47
4F：推 MIM23: 推 11/28 04:03
5F：推 leafwind: 完全同意有方法可以改進 只是我針對"must ontime"回覆:) 11/28 10:57
如我上文中所述，要看這 "must be on time" 的要求是否來自於專
案鐵三角合理協商的結果 (還是硬把估價(estimate)凹成承諾(commitment)
6F：→ leafwind: 另外新創的變動程度大 要壓到25%已經是相對穩定的狀態了 11/28 10:58
是的，若能常態地把成本控制在估價的 +/- 25% 內，那已經是高手
高手高高手了 :D
7F：→ leafwind: 當然台灣對於新創的定義好像不太一樣 那又是另一回事.. 11/28 11:03
江山代有人才出；過去有「奈米」、「雲端」，現在是「新創」，潮
到出汁 :D
8F：推 lovdkkkk: 推 11/28 13:11
※ 編輯: AmosYang (70.181.102.71), 11/28/2015 17:20:35
※ 編輯: AmosYang (70.181.102.71), 11/28/2015 17:30:25
9F：推 longlongint: 四次裡有三次，估計值在實際值加減 25% 內 仍然被幹 11/29 07:31
10F：推 vn509942: 原來有這樣的評估方式 11/29 14:39
11F：推 GoalBased: 開個雞排攤也是新創阿，新開的又是創業，合理 11/29 15:43
雲端大數據奈米雞排
12F：→ sayya2311: 箭射不到靶,靶可以去追箭啊.. 11/29 22:42
13F：→ sayya2311: 不把所有責任壓在一次決策上,那估計準確的重要性就降低 11/29 22:44
※ 編輯: AmosYang (70.181.102.71), 11/30/2015 02:25:05