恕删 有一个观念还蛮不错的, "没有银弹" Ref https://zh.wikipedia.org/wiki/%E6%B2%A1%E6%9C%89%E9%93%B6%E5%BC%B9 缩 https://goo.gl/S7bKr4 推荐给大家 (?) (谜之音 : 老生常谈推荐个...) (艹) 对於各种看似冲突、矛盾的评论, 如果不综合考虑开发/运行环境, 人员组成等因素, 是很难有实质上有意义的讨论的 例如若是旧系统的改写, 像老旧的银行系统用 JAVA 翻新, DB 栏位确定、逻辑确定、规格一清二楚, 一个资深架构师 + PM/SA/SD + 新手菜鸟 n 名, 这种情形说用瀑布比用敏捷适合也是很合理的事情 例如很简单的 CRUD 专案, 搭配好棒棒的前後端框架, 每个功能都非常独立且简短, 要求不严、有 bug 上线後收到使用者回报再修就好, 收到回报後可以几分钟内追到原因改好上新版, 这种情形说跑敏捷不必搭配 unit test 也很正常 (本来就不需要) 说跟 coding 功力没关系也可以理解 (也是本来就不需要) (相对如果要求很严、有 bug 会亏大钱, 那最少 e2e test 跑一下) 例如某复杂 lib 的核心, 有复杂的逻辑、时常变动、扩展的规格、会被用在不知道 n 百个地方, 一个改动得测过 n 百个 case 确认都 pass 後才能发布, 这种的如果没 coding 功力跟相当程度的自动测试做搭配, 嗯... 可能要修改完再花两周手动测试之类的? 然後有错 > 再改 > 全部重测 又因为 coding 功力不好这 loop 重覆许多次 全部搞定已过三个月... 这样子应该很难敏捷得起来 (会有一堆 sprint 是 test > refix > loop) XD 总之只是想说各种方法/理论/工具都有它各自适用的情况, 也都有各自的强项与弱点, 真的要讨论东西的话各面向都交待得清楚一点会比较有效果, 另外自动测试真的不错, 人工测很累der (刚入行干过一阵子, 几百几千个 case 一天大概测四五十个) 不管敏不敏捷都建议可以试试自动测试 -- 废文能量释放完毕 XD --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 118.163.80.109 ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1523593383.A.0E3.html 真der, 人工几周的事情变电脑自动跑半天就好 ※ 编辑: lovdkkkk (118.163.80.109), 04/13/2018 15:04:21