推 hegemon: 點數通膨是一大問題，每個人都說這個sprint 要做10點，結 11/27 11:11
→ hegemon: 果每個task估計的點數越來越寬鬆，變成沒做啥事情就達成1 11/27 11:11
→ hegemon: 0點，剩下的時間都在玩耍，美其名叫WLB 11/27 11:11
推 abccbaandy: 目標導向就是這樣囉，最經典的就是用行數，大家就各種 11/27 11:23
→ abccbaandy: 複製貼上... 11/27 11:23
推 chen09885: story point 是估工時人天用的，把KPI掛勾一定爛掉 11/27 11:26
推 jackflu: 亞洲有亞洲的玩法 不能讓大家更窮忙 我們可是不要的 嘻嘻 11/27 11:54
推 jason82714: 笑死 11/27 12:15
→ orangelite: 把 story point 當 KPI，明顯主管就還是沒有把自己的 11/27 12:23
→ orangelite: 腦袋革新。 11/27 12:23
推 soccer103: 笑死 11/27 12:24
→ orangelite: 換一套管理流程，但骨子裡思想沒變。 11/27 12:24
這就是雙言巧語 打著敏捷的名號搞著傳統的管理
你們工程師不是很嚮往歐美那套嗎 這不就來了
推 menShow: 笑死,從一開始就覺得這個到台灣就是垃圾的機制,果然~ 11/27 12:31
→ menShow: 不理解下面的人在做什麼,你用幾百種管理方式都一樣啦~ 11/27 12:33
推 kaibaemon: 東亞文化圈先改變自己的文化再去玩高文明的管理技巧 11/27 12:39
→ buffon: 結果腦袋都在思考公司政治 XDDDDDD 11/27 12:56
推 hobnob: 血淋淋的經驗QQ 11/27 13:07
※ 編輯: SkankHunt42 (37.19.205.163 日本), 11/27/2024 13:10:53
→ AvatarH: 有遇過敏捷一天要報4次工時的 11/27 13:15
→ AvatarH: 以半小時為單位 11/27 13:15
讚 歡迎大家繼續分享鬼故事 真的沒有最扯 只有更扯
※ 編輯: SkankHunt42 (37.19.205.163 日本), 11/27/2024 13:22:00
推 theedge: 笑死 以為在講敝司 11/27 13:41
推 freeloop: 謝謝大家TT 看到這麼慘的 我心情好一些了 11/27 13:45
→ ssccg: 瀑布被汙名化了，那些都是殞石。瀑布其實很爽，就是很死的 11/27 14:47
→ ssccg: 每階段產出完成才進下一階段，要改就是整個翻掉從瀑布頭開 11/27 14:48
→ ssccg: 始，沒有瀑布是水在半空中還倒流一小段的 11/27 14:49
是的 瀑布確實是被隕石汙名化 隕石汙名化完瀑布以後又來汙名化敏捷
其實方法都只是工具 沒有什麼是萬用的
※ 編輯: SkankHunt42 (37.19.205.163 日本), 11/27/2024 14:54:21
→ ssccg: 只有神才能違反物理，有神存在的就是隕石開發 11/27 14:53
推 flash789: 你一定跟我同公司 XD 11/27 15:47
→ flash789: 然後每個sprint結束，要計算該sprint點數除以該sprint上 11/27 15:50
→ flash789: 班時數，下降就表示你偷懶... 11/27 15:50
推 xcawszp: 想笑又有點笑不出來 11/27 16:02
推 c80352: 通貨膨脹笑死 XD 11/27 16:14
推 O187: 2的公司用敏捷改善產能本身就誤會大了 敏捷只會更慢 它的目 11/27 17:33
→ O187: 的不是快 而是不斷地試誤調整 讓最終成品能中途因應局勢變 11/27 17:33
→ O187: 化 或是在沒有方向時找出最後想要走的方向 11/27 17:33
→ O187: 1也是大錯 捷敏的要件就是9人以下的精英組團 非精英勿入呀 11/27 17:34
推 NDark: 樓上正解 敏捷精神是擁抱改變 所以不保證效率會提升 11/27 17:37
→ NDark: 有錯誤期待的管理層引入一個與目標相反的政策 是悲劇來源 11/27 17:38
推 aria0520: 敏捷（應對所有突發狀況和現況改變） 11/27 17:45
→ bndan: story point 當 KPI 這邏輯很直覺 就是做多的貢獻多 XD 但 11/27 17:48
→ bndan: 這種想法納入體制 基本上最後就是逼人與他人合作度降到最低 11/27 17:49
→ bndan: 敏捷本身是怕結果脫離"目標" 所以才會擁抱改變 但這很容易 11/27 17:50
→ bndan: 變成無限加料 然後做出一團和客戶需求完全不同的垃圾... 11/27 17:51
→ MOONY135: 「擁抱改變」 11/27 18:04
推 ppppman: 也遇過一家公司scrum都亂做然後搞績效算kpi 但問題是怎 11/27 18:29
→ ppppman: 麼量化 怎麼評估準確度和公平性 隨便想也一堆漏洞可以提 11/27 18:29
→ ppppman: 出 然後就變成為了績效到處亂看卡 11/27 18:29
推 Lipraxde: 看起來都是用一套新「方法」期待能帶來效益，而不是實 11/27 18:31
→ Lipraxde: 務上去解決問題，以為是方法不對，實際上是場景不適合 11/27 18:31
→ Lipraxde: 、能力不足，可笑的是定方法的人不是做事的人XD 11/27 18:31
推 vi000246: 用bug當kPI本來就很智障 我複製貼上就沒bug了 傻了才重 11/27 18:56
→ vi000246: 構 11/27 18:56
推 louner: 靠背戰力通膨超好笑 很有畫面XDDD 11/27 19:07
→ atst2: 菁英組團，不用敏捷也會成啊!? 這干敏捷屁事? 11/27 20:05
推 viper9709: 戰力通膨www 11/27 23:28
推 ak78912: 敏捷自助餐 11/28 00:53
噓 panda04056: 所以 到底有沒有哪個公司不是亂搞敏捷 隕石當敏捷的啊 11/28 08:52
→ AvatarH: 有敏捷團隊用comment數量當kpi的，討論愈多績效愈差 11/28 08:59
推 Csongs: 很多人把scrum當隨意改規格的方式 11/28 09:03
推 atpx: 我只能說，每家公司資訊部門都一堆類似鬼故事 11/28 11:13
→ DrTech: 看來大家對scrum誤解很深。軟體規格本來就可以隨意改，但 11/28 12:16
→ DrTech: 要管理優先權。每天有進度也沒問題，每天要看KPI或關多少i 11/28 12:16
→ DrTech: ssues也沒問題，但要懂得拆成夠小的ticket，保證每日 軟體 11/28 12:16
→ DrTech: 版本品質。 11/28 12:16
→ DrTech: 無限加料也沒什麼，放在back log就好。推文看到最大的問題 11/28 12:18
→ DrTech: 就是：一堆沒成功經驗的人在亂做scrum。 11/28 12:18
→ DrTech: 另外不是所有軟體都適合scrum。固定規格的接案，waterfall 11/28 12:30
→ DrTech: 會比較適合。常常要變更功能的to C端產品，就很適合scrum 11/28 12:30
→ DrTech: 。 11/28 12:30
→ MOONY135: 那有那個成功案例嗎？ 11/28 12:40
推 abccbaandy: 同樓上，每次都有護航：這不是敏捷、你們誤解敏捷 11/28 13:02
DrTech講的 我大致認同
本來敏捷就比較適合應付經常變動、需持續與客戶溝通理解需求的專案
領域與產品成熟的商品其實不太需要敏捷(避免有人曲解 說明一下不是不能run敏捷)
台灣多數的問題是敏捷自助餐 研發量能我不管 每個任務都是top priority
推 shadow0326: 老實說 你要問台灣有哪個軟體的成功案例 都不見得有答 11/28 13:06
→ shadow0326: 案了 再多加一個"使用敏捷開發"的過濾條件 哪會有答案 11/28 13:06
對資方跟股東來說 能賺錢就是成功的案例
如果你要把什麼人員流動率啦 程式碼品質啦 員工滿意度與WLB、加班時數算進去
那就有點難定義了
※ 編輯: SkankHunt42 (37.19.205.163 日本), 11/28/2024 13:14:09
→ Lordaeron: 我也想知道，什麼樣的案子/專案適合scrum. 11/28 14:40
推 WilliamLFY: 遇過用story point 除工時拿來當kpi 的，sp 還給一堆 11/28 14:52
→ WilliamLFY: 搞不懂狀況的主管定義，結果就是低sp 高工時，最後我 11/28 14:52
→ WilliamLFY: 不爽就離職了 11/28 14:52
推 sealman234: 確實，然後Bug單不能算工時，或者在績效報告時點數 11/28 14:54
→ sealman234: 不能算上Bug單的，所以一堆人害怕寫出Bug都在複製 11/28 14:54
→ sealman234: 貼上，能動就好 11/28 14:54
推 jamesho8743: 同Lordaeron, 到底什麼案子適合scrum? 商業上的案子 11/28 16:04
→ jamesho8743: 有幾件是沒規格的? 11/28 16:04
推 ko27tye: 新創/新產品還找不到獲利模式，邊摸索邊開發可以跑敏捷 11/28 16:16
→ Lordaeron: 新創這說法也很怪，一來屎金出生時，還沒哪麼多新創的 11/28 16:41
→ Lordaeron: 不可能是以新創為生的，再說新創總得要第一個：產品 11/28 16:41
→ Lordaeron: 才能去圈錢。我們以FB/META 為例，當年要是連第一個 11/28 16:42
→ Lordaeron: 可以用的產品/網站都沒有，是怎樣屎金來變需求呢？ 11/28 16:43
→ Lordaeron: 用這思路，加上Dr Tech 的講法，就是先有to C的網路產 11/28 16:44
→ freeloop: 如果只適用新創 那一堆企業推是在？ 11/28 16:44
→ Lordaeron: 品後，後續按C 的變化，去屎金一下。 11/28 16:44
→ Ekmund: 我手上的狀況是 算是很成熟的產品 但太熟了 要管理或更動 11/28 19:40
→ Ekmund: 的effort很大 於是排了個比較大的重構 這種時候就會同時 11/28 19:40
→ Ekmund: 有很確定要什麼 與 有些頗ambiguous的東西 不一定能第一 11/28 19:41
→ Ekmund: 時間界定 這時跑scrum我是覺得蠻合適的 反正都是要持續的 11/28 19:41
→ Ekmund: sync-up與跨各單位去確認business logic來訂規則 11/28 19:41
→ Ekmund: 但之前在遊戲業就沒辦法 個人管個人的 工項永遠爆滿 11/28 19:41
→ Ekmund: 隕石術放不用mp的 根本沒辦法也沒意義去做高頻率的溝通 11/28 19:41
→ Ekmund: 趕快rush出一個東西推次級市場驗證概念比較重要 11/28 19:41
→ WaterLengend: 跟錯老闆產生這種結果，這算眼光問題，還是人品問 11/28 21:04
→ WaterLengend: 題？ 11/28 21:04
