→ atst2: 更根本的問題是,不論號稱是scrum還是waterfall,最基本的 03/12 15:19
→ atst2: 分析, 設計，開發，測試，維護有沒有缺漏? 03/12 15:19
→ atst2: 目前觀察下來，不論scrum/waterfall,很多團隊是連分析都沒 03/12 15:20
推 gino0717: 我覺得測試部門應該要有更大的話語權 應該要有個 03/12 15:21
推 Kroner: 魚油 03/13 00:00→ atst2: 有，市場調查也不做，直接"我覺得是這樣"就往後跑了... 03/12 15:21
→ gino0717: CT(test)O 東西沒穩不准出去 03/12 15:21
→ gino0717: 不然就像二哥守荊州 你不知道哪天會出包整天抖 03/12 15:22
推 Kroner: 苦瓜胜肽什麼時候吃 03/13 00:04推 abccbaandy: 問題是大部分敏捷也是要做100%...問就是都要做 03/12 15:58
→ abccbaandy: 根本不是啥MVP，超完整的 03/12 15:59
→ stepnight: 有沒有scrum，套啥框架，不生文件都一樣XDD 03/12 16:09
推 Kroner: 魚油 03/13 00:23→ ChungLi5566: 想走敏捷就看空X 同時建好幾個火箭 試飛成功就把其他 03/12 16:16
→ ChungLi5566: 建到一半的捨棄掉 03/12 16:16
推 kuosos520: 躺平打工仔主點防禦，照顧好自己，敏捷是游擊隊的 03/12 16:16
推 Chricey: 苦瓜胜肽品牌推薦 03/13 00:25→ kuosos520: 事 03/12 16:16
→ hidog: 敏捷但又要100%就沒敏捷的意義了吧orz 03/12 16:28
推 OyodoKai: 大部分都 kanban 跑起來而已 03/12 16:41
推 Chricey: 苦瓜胜肽 03/13 01:34推 ktasl: 敏捷有文件 不可能沒有文件 難道需求拆分不算文件？ 03/12 17:09
推 abccbaandy: 有文件又怎樣，jira只寫個標題也算開ticket阿 03/12 17:13
→ hidog: 要有能支援開發的文件... 03/12 17:24
推 Chricey: 瑪卡功效要吃多久 03/13 01:36→ ssccg: 他們可是原本JIRA跑好好的，老闆說要改用便利貼和實體板 03/12 19:30
推 shadow0326: 什麼是100%? 從來沒看過任何產品是100%的 03/12 20:11
→ labbat: 開發部門有權直接關閉議題，管你穩不穩東西就是要推出去的 03/12 22:12
推 Kroner: 苦瓜胜肽 03/13 01:38噓 dream1124: 敏捷的重點不是什麼做個20%概念吧。重點是定期頻繁發佈 03/12 23:43
→ dream1124: 然後衝次過程不要隨便亂改計劃，好讓大家能按一定節奏 03/12 23:44
→ dream1124: 共同前進。你一個大願景只做20%是能試出什麼水溫？ 03/12 23:45
推 Kroner: 鋅的功效 03/13 01:40→ dream1124: 更何況就算瀑布式也能先做基礎版上市後續再修改。 03/12 23:47
→ dream1124: 敏捷在我看就是把原本一個大瀑布拆成好幾個小瀑布罷了 03/12 23:47
推 neo5277: 幾個小衝刺沒錯啊，但是現在想起來硬體迭代的確考慮要比 03/12 23:51
推 Kroner: B群 03/13 01:42→ neo5277: 較多耶，也不是不能跑但是就是麻煩，一開始要弄得很活 03/12 23:51
→ DrTech: 幾%？ 會用這個詞代表你還在waterfall思考模式啊。 minimu 03/12 23:54
→ DrTech: m "viable" product。 最簡化的"可行性"產品。 是否可行， 03/12 23:54
推 Chricey: 魚油 03/13 01:44→ DrTech: 根本不是%來訂的，沒人知道使用者的20%，100%到底是什麼。 03/12 23:54
→ DrTech: 而且100%的定義隨時變動，才是Scrum與MVP開發的精髓啊。你 03/12 23:54
→ DrTech: 能訂出20%, 100%是什麼，你幹嘛浪費時間用Scrum一直變需求 03/12 23:54
推 Kroner: 馬卡推薦 03/13 01:46→ DrTech: 與優先權。 03/12 23:54
→ DrTech: 就是因為沒人知道100%的產品是什麼，才演化出了Scrum啊。 03/12 23:56
→ DrTech: 頻繁發佈更不是精髓，頻繁發佈只是達成目的的方法手段。Sc 03/13 00:00
→ DrTech: rum精髓：可用最小開發成本，應對當前最有價值的需求，使 03/13 00:00
→ DrTech: 產品價值最大化才是精髓。 03/13 00:00
實務上我不會用%數來評估,但如果老闆比較喜歡%數,我就會想辦法掰%數給他.
只要能適應快速變動的市場,要用%數還是用其他方式決定release時間並不重要吧.
→ DrTech: "敏捷在我看就是把原本一個大瀑布拆成好幾個小瀑布罷了"， 03/13 00:04
→ DrTech: 錯誤的觀念。正確觀念：用"最小成本"，選擇當前"最有價值" 03/13 00:04
→ DrTech: 的小瀑布開發才是重點。 03/13 00:04
→ shooter555: 敏捷的精神應該是同步共享 資訊透明 吧 把瀑布的每一 03/13 00:23
→ shooter555: 階段同步跑 03/13 00:23
→ shooter555: 算了 我也不瞭 大家就敏捷自助餐 各取所需 03/13 00:24
推 OyodoKai: 一堆DT在討論PO跟SM煩惱的東西 甚至是沒有SM的Scrum 03/13 00:25
推 Lhmstu: 軟體新創真的一堆那種，難怪台灣軟體很難起來 03/13 00:43
推 viper9709: 推敏捷式+新創這個組合常常發生問題+1 03/13 01:07
推 strlen: 敏捷這兩個字當初翻譯就有問題了才導致華文圈管理模式亂用 03/13 01:34
→ strlen: 敏捷不是快快快 什麼都講求快 敏捷是短週期頻繁檢視現實需 03/13 01:35
→ strlen: 求 然後修正開發方向 這跟快不快一點關係也沒有 也跟什麼 03/13 01:36
→ strlen: 最小可行性產品一點關係都沒有 敏捷開發真正的精神可以用 03/13 01:36
→ strlen: 在任何一種產品上 就是 短週期檢視小成果 頻繁討論修正方 03/13 01:37
→ strlen: 向 一步一步讓軟體慢慢演化 你整個工期要快要慢跟敏捷一點 03/13 01:37
→ strlen: 關係都沒有 敏捷真正的意思 是讓整個系統的架構更快更容易 03/13 01:38
→ strlen: 做修改 做調整 做擴展 也就是能快速做出改變 快是指這個 03/13 01:39
→ strlen: 要達到這種效果 你的軟體模組化要做好 SOLID原則要用好 設 03/13 01:40
→ strlen: 計模式也要仔細檢討 而且重點不是一股腦全把這些東西尻進 03/13 01:40
→ strlen: 去 你還要判斷哪邊該加入SOLID和設計模式 哪邊不要 以免過 03/13 01:41
→ strlen: 度設計 結果適得其反 所以敏捷非常非常注重架構設計 大區 03/13 01:42
→ strlen: 塊中區塊小區塊的各種設計 也非常非常重視單元測試整合測 03/13 01:42
→ strlen: 試 因為你沒有這些東西怎麼能保證你改了啥 東西不會壞？ 03/13 01:43
→ strlen: 架構設計最麻煩的就是沒有標準答案 你怎麼知道這個部份要 03/13 01:44
推 OyodoKai: 樓上講的敏捷也太高大上了 03/13 01:44
→ strlen: 用哪個設計模式？工廠？還是策略？所以跑敏捷大家要常常吵 03/13 01:45
→ strlen: 架 常常討論 所以要pair programming 要老的帶小的 學徒制 03/13 01:46
→ strlen: 團隊要公開透明 甚至對需求方窗口也要公開透明 03/13 01:46
→ strlen: 對工程師的要求也相當高 光是每個人都一定要寫測試就飽了 03/13 01:47
→ strlen: 敏捷要認真跑 工期絕對比什麼隕石瀑布長啦 03/13 01:47
→ strlen: 這就是真正的敏捷開發 那要魔改亂七八糟的 隨便啦 爽就好 03/13 01:48
→ strlen: 敏捷也不是沒有文件 而是文件輔助用 重點團隊溝通 和與需 03/13 01:49
→ strlen: 求方溝通 緊密合作 公開透明 無所保留 也不要搞什麼政治 03/13 01:49
→ strlen: 反正敏捷最終要達到的最高目標 就是讓系統能更快速的修改 03/13 01:51
→ strlen: 和擴展 而且還不能弄壞 要穩定 那些管理模式都是為了這事 03/13 01:51
→ strlen: 一般瀑布和隕石開發根本做不到快速修改擴展 做到一半要改 03/13 01:52
→ strlen: 因為設計寫死了要改又要花大半時間 而且沒測試 一邊改bug 03/13 01:53
→ strlen: 就一邊出 挖東牆補西牆 最後整鍋都砸了 03/13 01:53
→ strlen: 當然你們很屌用瀑布隕石開發 然後還可以讓系統做到能快速 03/13 01:54
→ strlen: 修改擴展而且也非常穩定測試也都有寫 那你天生神力 03/13 01:55
→ strlen: 要讓產品能夠快速做出改變適應需求還要穩定不能壞掉 這是 03/13 01:58
→ strlen: 要付出代價的 03/13 01:58
推 OyodoKai: 待過成功上市的新創 雖然不是跑真的Scrum 應該也不可能 03/13 02:00
→ strlen: agile這個字其實是靈活上的敏捷 而不是快速上的敏捷 03/13 02:01
→ OyodoKai: 期待隕石開發天生神力保佑 03/13 02:01
→ strlen: 一堆老闆大概看到敏捷 就覺得原文是fast...... 03/13 02:03
→ strlen: 你啥設計都沒有把功能直接從頭寫到尾 這叫fast 最快 03/13 02:04
→ strlen: 但你如果要考慮設計 還要跟同事吵架 東想西想才弄出一個架 03/13 02:04
→ strlen: 構 然後再加上測試 可能花你兩倍以上時間 但要改就很快 03/13 02:05
→ strlen: 你從頭寫到尾的 前面很快 等到後面要改 就是還債囉 03/13 02:05
→ strlen: 我講白一點 這雲三洨的果然雲 老董跟CTO兩個老人真的啥都 03/13 02:06
→ strlen: 不懂在胡說八道 雞同鴨講 其實agile也夠老了也能亂扯一通 03/13 02:07
→ strlen: 什麼scrum造不三洨督三洨的 這跟那有何關係？混業界混幾十 03/13 02:09
→ strlen: 年了 上網搞懂這些管理模式花幾小時而已很難嗎 可悲喔 03/13 02:09
→ strlen: 難怪公司爛成這樣 哈 03/13 02:10
→ OyodoKai: scrum如果真的能滿足老闆(PO) 大家就老老實實跑了 03/13 02:11
→ OyodoKai: 新創基本上都魔改成kanban來接隕石 03/13 02:13
→ strlen: 其實重點還是在達成目標 把產品做成可快速修改的穩定系統 03/13 02:15
→ strlen: 你要自己發明什麼鬼模式都可以 能尻出這種效果就行 03/13 02:16
推 OyodoKai: 老闆要的是賺錢的系統 XD 03/13 02:17
→ strlen: 可快速修改的穩定系統 這可並不容易 應該說 非常困難 03/13 02:17
→ strlen: 你東西不能快速修改 跟不上需求 就賺不了錢 可以改 但不穩 03/13 02:17
→ strlen: 定 客戶體驗爛 一樣不賺錢 所以囉 03/13 02:18
→ OyodoKai: 大部分公司聘不起能做出可快速修改的穩定系統的工程師 03/13 02:18
推 dio0204: 結論：跟共產主義一樣 只有小屁孩相信 03/13 02:45
→ strlen: 也不是什麼共產主義 這就經驗累積的結果 就是這樣 03/13 02:49
→ strlen: 你的目標是開發出能快速修改擴充又穩定的產品 03/13 02:49
→ strlen: 前人累積了許多心酸血淚 最後才試出一套敏捷開發模式 是最 03/13 02:50
→ strlen: 有機會能達成這個目標的 別的模式不是不行喔 就說你屌炸天 03/13 02:50
→ strlen: 自己發明什麼碗糕模式也能達到一樣效果 那算你厲害囉 03/13 02:51
推 OyodoKai: 我覺得該來個scrum九宮格了 形式自由 03/13 02:52
→ strlen: 這葛雲三洨的產品 很明顯就是 能快速修改 但極不穩定 哈哈 03/13 02:53
→ strlen: 敏捷玩一半就會變成這樣 可憐哪 03/13 02:53
噓 B0988698088: 感覺文就別發了 你講的大家早就知道了 03/13 08:47
※ 編輯: hidog (111.241.148.153 臺灣), 03/13/2025 09:24:45
推 luke72: 20%這種事跑mini waterfall也行，沒規定waterfall要100% 03/13 12:18
→ luke72: 再來CTO跟這串文講的都是硬體跟核心，就不適合agile啊 03/13 12:20
推 jack0204: 硬體可以參考Toyota高效工作術，也是敏捷精神 03/13 16:42
→ jack0204: 特斯拉造車也是想方法各種加速 03/13 16:43
推 NDark: 特斯拉造車法就是解決不能接受改變的人 03/13 17:00
→ NDark: 因為馬斯克每個站點都自己盯敢說不的就被ＦＩＲＥ了 03/13 17:01
→ lonelytea: 第一段確實 03/13 17:55
→ superpandal: 不會有無敵的系統出來的 真有也不會甘心獻給一個不是 03/13 18:30
→ superpandal: 自己所有的公司或單位 雖然我自己隨手做的靈活性就不 03/13 18:31
→ superpandal: 錯了 但我絕對不會想做一個讓人可以在技術上躺贏 03/13 18:33
→ superpandal: 並且危害到自己生存的東西 因為人不可盡信 03/13 18:36
→ superpandal: 職場上經驗就是王八蛋人數遠遠超過好人 03/13 18:39
→ superpandal: 故現實上這些東西是不可能完美進行的 不管你打算用幾 03/13 18:48
→ superpandal: % 災難如果可以意料就不是災難 03/13 18:49
→ superpandal: 即便全部沒算漏 但薪水明顯就是不合理 03/13 18:53
推 AudiA4Avant: Toyota 的 Kanban被應用在執行敏捷開發。不等於Toyot 03/13 19:14
→ AudiA4Avant: a是敏捷開發吧 03/13 19:14
→ atst2: Toyota方法比較接近的是Lean吧? 而且要走Toyota方法，前提 03/13 19:42
→ atst2: 相當嚴格, 生產要有完整自動化機制，遇到問題要能隨時叫停 03/13 19:43
→ atst2: 所有問題都要排除後才能往下走. 對於很多企業來說，連前提 03/13 19:45
→ atst2: 要達到都很難... 03/13 19:45
→ dildoe: 要原型肥宅會直接用現成硬體直接盡量用現成套件來拼 03/13 20:08
推 jack0204: 高效工作術不只硬體層面的規劃，還有計劃如何推進 03/13 20:08
→ jack0204: 例如下午要跟多個客戶討論能怎麼減少時間浪費 03/13 20:10
→ jack0204: 怎麼防止問題再犯，都跟敏捷有關，只是它不用敏捷稱呼 03/13 20:11
→ jack0204: 實際上要運用要看你夠不夠格啦，職位不夠想搞什麼都難 03/13 20:12
推 viper9709: 聽起來滿猛的 03/14 00:03
→ superpandal: 樓上有人講的高效工作術我看了大綱 那看起來就是超級 03/14 00:59
→ superpandal: 螺絲釘的概念 什麼思考how前先思考why... 這本身就是 03/14 01:00
→ superpandal: 上層思考的 什麼管好自己的不丟給別人 社會很複雜的 03/14 01:02
→ superpandal: 洗腦人當超級牛馬 高層當棋手下都下不好都沒責任 03/14 01:04
→ superpandal: 況且我不信可以當面問why 最後不是心裡os就是走人 03/14 01:12
→ hegemon: 一直問why到最後就是會被搞..螺絲釘就好好扮演螺絲釘好嗎 03/14 07:52
→ hegemon: ..整天問why只會拖慢速度..等到你真的上位有時間跟資源壓 03/14 07:52
→ hegemon: 力的時候看底下的人一直問why你就會有體會了 03/14 07:52
推 moon2519: 中肯 03/14 08:48
推 CRPKT: 也有些公司會鼓勵工程師了解一下商業脈絡 03/14 08:57
→ CRPKT: 但不是所有工程師都會對這個有興趣 03/14 08:57
推 shadow0326: 鼓勵工程師問聰明的問題，不鼓勵問智障問題 03/14 14:23
→ shadow0326: 至於哪種問題聰明哪種問題智障，我他媽怎麼會知道 03/14 14:23
→ ssccg: 鼓勵工程師通靈，不鼓勵工程師自己亂想 03/14 15:56
→ strlen: 問不問也不是重點 重點是企業有沒有公開透明大家吵架的文 03/14 17:12
→ strlen: 化 什麼事都拿出來吵 拿出來公開討論 包括需求 03/14 17:12
→ strlen: 通常都是表面上講open mind 但是你開口就被記仇 再講你就 03/14 17:13
→ strlen: 被捅 嘻嘻嘻 03/14 17:13
→ strlen: 連真話都不能講 還跑什麼敏捷 敏你個洨 工程師不要刻意塞 03/14 17:14
→ strlen: bug就祖宗保佑惹 甚至也不需要故意塞 就故意粗心一點做事 03/14 17:14
→ gino0717: 桑原老師說過 架是要兩個人才能吵的 03/14 17:19
推 AudiA4Avant: 有的時候有問題的不是方法，而是執行的時候忽略人性 03/15 21:19
推 new122851: 開發測試比至少要1比3，團隊10個開發者，就要搭配30個 03/16 13:22
→ new122851: 測試人員 03/16 13:22
噓 s860134: 通常測試開發比例是1：3 測試是1 03/16 15:09
→ labbat: 抱歉測試人員去幫忙開發了，所以是0 03/16 15:50
推 luke72: 測試？我快十年沒看過公司有測試了… 03/17 21:05
推 atowng: 怎麼還再吵這個？產品品質下降就是事實，使用者哪管你媽媽 03/19 09:55