※ 引述《smallworld (腸門有稀)》之銘言： : 以下說的這些需求到後來都會變成公司文化問題 : 比如某老社想要推這類東西 找了小弟 : 進去一看 程式MVC不分 爛了好多年的老 code : 說要自動化測試 根本untestable的架構 : 連unittest都搞不起來 (一個網站包成一整坨) : 出報告要重構 元件化 要用auto deploy : MVC要拆出來 要用artifactory jenkins : 每個單位主管當耳邊風 恭請他們配合就推沒時間 : 上報主管開會要求大家配合變成我說書大會 : 大頭主管看著CI CD願景跟執行規劃步驟都快高潮了 : 高潮完甚麼事情都沒變 做事的根本叫不動 : 程式會動就好 每年還不是有賺錢 : 最後就是文化問題把整個東西卡死 : 台灣公司沒那個本錢就不要搞這個 : 反正也不會比較好 關於方法論， 我跟幾個國外的前輩在去年做了一個針對遊戲產業組織文化及專案開發的問卷 叫 "The Game Outcomes Project" 在最後產出的五篇統計分析文章中 特別有一篇談到方法論( http://wp.me/pBAPd-pz ) 也就是採取瀑布式或敏捷式對專案成功是否有幫助. 其中得到的結論蠻特別的 結論是: 採取哪一種開發方法"並沒有"對專案的成功特別有幫助. (採取任何一種開發方法都沒有在統計上產生表徵) 我節錄部分給各位參考 "另一個令人驚訝之處在於方法論，也是業界頻繁討論的問題。 我們問的問題是團隊是屬於 沒有使用特定的開發方法， 使用瀑布式， 使用敏捷式， 或使用其他隨意的方式來開發。 我們也在答案的旁邊附註了最有可能的情境。結果令人震驚。 ...答案是甚麼也沒有。 ...對某些遊戲開發者來說，方法論被認為是聖杯， 會造成巨大的差異，特別以敏捷式為標的。 但其造成的差異很微小。每個方法論與產出分數的相關度都很低（p值很高）。 比之Scrum，敏捷式，或其他方法， 沒有使用特定的方法與使用其他方法都比想像中來得高。 ...製程的方法論原本被認為是放諸四海皆準， 但我們的結果卻沒辦法顯示出方法論與遊戲類型， 團隊人數，經驗，或其他項目有相關性。 ...即便是大家最不喜歡的瀑布式也都運作的很好。" 我認為smallworld講得是台灣生態 這是因為人類的習慣就是傾向穩定，害怕改變。 所以敏捷式的口號"擁抱改變"才會讓人印象這麼深刻 因為其實很難做到. 會認為很容易的人其實就像是健身教練說減肥很容易一樣. "不就是控制飲食,多運動嗎?" 回到台灣，至少在我觀察比較多的遊戲產業， 我認為： "公司能否賺錢，跟軟體開發方法，其實並沒有太大相關。" 所以自然在台灣的公司推這些先進的開發方法，很容易受到老闆或資深人員的不解。 其實有可能他們是對的，也就是說："搞那些有的沒的不會賺錢啊？" 但使用先進的開發方法對技術人有沒有幫助？ 其實我認為至少還有幾點好處，所以各位朋友也不要氣餒。 1. 可以跟世界接軌，如果有國外的職缺，對方也許是以這樣未標竿或標準的。 2. 對技術人之間合作有幫助， a) TDD除了做好測試外，還能協助確認規格。 b) 做好測試就是一種確保責任避免火亂燒的明哲保身好方法。 c) 使用版本控制，程式碼審核就是逼著程式把自己的罪惡攤開來。 d) 連續整合開發，就是不要把問題都堆在後面，誰進來出紅燈，誰要負責修好。 e) 站立會議，確認每天的衝刺開始，不要有人裝死。 也就是對自己好，對使用這些技巧的團隊"自己"好。 不一定要把這些技巧套用到別人身上，因為別人是別人家的事。 公司文化不會為個人改變。 各位摸摸自己的ＬＰ，如果公司文化真的很重要，大多數朋友願意減薪屈就嗎？ 這也就造成老闆用錢砸我們就可以讓我們放棄正常工時的原因。 如果沒獎金，誰會願意加班呢？答案不言自喻。 共勉之。 -- "May the Balance be with U"(願平衡與你同在) 遊戲設計教學，討論，分享。歡迎來信。 黑水溝歷史文庫 https://ndark.wordpress.com/ --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.164.2.170 ※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1451404534.A.1D4.html