推 rofellosx:1人RD 10/24 12:18
→ iincho:VSS通常都是老RD不願意改變使用習慣... 10/24 22:15
推 littlethe:推一個,重點在流程,流程不對,版本管理軟體一樣搞死人 10/25 01:24
→ Baternest:工作經驗... 第一間:VSS 第二間:ClearCase 第三間:沒有! 10/25 09:52
→ Baternest:但是最賺錢的是第三間... 不過後來我架SVN給大家用了~ 10/25 09:54
這一系列看下來真是心有戚戚焉...
小弟第一間公司是間頗具規模的公司，但版本與Bug管控=>沒有！
後來在客戶要求下，是用Excel...XD
個人是覺得版本控制有兩個目的：
1.功能區分
2.Bug管控
老一派的工程師總覺得這些玩意礙手礙腳，覺得那是老闆或大頭拿來盯人的工具。
(事實上他們也這麼做了...)
在一間股票上市上櫃的高科技公司，推這個居然推不起來 XD
後來轉到一間小公司，在主管與老闆支持下，架了個簡單的BugZilla。
我可以說，這種東西絕對對大家都有幫助！
各部門都能在第一時間通報Bug，省去以往溝通上的問題。
例如以前：FW發現有EE的問題，要從三樓跑到四樓找EE，找到後要花30分鐘吵架，EE才會
承認這個問題是屬於他們的。有時候還要把ME拉進來，大家再吵個30分鐘，確定這
個狗屁Bug到底是誰家的，這時候你花了一個小時，才能從這個根本與你無關的Bug
脫身。
現在：Bug上系統，一開始雖然我們認為這是EE的問題，但其實ME與EE都收到信，EE發現問
題不屬於他們的，他們會轉給ME。當然，ME可能在第一時間就意識到這問題其實是
他們的，在EE通知他們前，他們可能已經處理好了！
還有，絕大多數老闆、主管與工程師，都視Bug為財狼虎豹；但是其實Bug是很重要的！
一個系統好不好、穩不穩定，就是看測試期間測出的Bug數量與內容來決定！
比如說我做一台汽車，從開發到量產有1000個Bug，你說你做一台飛機，只有10個Bug，
那你會敢買那架飛機嗎?
一個產品越複雜，Bug就一定越多。因此當我們要做一個產品時，我們就能預估它應該要
有多少個Bug，也因此我們能夠過以往修正Bug的速度，來推測產品完成的時間表。也能
透過Bug的數量，來推測產品的成熟度。
此外做軟體的最吃虧的就是績效難以評比，
此時Bug就可以拿來量化了，我們可以透過解決了多少Bug，來評估個人或是Team的績效。
解決Bug的方法甚至可以申請專利，替公司或是個人取得額外的利益。
無奈的是絕大多數公司(尤其傳產)，見到Bug都像鬼一樣，
只要有人跟我說，我們的產品不能有Bug或沒有Bug，我就知道這個人沒Sense...
這世界上沒有沒Bug的產品，多或少而已。
這種口號留給消費者吧...
事實上如果是代工性質的產業，對客戶來說有版本控制或是Bug回報也是很重要的。
因為客戶只知道我給你錢，你把我要的東西做出來就對了！
當案子Delay時，他們會覺得你欺騙他們，因為你跟他們說一切順利，沒有問題，
但是時間到了，東西卻出不來？！(尤其是美國客戶)
現在很多大廠，你要幫他代工，可以，但是他們會看你的公司，如果沒有一個完善的管理
系統，他們便會很慎重的考慮合作的問題(尤其是日本客戶...毛很多)
最好的情況是，你的系統客戶也能上，這樣客戶能隨時追蹤專案的情況，
客戶會覺得他們什麼都知道，自然也不會來煩你。
(你才不需要三不五時接待從日本飛來的超級工作狂，
或是從美國飛來不知道是出差還是觀光的觀光團)
同時客戶也會知道案子難易程度，一旦發生Delay，他們也能夠接受，因為他們能從系統
上知道，這個案子比他們想像中難，有的時候甚至他們還會覺得賺到了(還好這案子是外
包，不是自家花時間做...)。
善用管理系統優勢：
1.提升部門間協調
2.客戶交流窗口
3.掌握專案進度
4.工程師自我時間安排
5.部門/工程師績效依據
不過話說回來，這種東西應該是PM在建立的，怎麼好像都是SW工程師在搞...= ="
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 125.231.209.12
推 kkc0828:可是我覺得Bugfix跟個人績效結合，在東方人的公司，可能會 10/25 18:44
→ kkc0828:導致很可怕的結果... 10/25 18:44
推 b6byc:因為軟體在台灣被人瞧不起.隨便就好.有硬體代工就好,爭那一 10/25 18:50
→ b6byc:點點的毛利,軟體工程?那是啥?隨便就好,能作出就行,我現在的 10/25 18:52
→ b6byc:公司就是這樣子搞,花更多時間在無謂的加班?很無奈... 10/25 18:53
→ songsongboy:拿解Bug數當績效...除非解Bug的和寫Code的不同人 10/25 22:59
→ songsongboy:否則就是變相鼓勵寫Bug出來解... 10/25 23:01
不可能，一個專案都有一個合理的Bug數量範圍，多或少都看得出來。
→ songsongboy:就算不要想的這麼黑暗, 採用這種方法評估也很奇怪... 10/25 23:02
→ songsongboy:今天有人寫Code前思考較謹慎, 交給測試測Bug比較少 10/25 23:04
→ songsongboy:難不成他的績效比較不好嗎... 10/25 23:04
所以我才說評估包括整個團隊，否則誰願意花時間解超級大Bug？
這種東西是主管給老闆看的，讓老闆知道SW Team在做什麼，
因為搞軟體是沒有實體的。不像ME或EE看的到摸的到。
反之，如果一個主管還要靠這種東西，
才搞得清楚自己的人在做什麼，那我看這主管也大有問題...
推 Wush978:請問原Po方便透露,Bug的數量要怎麼估計嗎? 10/26 13:50
指哪方面的?
※ 編輯: rv180 來自: 125.231.213.10 (10/27 14:57)