※ 引述《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/cn.aspx?n=bbs/Soft_Job/M.1451404534.A.1D4.html