恕刪 有一個觀念還蠻不錯的, "沒有銀彈" 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/m.aspx?n=bbs/Soft_Job/M.1523593383.A.0E3.html 真der, 人工幾週的事情變電腦自動跑半天就好 ※ 編輯: lovdkkkk (118.163.80.109), 04/13/2018 15:04:21