→ alongalone: 因為推的人都是傳道者 07/25 10:37
→ infinitlee: 這只是披著敏捷開發實際上是waterfall的變體 07/25 10:41
推 fishfish1314: 敏捷(X) 隕石(O) 07/25 10:42
推 KyuubiKulama: 敏捷不是要有個有經驗的PM來帶比較好嗎 07/25 10:49
推 ghost90331: 這就要看思考角度了，單純只想領薪水的話敏捷很痛苦 07/25 10:50
推 Lhmstu: 因為推的人，只負責開會 07/25 10:57
推 lonelytea: 還要浪費時間開會 白吃東西 07/25 10:58
推 brucetu: 工程師的談判力不如管理職，不管你換什麼玩法這個本質不 07/25 10:58
→ brucetu: 會改變 07/25 10:58
→ brucetu: 工程師精於解決需求，管理職精於靠嘴壓榨出價值，不論哪 07/25 11:00
→ brucetu: 種開發方法都不能扭轉這樣的利益關係 07/25 11:00
→ brucetu: 最簡單的，你敢不敢拿著需求去跟你帶的新人說，這個本來 07/25 11:01
→ brucetu: 一個月要完成的東西麻煩你們趕工一下兩個禮拜完成 07/25 11:01
→ brucetu: 然後再轉頭跟上面報告說這個沒有一個半月做不出來 07/25 11:02
推 gino0717: 現在路邊的貓貓狗狗都可以直接跑去找工程師押時程了 07/25 11:24
推 nayeonmywife: 當然是方便插單跟臨時改scope呀 07/25 11:28
推 abccbaandy: 因為老闆聽到敏捷就高潮阿...你痛不痛苦關他屁事 07/25 11:28
→ abccbaandy: PM也爽，需求講不清楚可以說我們是敏捷 07/25 11:29
→ abccbaandy: 每天一堆會搞得好像很忙 有在做事 07/25 11:30
→ stepnight: 一堆打著敏捷開發，實際上整天浪費時間開會 07/25 11:36
推 fg008kimo: 就是一種新的壓榨手法阿 老闆聽到當然開心 07/25 11:36
推 johnbill: 習慣就好 07/25 11:47
→ johnbill: 整天在那邊裝忙 07/25 11:47
推 Abbee: 你這不是敏捷 是隕石石開發法 真正的敏捷是目標小又明確 07/25 11:48
→ Abbee: 全力在短時內作出來 而不是亂改 07/25 11:48
→ Abbee: 而且成員是全職在寫 本來就不給你自己安排想作別的 07/25 11:49
推 WaterLengend: 需求不明確不叫敏捷，這叫隕石 07/25 11:57
推 SHANGOYANYI: 那些熱衷的通常是想轉PM的開發XD 07/25 11:58
推 Obama19: 就是產出最大化啊 不把人當人看 當工具用 07/25 12:03
→ MOONY135: 插單+hotfix+milestone都要同時間做好喔，做不完的時候 07/25 12:04
→ MOONY135: 還可以說給工程師自由規劃工作時間的空間了。 07/25 12:04
推 NTUTM04: 比較痛苦的瀑布式開發 07/25 12:07
推 chen09885: 根本沒有敏捷，只是換個名詞繼續催你而已 07/25 12:15
→ holmes2136: 其實對於QA也是折磨,例如regression testing只給了更 07/25 12:16
→ holmes2136: 短的時間跑整個流程 07/25 12:16
→ bill0205: 會強調敏捷的80%都是隕石 07/25 12:19
→ kuosos520: 有時候不一定強調敏捷這個名稱，只是業界大多往這 07/25 12:23
→ kuosos520: 個方向走了 07/25 12:23
推 Ghamu: 你們是不是都沒用jira之類的管理工具然後一直用開會對進度 07/25 12:26
→ Ghamu: 的方式做事？ 07/25 12:26
推 Ghamu: 我們公司說穿也是常常什麼週會連站會都在細究進度 07/25 12:28
→ kuosos520: 用jira，走敏捷精神，還是一樣， 07/25 12:29
→ kuosos520: 問題不是實踐方法 07/25 12:29
→ kuosos520: 是被被短時程追著跑的痛苦 07/25 12:29
→ kuosos520: 我感覺用什麼工具都差不多，就這種精神很反人性 07/25 12:30
推 Ghamu: 看到你說一直報進度 感覺是不是浪費很多時間開會 07/25 12:30
→ kuosos520: 我總有燃燒自己的時間跟融化的時間 07/25 12:30
→ kuosos520: 不能一直讓我燃燒 07/25 12:30
→ Ghamu: 我倒不覺得反人性 敏捷應該是及早發現及早治療 我前公司我 07/25 12:31
→ Ghamu: 們做了一個軟體做超久 丟上市場才發現沒半個用 07/25 12:31
→ Ghamu: 要是能小步快跑 早點驗證早點發現不對 我們就不用浪費時間 07/25 12:32
→ Ghamu: 了 07/25 12:32
→ kuosos520: 那是公司的角度看，不是工程師的角度看 07/25 12:33
→ kuosos520: 工程師的時間有換到薪水，就不是浪費時間，除非你 07/25 12:33
→ kuosos520: 說你創業 07/25 12:33
→ Ghamu: 那感覺你應該多抓一點自己的buffer吧 順風就提早做完 不順 07/25 12:34
→ Ghamu: 就on time 這樣對管理方也比較好暗算 07/25 12:34
→ Ghamu: 也可以請假吧 需要休息就好好休息 07/25 12:34
→ Ghamu: 另外我沒記錯的話敏捷精神不是要大家專注在一個sprint上嗎 07/25 12:35
→ Ghamu: ？你怎麼有很多進度要追 07/25 12:35
→ kuosos520: 不討論細節跟實踐方式，是指目前大多往這個方向做 07/25 12:37
→ kuosos520: 管理 07/25 12:37
→ kuosos520: 敏捷到底應該怎樣，窩不知道，窩只知道比瀑布痛苦 07/25 12:37
→ kuosos520: 很多 07/25 12:37
→ panda04056: 因為大部分公司是假敏捷啊 只會站立咪聽+隕石 07/25 12:40
→ Ghamu: 我覺得很多都是假敏捷 搞錯重點弄成他不舒服我也很痛苦的樣 07/25 12:40
→ Ghamu: 子 07/25 12:40
→ alan3100: 道理簡單 跨過學習門檻後公司競爭力會提升很多 07/25 12:42
推 NDark: Scrum Master就是小PM的變形 07/25 12:54
→ NDark: 不過我現在都不講敏捷 都化整為零直接精算時間 07/25 12:56
→ NDark: 你要一天就上版也行 那少掉的測試時間自己要負責任 07/25 12:56
→ NDark: 沒有測試人員的組織 基本上是輕視測試這項專業 07/25 12:57
→ NDark: 甚麼叫做 "開發人員應該..." 那都是一種不負責任的話術 07/25 12:58
→ NDark: 年紀越大我越覺得有個專門的品管人員會很安心 07/25 12:59
推 NDark: 很多開發人員認為測試人員不會測 那只是打資訊落差而已 07/25 13:01
→ NDark: 如果在開發過程中測試人員提早進場做測試計畫 07/25 13:01
→ NDark: 那麼測試人員的準備不一定會比開發人員少 07/25 13:02
推 googoo1102: 假scrum 真daily review, push進度 會議又超時 07/25 13:02
→ NDark: 差異就在於成本 (不好意思離題了講一堆) 07/25 13:02
推 miloisgood: 最近也遇到 跟原po深有同感 07/25 13:09
推 CRPKT: 你知道十家公司一般會有十一種敏捷跑法嗎 07/25 13:14
推 gmoz: 這不是敏捷的問題 是你公司制度的問題 看起來不是敏捷 07/25 13:16
→ gmoz: 時間是在grooming跟planing時就決定的 也是左移提早發現問題 07/25 13:17
→ gmoz: 做到一半改需求改AC 這看起來根本沒有敏捷 07/25 13:17
推 NDark: "那是因為沒有執行真正的敏捷" 07/25 13:20
→ BoXeX: 真正的敏捷只存在於幻想中吧 07/25 13:21
→ BoXeX: 人不是機器 每天叫你全力 最好能做到 07/25 13:26
→ BoXeX: 又不是國外可以按時休長假 07/25 13:26
推 vencil: 本來就是來壓榨出工程師生產力的機制... 07/25 13:28
→ MOONY135: 最後可能發現真正的敏捷速度比瀑布還慢XDDD 07/25 13:31
→ abccbaandy: 敏捷的總時程本來就會比瀑布慢啊... 07/25 13:34
推 wsad50232: 想要用一條鞭的方式管理，結局就是悲劇 07/25 13:37
→ alan3100: 敏捷不會比較快 只是一種管理方式 不會讓工作變少 07/25 13:42
→ alan3100: 主要是提早發現隨時調整 暴露隱藏成本 07/25 13:43
→ alan3100: 瀑布最糟方向錯了最後60分也沒有 敏捷邊做邊調能80分 07/25 13:44
推 CRPKT: 不知道原 po 只是想上來抱怨一下還是想改變現狀 07/25 13:47
推 ko27tye: 瀑布方向錯了也能一顆隕石砸成80分阿 07/25 13:48
→ CRPKT: 抱怨的話大家可以陪嘴一下，想改變就跳槽吧 07/25 13:48
推 NDark: 上面說的對 其實敏捷並不保證快 敏捷是保證"逐步"趨近需求 07/25 13:52
→ alan3100: 不太可能吧XD 砸成80分可能是花200分工的後果 07/25 13:52
→ atst2: 問題在於, 團隊中最應該瞭解需求，最能反應改變的，會是工 07/25 14:16
→ atst2: 程師嗎? 07/25 14:17
→ atst2: 如果不是，那團隊中誰該負責去明確需求? 07/25 14:18
→ atst2: 不管瀑布還是敏捷, 需求還不明確就要求訂時程，都不合理吧? 07/25 14:20
推 NDark: Product Owner可是有明確定義的喔 這點沒錯 07/25 14:31
→ NDark: 能決定事情的這個人必須進入團隊 老闆在外圍點菜就失格 07/25 14:32
推 jyunwei: 因為這是瀑布群 07/25 14:35
推 k7ji91ab5m: 敏捷可以快速反應變化 瀑布不行 想請問原PO假設 07/25 15:22
→ k7ji91ab5m: 你們現在回到瀑布是可行的嗎? 週期多長呢? 07/25 15:22
→ k7ji91ab5m: 那麼做到一半有需求改變了 工程師可以拒絕嗎? 07/25 15:23
推 NDark: 這樣不能比應該要設定 兩個禮拜的瀑布vs兩個禮拜的敏捷 07/25 15:33
→ NDark: 或是半年的瀑布vs半年一個sprint的敏捷 這樣才能比出差異 07/25 15:33
推 shadow0326: 你的描述看起來不像敏捷 07/25 15:37
推 APTON: 你和你的公司都不熟敏捷和瀑布，倒是都很懂隕石XD 07/25 16:03
推 jack0204: 敏捷不是在追進度，是你們公司認為的敏捷是那樣而已 07/25 16:10
推 viper9709: 推這篇&二樓07/25 16:25
→ DrizztMon: 這篇重點到真的不是敏捷式開發 07/25 16:26
→ DrizztMon: 有效率的工作模式當然包含壓榨勞工的心力阿 07/25 16:26
→ DrizztMon: 你可以為了錢拚老命 也可以自己設定工作步調 07/25 16:27
→ DrizztMon: 反正我們只是打工仔 要自己決定平衡點阿 07/25 16:28
推 holebro: 假敏捷 07/25 17:14
→ ku399999: 這不是敏捷，只是錯誤理解沒被糾正而已 07/25 18:11
我覺得有些荒謬的是
很多人反應的是，這不是敏捷
那我想反問，敏捷是什麼？
就我而言
追求快速跌代，就是敏捷開發
至於怎麼實現，每個地方都不一樣
就算瀑布開發
每個公司，每個部門，甚至每個專案
流程一定都不一樣
難道有一些固定形式必須滿足才能稱為XXX模式
這怎麼感覺變成哲學問題
我認知
垂直運作是瀑布
快速跌代是敏捷
而且單就工程師角度看
追求快速跌代這個精神，本身就比較折磨人
※ 編輯: kuosos520 (1.200.249.3 臺灣), 07/25/2024 18:40:39
→ lazarus1121: 以前三天做完的喊一禮拜，改成三小時做完喊一天而已 07/25 18:35
→ lazarus1121: 唯一的差別就是每天站會很浪費時間，耽誤拉屎跟看盤 07/25 18:35
推 kwanles: 在台灣的敏捷 大概都會變成壓榨工具 壓迫開發時程 07/25 18:38
→ lazarus1121: 敏捷是給pm或po失敗的藉口之一 07/25 18:46
→ lazarus1121: 最好有工程師會喜歡敏捷XD 07/25 18:46
推 johney719: 台灣只有隕石式開發 07/25 18:46
推 keel90135: 隕石：找我? 07/25 19:11
→ infinitlee: 你認為的敏捷開發跟別人認為敏捷的開發，雙方起始點就 07/25 19:19
→ infinitlee: 不一定相同。某個pm認為的敏捷開發是在一個sprint不斷 07/25 19:20
→ infinitlee: 變動需求，但工程師要能夠快速反應，這也能稱為快速跌 07/25 19:21
→ infinitlee: 代。上線後有問題，就在下一個sprint再來調整。 07/25 19:21
→ infinitlee: 這樣的敏捷開發，是原po認定的敏捷開發嗎? 07/25 19:22
→ infinitlee: 敏捷開發會因為不同環境而有所異動，但大部分公司說的 07/25 19:23
→ infinitlee: 敏捷開發就只是單純的壓榨跟抱怨工程師速度不夠快，不 07/25 19:23
→ infinitlee: 夠敏捷。但有定義好每個sprint的目標是什麼? 07/25 19:24
推 NDark: 我覺得在相同的buffer比例之下 不會比較折磨人 07/25 19:25
→ kuosos520: 回覆樓上，只要是開發中快速跌代我都認知是偏敏捷 07/25 19:26
→ kuosos520: 的管理模式 07/25 19:26
→ NDark: 敏捷開發有一個條件是 "擁抱改變" 07/25 19:26
→ NDark: 也就是說敏捷開發的成員 心態上 就不要太把規格改變放心上 07/25 19:27
→ NDark: 也就是說心態反倒是要訓練改變為 "你改我就下一周期開時程" 07/25 19:27
→ infinitlee: 那使用waterfall開發，就無法快速跌代嗎?一定要用敏捷 07/25 19:27
→ infinitlee: 才能快速跌代? 07/25 19:28
→ NDark: 改越多越好 等於是PO自己不在意時程問題 07/25 19:28
→ NDark: 敏捷開發比較適合那種老闆不知道怎麼準確描述需求的案子 07/25 19:28
→ NDark: 所以只好一步步改 07/25 19:28
→ NDark: 對於大型系統的模仿案就不應該用敏捷 因為參考對象已經有了 07/25 19:29
→ NDark: 模仿案反而在意時程問題 因為要搶時間趕快上線 07/25 19:30
→ infinitlee: 今天真的使用waterfall，難道就真的先等SA,SD把文件寫 07/25 19:30
→ infinitlee: 好，pg才進來開發嗎?其實也沒有，難道今天需求有變動 07/25 19:30
→ infinitlee: pg能說文件先改好，我才能動程式，其實也沒有阿 07/25 19:31
→ NDark: 確實有PG說你規格不完全接露我無法開發 通常是資料庫人員 07/25 19:32
→ infinitlee: @NDark，因為DBA通常就是你給我什麼我就做甚麼 07/25 19:33
→ NDark: 敏捷的規格可以模糊(少)一點 只滿足現在想得到的規格 07/25 19:33
→ NDark: 若不在意變化那就很有敏捷精神了.那就是他改歸他改.任我行. 07/25 19:34
無意爭辯
這樣偏瀑布
https://tinyurl.com/y93q5nr6
這樣偏敏捷
https://tinyurl.com/ybbqoexd
→ alongalone: 因為推的人都是傳道者 07/25 10:37
→ infinitlee: 這只是披著敏捷開發實際上是waterfall的變體 07/25 10:41
推 fishfish1314: 敏捷(X) 隕石(O) 07/25 10:42
推 KyuubiKulama: 敏捷不是要有個有經驗的PM來帶比較好嗎 07/25 10:49
推 ghost90331: 這就要看思考角度了，單純只想領薪水的話敏捷很痛苦 07/25 10:50
推 Lhmstu: 因為推的人，只負責開會 07/25 10:57
推 lonelytea: 還要浪費時間開會 白吃東西 07/25 10:58
→ brucetu: 會改變 07/25 10:58
→ brucetu: 工程師精於解決需求，管理職精於靠嘴壓榨出價值，不論哪 07/25 11:00
→ brucetu: 種開發方法都不能扭轉這樣的利益關係 07/25 11:00
→ brucetu: 最簡單的，你敢不敢拿著需求去跟你帶的新人說，這個本來 07/25 11:01
→ brucetu: 一個月要完成的東西麻煩你們趕工一下兩個禮拜完成 07/25 11:01
→ brucetu: 然後再轉頭跟上面報告說這個沒有一個半月做不出來 07/25 11:02
推 gino0717: 現在路邊的貓貓狗狗都可以直接跑去找工程師押時程了 07/25 11:24
推 nayeonmywife: 當然是方便插單跟臨時改scope呀 07/25 11:28
推 abccbaandy: 因為老闆聽到敏捷就高潮阿...你痛不痛苦關他屁事 07/25 11:28
→ abccbaandy: PM也爽，需求講不清楚可以說我們是敏捷 07/25 11:29
→ abccbaandy: 每天一堆會搞得好像很忙 有在做事 07/25 11:30
→ stepnight: 一堆打著敏捷開發，實際上整天浪費時間開會 07/25 11:36
推 fg008kimo: 就是一種新的壓榨手法阿 老闆聽到當然開心 07/25 11:36
推 johnbill: 習慣就好 07/25 11:47
→ johnbill: 整天在那邊裝忙 07/25 11:47
推 Abbee: 你這不是敏捷 是隕石石開發法 真正的敏捷是目標小又明確 07/25 11:48
→ Abbee: 全力在短時內作出來 而不是亂改 07/25 11:48
→ Abbee: 而且成員是全職在寫 本來就不給你自己安排想作別的 07/25 11:49
推 WaterLengend: 需求不明確不叫敏捷，這叫隕石 07/25 11:57
推 SHANGOYANYI: 那些熱衷的通常是想轉PM的開發XD 07/25 11:58
推 Obama19: 就是產出最大化啊 不把人當人看 當工具用 07/25 12:03
→ MOONY135: 插單+hotfix+milestone都要同時間做好喔，做不完的時候 07/25 12:04
→ MOONY135: 還可以說給工程師自由規劃工作時間的空間了。 07/25 12:04
推 NTUTM04: 比較痛苦的瀑布式開發 07/25 12:07
推 chen09885: 根本沒有敏捷，只是換個名詞繼續催你而已 07/25 12:15
→ holmes2136: 其實對於QA也是折磨,例如regression testing只給了更 07/25 12:16
→ holmes2136: 短的時間跑整個流程 07/25 12:16
→ bill0205: 會強調敏捷的80%都是隕石 07/25 12:19
→ kuosos520: 有時候不一定強調敏捷這個名稱，只是業界大多往這 07/25 12:23
→ kuosos520: 個方向走了 07/25 12:23
推 Ghamu: 你們是不是都沒用jira之類的管理工具然後一直用開會對進度 07/25 12:26
→ Ghamu: 的方式做事？ 07/25 12:26
推 Ghamu: 我們公司說穿也是常常什麼週會連站會都在細究進度 07/25 12:28
→ kuosos520: 用jira，走敏捷精神，還是一樣， 07/25 12:29
→ kuosos520: 問題不是實踐方法 07/25 12:29
→ kuosos520: 是被被短時程追著跑的痛苦 07/25 12:29
→ kuosos520: 我感覺用什麼工具都差不多，就這種精神很反人性 07/25 12:30
推 Ghamu: 看到你說一直報進度 感覺是不是浪費很多時間開會 07/25 12:30
→ kuosos520: 我總有燃燒自己的時間跟融化的時間 07/25 12:30
→ kuosos520: 不能一直讓我燃燒 07/25 12:30
→ Ghamu: 我倒不覺得反人性 敏捷應該是及早發現及早治療 我前公司我 07/25 12:31
→ Ghamu: 們做了一個軟體做超久 丟上市場才發現沒半個用 07/25 12:31
→ Ghamu: 要是能小步快跑 早點驗證早點發現不對 我們就不用浪費時間 07/25 12:32
→ Ghamu: 了 07/25 12:32
→ kuosos520: 那是公司的角度看，不是工程師的角度看 07/25 12:33
→ kuosos520: 工程師的時間有換到薪水，就不是浪費時間，除非你 07/25 12:33
→ kuosos520: 說你創業 07/25 12:33
→ Ghamu: 那感覺你應該多抓一點自己的buffer吧 順風就提早做完 不順 07/25 12:34
→ Ghamu: 就on time 這樣對管理方也比較好暗算 07/25 12:34
→ Ghamu: 也可以請假吧 需要休息就好好休息 07/25 12:34
→ Ghamu: 另外我沒記錯的話敏捷精神不是要大家專注在一個sprint上嗎 07/25 12:35
→ Ghamu: ？你怎麼有很多進度要追 07/25 12:35
→ kuosos520: 不討論細節跟實踐方式，是指目前大多往這個方向做 07/25 12:37
→ kuosos520: 管理 07/25 12:37
→ kuosos520: 敏捷到底應該怎樣，窩不知道，窩只知道比瀑布痛苦 07/25 12:37
→ kuosos520: 很多 07/25 12:37
→ panda04056: 因為大部分公司是假敏捷啊 只會站立咪聽+隕石 07/25 12:40
→ Ghamu: 我覺得很多都是假敏捷 搞錯重點弄成他不舒服我也很痛苦的樣 07/25 12:40
→ Ghamu: 子 07/25 12:40
→ alan3100: 道理簡單 跨過學習門檻後公司競爭力會提升很多 07/25 12:42
推 NDark: Scrum Master就是小PM的變形 07/25 12:54
→ NDark: 不過我現在都不講敏捷 都化整為零直接精算時間 07/25 12:56
→ NDark: 你要一天就上版也行 那少掉的測試時間自己要負責任 07/25 12:56
→ NDark: 沒有測試人員的組織 基本上是輕視測試這項專業 07/25 12:57
→ NDark: 甚麼叫做 "開發人員應該..." 那都是一種不負責任的話術 07/25 12:58
→ NDark: 年紀越大我越覺得有個專門的品管人員會很安心 07/25 12:59
推 NDark: 很多開發人員認為測試人員不會測 那只是打資訊落差而已 07/25 13:01
→ NDark: 如果在開發過程中測試人員提早進場做測試計畫 07/25 13:01
→ NDark: 那麼測試人員的準備不一定會比開發人員少 07/25 13:02
推 googoo1102: 假scrum 真daily review, push進度 會議又超時 07/25 13:02
→ NDark: 差異就在於成本 (不好意思離題了講一堆) 07/25 13:02
推 miloisgood: 最近也遇到 跟原po深有同感 07/25 13:09
推 CRPKT: 你知道十家公司一般會有十一種敏捷跑法嗎 07/25 13:14
推 gmoz: 這不是敏捷的問題 是你公司制度的問題 看起來不是敏捷 07/25 13:16
→ gmoz: 時間是在grooming跟planing時就決定的 也是左移提早發現問題 07/25 13:17
→ gmoz: 做到一半改需求改AC 這看起來根本沒有敏捷 07/25 13:17
推 NDark: "那是因為沒有執行真正的敏捷" 07/25 13:20
→ BoXeX: 真正的敏捷只存在於幻想中吧 07/25 13:21
→ BoXeX: 人不是機器 每天叫你全力 最好能做到 07/25 13:26
→ BoXeX: 又不是國外可以按時休長假 07/25 13:26
推 vencil: 本來就是來壓榨出工程師生產力的機制... 07/25 13:28
→ MOONY135: 最後可能發現真正的敏捷速度比瀑布還慢XDDD 07/25 13:31
→ abccbaandy: 敏捷的總時程本來就會比瀑布慢啊... 07/25 13:34
推 wsad50232: 想要用一條鞭的方式管理，結局就是悲劇 07/25 13:37
→ alan3100: 敏捷不會比較快 只是一種管理方式 不會讓工作變少 07/25 13:42
→ alan3100: 主要是提早發現隨時調整 暴露隱藏成本 07/25 13:43
→ alan3100: 瀑布最糟方向錯了最後60分也沒有 敏捷邊做邊調能80分 07/25 13:44
推 CRPKT: 不知道原 po 只是想上來抱怨一下還是想改變現狀 07/25 13:47
推 ko27tye: 瀑布方向錯了也能一顆隕石砸成80分阿 07/25 13:48
→ CRPKT: 抱怨的話大家可以陪嘴一下，想改變就跳槽吧 07/25 13:48
推 NDark: 上面說的對 其實敏捷並不保證快 敏捷是保證"逐步"趨近需求 07/25 13:52
→ alan3100: 不太可能吧XD 砸成80分可能是花200分工的後果 07/25 13:52
→ atst2: 問題在於, 團隊中最應該瞭解需求，最能反應改變的，會是工 07/25 14:16
→ atst2: 程師嗎? 07/25 14:17
→ atst2: 如果不是，那團隊中誰該負責去明確需求? 07/25 14:18
→ atst2: 不管瀑布還是敏捷, 需求還不明確就要求訂時程，都不合理吧? 07/25 14:20
推 NDark: Product Owner可是有明確定義的喔 這點沒錯 07/25 14:31
→ NDark: 能決定事情的這個人必須進入團隊 老闆在外圍點菜就失格 07/25 14:32
推 jyunwei: 因為這是瀑布群 07/25 14:35
推 k7ji91ab5m: 敏捷可以快速反應變化 瀑布不行 想請問原PO假設 07/25 15:22
→ k7ji91ab5m: 你們現在回到瀑布是可行的嗎? 週期多長呢? 07/25 15:22
→ k7ji91ab5m: 那麼做到一半有需求改變了 工程師可以拒絕嗎? 07/25 15:23
推 NDark: 這樣不能比應該要設定 兩個禮拜的瀑布vs兩個禮拜的敏捷 07/25 15:33
→ NDark: 或是半年的瀑布vs半年一個sprint的敏捷 這樣才能比出差異 07/25 15:33
推 shadow0326: 你的描述看起來不像敏捷 07/25 15:37
推 APTON: 你和你的公司都不熟敏捷和瀑布，倒是都很懂隕石XD 07/25 16:03
推 jack0204: 敏捷不是在追進度，是你們公司認為的敏捷是那樣而已 07/25 16:10
推 viper9709: 推這篇&二樓07/25 16:25
→ DrizztMon: 這篇重點到真的不是敏捷式開發 07/25 16:26
→ DrizztMon: 有效率的工作模式當然包含壓榨勞工的心力阿 07/25 16:26
→ DrizztMon: 你可以為了錢拚老命 也可以自己設定工作步調 07/25 16:27
→ DrizztMon: 反正我們只是打工仔 要自己決定平衡點阿 07/25 16:28
推 holebro: 假敏捷 07/25 17:14
→ ku399999: 這不是敏捷，只是錯誤理解沒被糾正而已 07/25 18:11
→ lazarus1121: 以前三天做完的喊一禮拜，改成三小時做完喊一天而已 07/25 18:35
→ lazarus1121: 唯一的差別就是每天站會很浪費時間，耽誤拉屎跟看盤 07/25 18:35
推 kwanles: 在台灣的敏捷 大概都會變成壓榨工具 壓迫開發時程 07/25 18:38
→ lazarus1121: 敏捷是給pm或po失敗的藉口之一 07/25 18:46
→ lazarus1121: 最好有工程師會喜歡敏捷XD 07/25 18:46
推 johney719: 台灣只有隕石式開發 07/25 18:46
推 keel90135: 隕石：找我? 07/25 19:11
→ infinitlee: 你認為的敏捷開發跟別人認為敏捷的開發，雙方起始點就 07/25 19:19
→ infinitlee: 不一定相同。某個pm認為的敏捷開發是在一個sprint不斷 07/25 19:20
→ infinitlee: 代。上線後有問題，就在下一個sprint再來調整。 07/25 19:21
→ infinitlee: 這樣的敏捷開發，是原po認定的敏捷開發嗎? 07/25 19:22
→ infinitlee: 敏捷開發會因為不同環境而有所異動，但大部分公司說的 07/25 19:23
→ infinitlee: 敏捷開發就只是單純的壓榨跟抱怨工程師速度不夠快，不 07/25 19:23
→ infinitlee: 夠敏捷。但有定義好每個sprint的目標是什麼? 07/25 19:24
推 NDark: 我覺得在相同的buffer比例之下 不會比較折磨人 07/25 19:25
→ kuosos520: 回覆樓上，只要是開發中快速跌代我都認知是偏敏捷 07/25 19:26
→ kuosos520: 的管理模式 07/25 19:26
→ NDark: 敏捷開發有一個條件是 "擁抱改變" 07/25 19:26
→ NDark: 也就是說敏捷開發的成員 心態上 就不要太把規格改變放心上 07/25 19:27
→ NDark: 也就是說心態反倒是要訓練改變為 "你改我就下一周期開時程" 07/25 19:27
→ infinitlee: 那使用waterfall開發，就無法快速跌代嗎?一定要用敏捷 07/25 19:27
→ infinitlee: 才能快速跌代? 07/25 19:28
→ NDark: 改越多越好 等於是PO自己不在意時程問題 07/25 19:28
→ NDark: 敏捷開發比較適合那種老闆不知道怎麼準確描述需求的案子 07/25 19:28
→ NDark: 所以只好一步步改 07/25 19:28
→ NDark: 對於大型系統的模仿案就不應該用敏捷 因為參考對象已經有了 07/25 19:29
→ NDark: 模仿案反而在意時程問題 因為要搶時間趕快上線 07/25 19:30
→ infinitlee: 今天真的使用waterfall，難道就真的先等SA,SD把文件寫 07/25 19:30
→ infinitlee: 好，pg才進來開發嗎?其實也沒有，難道今天需求有變動 07/25 19:30
→ infinitlee: pg能說文件先改好，我才能動程式，其實也沒有阿 07/25 19:31
→ NDark: 確實有PG說你規格不完全接露我無法開發 通常是資料庫人員 07/25 19:32
→ infinitlee: @NDark，因為DBA通常就是你給我什麼我就做甚麼 07/25 19:33
→ NDark: 敏捷的規格可以模糊(少)一點 只滿足現在想得到的規格 07/25 19:33
→ NDark: 若不在意變化那就很有敏捷精神了.那就是他改歸他改.任我行. 07/25 19:34
→ NDark: 就我的經驗 規格差一點 資料庫關聯開起來會差很多 07/25 19:35
→ infinitlee: 然後就會有人出來說專案品質很差，程式品質很差 07/25 19:35
→ infinitlee: 原po若開發快速跌代就是敏捷開發，那你應該也只有取你 07/25 19:37
→ NDark: 效能很差就繼續改.這也是PO要自己承受. 07/25 19:37
→ infinitlee: 覺得有意義的地方，而忽略整各精神 07/25 19:37
→ lazarus1121: 敏捷我怎麼聽都覺得是現在遊戲的EA模式 07/25 19:38
→ lazarus1121: 硬要套在開發上只能說推的人根本沒開發過 07/25 19:38
→ lazarus1121: 最好瀑布式開發spec開完團隊下次見面就是成品交付了 07/25 19:38
→ ku399999: 不是 大家不用這麼激動 把變動造成的影響通通丟給RD負責 07/25 19:40
→ NDark: 除了時程週期長短之外 兩者差在哪裡? 我認為是完整規格揭露 07/25 19:40
→ ku399999: 是錯的 這應該所有人認知都一致吧 07/25 19:40
→ NDark: 敏捷允許一次只接露一點(瞎子摸象) 07/25 19:40
→ infinitlee: 原po貼的連結是理論，但跟現實實作相距甚遠 07/25 19:41
→ NDark: 瀑布式因為時程長揭露的比較多這個週期開始就往產品奔跑了 07/25 19:41
→ NDark: 所以我認為差異最大是在PO能否把目標描述清楚 07/25 19:41
推 Csongs: 差異只是在不用等所有需求都釐清才開始做而已 07/25 19:42
→ NDark: 如果一開始就能描述100%(抄襲作) 那時程長短就不是問題 07/25 19:42
→ NDark: 如果PO很難把事情講清楚或這項產品沒有參考作品那適合敏捷 07/25 19:42
→ lazarus1121: 允許蝦子摸象只是模糊po的責任罷了 07/25 19:45
→ lazarus1121: 我還遇過要我一起參加產品發想的XD 07/25 19:45
推 NDark: 長週期能投注在設計上的時間多 所以能揭露/思考多一點再幹 07/25 19:45
→ NDark: 樓樓上 有一條是 "每個成員都是專家" ,老闆不專業只好花錢 07/25 19:46
→ lazarus1121: 所以我就說敏捷是分散po責任的開發方式啊 07/25 19:50
→ lazarus1121: 所以這樣的模式對開發來說沒啥幫助 07/25 19:50
→ MOONY135: 敏捷的奧義是不管規格怎樣改 開發周期都已經訂好了嗎? 07/25 19:53
→ MOONY135: 真的有人敢跟上面說 因為你改了規格所以之前承諾的時間 07/25 19:53
→ MOONY135: 不算嗎? 07/25 19:53
推 NDark: 新規格就下一個週期再作啊 這跟瀑布與敏捷無關 07/25 19:54
→ NDark: 瀑布也不可能作出沒講好的規格 07/25 19:55
→ infinitlee: @MOONY135，這時候就會把這各異動放到下一個sprint 07/25 19:56
→ NDark: 只是短周期比較好轉向改規格彈性比較大(心態) 07/25 19:56
→ MOONY135: 之前遇過某PM 弄出來的東西不能開發 07/25 20:01
→ MOONY135: 開發周一邊順需求一邊先改寫 然後讓他去改文件的 07/25 20:01
→ MOONY135: 最後pm還是說就算改了做法也是這個開發周要完成 07/25 20:01
推 CRPKT: 回到原 po 的論點好了，假設敏捷就是這個樣子 07/25 20:02
→ MOONY135: 新的規格順好都周三下班了 剩兩天開發 07/25 20:02
→ lazarus1121: 敏捷的問題就是道理都很多 07/25 20:02
→ lazarus1121: 但開發真的實作起來就跟小瀑布沒啥兩樣 07/25 20:02
→ CRPKT: 那原 po 可能性格上就是不喜歡這樣，也沒什麼不對 07/25 20:02
→ CRPKT: 那問題是，然後呢？原 po 想改變什麼嗎 07/25 20:03
→ CRPKT: 如果想改變，原 po 也說了不想管工程以外的東西 07/25 20:04
→ CRPKT: 那必然無法在組織內部造成影響，所以就只有換環境了 07/25 20:05
→ Abbee: 原PO的圖沒錯, 但每個sprint都要重訂時程 07/25 21:20
→ fgh81113: 你有沒有想過是你的問題 時間就這麼多 速度就這樣 做 07/25 22:03
→ fgh81113: 不來就是做不來 有沒有嘗試說不行 07/25 22:03
→ ku399999: 這根本不是敢不敢的問題吧 一個sprint就1-4週 改到生不 07/25 22:34
→ ku399999: 出來當然是要資源 要人要時間啊 07/25 22:35
→ ku399999: 敏捷不是剩兩天但我大改需求你照樣要生給我吧 07/25 22:36
推 ktasl: 沒有 Scrum Master 就不要說自己敏捷了好嗎 07/25 23:09
→ ktasl: 有 Scrum Master 還把需求跟會議搞成這樣就叫 SM 出來面對 07/25 23:10
→ kuosos520: 我剛剛想了一下，樓上的說法有點類似如果沒有用nod 07/25 23:44
→ kuosos520: e.js就不要說你會Javascript這樣 07/25 23:44
→ Ghamu: 如果需求變動不改時程 此例一開不管是否敏捷以後都很難過吧 07/25 23:53
推 newking761: 因為好交差啊 07/26 00:00
推 wulouise: 啊？你一次要做很多事怎麼敏捷？單位都是用周算的吧 07/26 00:13
推 popcool: 你這就真的不是敏捷，所謂快速迭代指的是需求拆小快速實 07/26 00:49
→ popcool: 現並上線，不是把時間塞滿就叫敏捷好嗎。不同需求之間也 07/26 00:49
→ popcool: 會有幾天修整期，另外，開發時間給工程端喊，啊你自己要 07/26 00:49
→ popcool: 喊這麼緊有意外就自己吞很正常，如果是需求變動那就是時 07/26 00:49
→ popcool: 間重拉這你們團隊要有共識 07/26 00:49
推 lchcoding: 要不改時程，可以啊 07/26 00:57
→ lchcoding: 壓“最後需求變動時間” 07/26 00:57
→ lchcoding: 過了，就進入閉關狀態了 07/26 00:57
→ lchcoding: 其他，等出來再說 07/26 00:57
推 LuLuCow: 唯一推薦「敏捷總舵主-Hermes」 07/26 01:50
推 hengsao: 這是假敏捷 我們團隊也是這樣 超痛苦 07/26 03:00
推 kwanles: 之前遇到的都是時程不能變 需求 規格一直變.. 07/26 05:29
→ Nitricacid: 敏捷(x) 流星雨(o) 07/26 08:12
推 Nitricacid: 說原 po 這不是敏捷 阿敏捷就 10 間公司有 11 種方案 07/26 08:25
→ Nitricacid: 實際上敏捷只有殼沒有料 根本給喇叭嘴唬爛進度推卸 07/26 08:25
→ Nitricacid: 責任用的 我現在都只要改規格就把時間往後估 陪這 07/26 08:25
→ Nitricacid: 些喇叭嘴慢慢耗 07/26 08:25
→ ssccg: 台灣公司做的才不是敏捷，是需求亂改時間不能再多 07/26 10:36
噓 gmoz: 啊你們現在流程就離敏捷太遠了啊 跟你自己的定義沒什麼關係 07/26 10:42
→ gmoz: 快速迭代是目的 你們達到目的的手段就是隕石小瀑布 07/26 10:43
→ gmoz: 手段差這麼多 哪裡算敏捷??? 07/26 10:43
→ TSMCfabXX: 有一種敏捷 = 老闆叫你做甚麼你就做甚麼 07/26 10:46
→ TSMCfabXX: 這種敏捷不叫做敏捷 07/26 10:46
→ ssccg: 能達成快速迭代且工程師沒靠北才叫敏捷 07/26 11:06
推 NDark: "老闆叫你做甚麼你就做甚麼" 這就是工作(雇傭) 07/26 11:07
→ ssccg: 只是追求快速迭代不論方法，那就是流星雨也可以啊 07/26 11:07
→ NDark: "用我的方法滿足雇主需求" 這叫委託(承攬) 07/26 11:07
→ ssccg: 你說的瀑布其實也不對，瀑布就是每階段要切得乾淨，需求一 07/26 11:14
→ ssccg: 直改並不正常，只能整個做完，或開發全推翻回去設計重來 07/26 11:15
→ ssccg: 基本上你就是從時程長的隕石，轉到時程短的流星雨而已 07/26 11:16
推 gmoz: 瀑布裡面不是水 是隕石群～～ 07/26 11:29
→ LiebeLion: 就一堆無能高層覺得新東西很潮 07/26 13:24
→ LiebeLion: 實際上都是隕石開發 07/26 13:24
推 answermangtr: 你是對的 台灣搞敏捷的一堆都效率更差 笑死 07/26 16:18
推 asdf121250: 真的 打著敏捷旗幟 PM把他要做的工作帶到每次會一請大 07/26 18:24
→ asdf121250: 家「討論」 PM根本就會議提醒機器人 07/26 18:24
噓 KanzakiHAria: 隕石不要裝敏捷 07/26 21:21
→ viper9709: 瀑布裡不是水而是隕石群XDDD 07/26 23:58
推 prag222: 潮阿,可以拿來嘴砲,業界常態拉 07/27 05:08
推 molopo: 假敏捷 07/27 05:56
推 avmm9898: 敏捷開發就是別人要敏捷一點的意思 07/27 09:34
→ z22771187: AGI點高，寫程式會比較快嗎 07/27 09:36
→ Firstshadow: 幹真的 每天都被進度追== 07/27 11:33
→ bndan: 敏捷的本質不是這樣 但是敏捷的"做法" 到是學的8成像 只能 07/27 17:40
→ bndan: 說最終就是求最高壓榨是真 但這也是軍備競賽產生的..只能說 07/27 17:41
→ bndan: 合作的本質是競爭+合作 而當重點放在前者時 就會壓力爆增.. 07/27 17:41
推 npkalala: 同意三樓，多得是用敏捷在跑瀑布開發。還看過PO在sprint 07/27 20:43
→ npkalala: 快結束還插單整個story硬說是bug的 07/27 20:44
推 mepowerlmay: 傳產 比較不會管這些歐 07/27 23:21
推 Litfal: 你的敏捷怎麼怪怪的 07/27 23:32
推 acenova: 恭喜悟得台式敏捷 07/29 14:41
→ shooter555: 敏捷開發就是叫開發者敏捷一點 燃盡圖就是要把你燃盡 07/30 10:41
推 yuiweq1999: 推2樓XD 07/30 16:49
→ ChungLi5566: 我這邊長官技術底的 也為了搏名聲搞敏捷 07/31 08:26
→ ChungLi5566: 大家也都做做樣子而已 實際上就一個人開發 是要怎麼 07/31 08:27
→ ChungLi5566: 敏捷 07/31 08:27
→ ChungLi5566: 一個人當ScrumMaster 自己拆Sprint 自己開發自己檢 07/31 08:31
→ ChungLi5566: 視自己每日跟自己開會 07/31 08:31
推 jiujibye: 有感 沒有喘息空間 07/31 18:09
推 Verse: 討厭 +1 ，總是那些不把手弄髒又要名聲的人在推 07/31 19:53
推 kaibaseto: 同樣一套管理工具在不同文化傳統的地方用 08/01 02:07
→ kaibaseto: 想起英國試用中國式的教育也讓英國學生受不了 08/01 02:08
推 JFLung9536: 我自己就是敏捷開發的實踐者 08/01 10:24
→ JFLung9536: 我變動規格的速度與幅度 08/01 10:24
→ JFLung9536: 常常比客戶跟主管還快 08/01 10:24
→ JFLung9536: 都是我追著客戶跟主管要工作 08/01 10:24
→ JFLung9536: 所以主管不太會追我進度 08/01 10:24
→ his8891: 台商就只會學國外的學半套：敏捷壓榨在台灣適用。WFH在台 08/05 06:20
→ his8891: 不適用，這裡不是歐美 08/05 06:20