作者SkankHunt42 (凯子爸)
看板Soft_Job
标题Re: [请益] Scrum压榨工程师
时间Wed Nov 27 11:01:40 2024
同感
有人有类似经验的 请不要来认亲 因为跟你绝对不是同公司 谢谢
A公司
执行瀑布式开发已久
但所谓的瀑布式其实就是摸石头过河
因为公司内部没有SA能够制定完整的规格 SA的工作落到TA上
TA写的规格自然是乱七八糟的 东西边做边改 PM QA RD TA都很痛苦
不要问我为什麽叫TA 公司职称职能就是那麽定的
後来公司就引进了"敏捷" 要RD跟TA遵守
意思就是TA继续乱写 RD跟着瞎转 实际上作法跟以前差不多
因为每次规格乱改都叫迭代 听起来更合理
这公司虽然把敏捷挂在嘴上 但PO是什麽 不知道 鸡与猪是什麽 不知道
因为其他部门对产品的细节有各式各样的决策权 但其他部门RUN的不是敏捷
这意味着你在其他部门瀑布的周期瞎迭代几十圈 最後还是要来一次瀑布大改
demo给CEO的时候 CEO可以在QA期再大改一次规格 这也是迭代
没人愿意承担PO的责任 但人人都有PO的权力 人人都为了产品好 人人都有决策权
人人指的是有话语权的人上人 别忘了 你是猪 去割肉作火腿
B公司
也是很敏捷 公司请了个顾问 问顾问要怎麽改进公司的产能
顾问说要KPI量化 主管左思右想 突然想到 阿 你们不是敏捷有story points吗
做完feature得到点数 搞出BUG到客户端要倒扣点数 所以乾脆再加个三四点当安全边际
做多少点数 变成考绩奖金的factor
原本立意良善 却开始了同事间各种诡异吊诡的行径
例如不拆分故事 一开就是一个30点的项目
还有 因为怕这个feature做完可能会因为BUG被倒扣点数
没人想对其他人的code负责 怕改错东西就是直接程式码复制贴上 然後改其中几行
当高层问 怎麽样提升大家的产能 主管就会在考核的时候说
上个年度我们的标准是100点 这个年度希望能做到120点
那方法也很简单 就是跟七龙珠一样战力通货膨胀就好
可能民国两百年我去看 B公司每年人均点数都是几万点
敏捷对我有利的说词、作法我都想要
敏捷我要负责、我不喜欢的 不是改不动就是文化不同
这就是亚洲式敏捷
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 37.19.205.163 (日本)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1732676502.A.EAA.html
※ 编辑: SkankHunt42 (37.19.205.163 日本), 11/27/2024 11:03:45
1F：推 hegemon: 点数通膨是一大问题，每个人都说这个sprint 要做10点，结 11/27 11:11
2F：→ hegemon: 果每个task估计的点数越来越宽松，变成没做啥事情就达成1 11/27 11:11
3F：→ hegemon: 0点，剩下的时间都在玩耍，美其名叫WLB 11/27 11:11
4F：推 abccbaandy: 目标导向就是这样罗，最经典的就是用行数，大家就各种 11/27 11:23
5F：→ abccbaandy: 复制贴上... 11/27 11:23
6F：推 chen09885: story point 是估工时人天用的，把KPI挂勾一定烂掉 11/27 11:26
7F：推 jackflu: 亚洲有亚洲的玩法 不能让大家更穷忙 我们可是不要的 嘻嘻 11/27 11:54
8F：推 jason82714: 笑死 11/27 12:15
9F：→ orangelite: 把 story point 当 KPI，明显主管就还是没有把自己的 11/27 12:23
10F：→ orangelite: 脑袋革新。 11/27 12:23
11F：推 soccer103: 笑死 11/27 12:24
12F：→ orangelite: 换一套管理流程，但骨子里思想没变。 11/27 12:24
这就是双言巧语 打着敏捷的名号搞着传统的管理
你们工程师不是很向往欧美那套吗 这不就来了
13F：推 menShow: 笑死,从一开始就觉得这个到台湾就是垃圾的机制,果然~ 11/27 12:31
14F：→ menShow: 不理解下面的人在做什麽,你用几百种管理方式都一样啦~ 11/27 12:33
15F：推 kaibaemon: 东亚文化圈先改变自己的文化再去玩高文明的管理技巧 11/27 12:39
16F：→ buffon: 结果脑袋都在思考公司政治 XDDDDDD 11/27 12:56
17F：推 hobnob: 血淋淋的经验QQ 11/27 13:07
※ 编辑: SkankHunt42 (37.19.205.163 日本), 11/27/2024 13:10:53
18F：→ AvatarH: 有遇过敏捷一天要报4次工时的 11/27 13:15
19F：→ AvatarH: 以半小时为单位 11/27 13:15
赞 欢迎大家继续分享鬼故事 真的没有最扯 只有更扯
※ 编辑: SkankHunt42 (37.19.205.163 日本), 11/27/2024 13:22:00
20F：推 theedge: 笑死 以为在讲敝司 11/27 13:41
21F：推 freeloop: 谢谢大家TT 看到这麽惨的 我心情好一些了 11/27 13:45
22F：→ ssccg: 瀑布被污名化了，那些都是殒石。瀑布其实很爽，就是很死的 11/27 14:47
23F：→ ssccg: 每阶段产出完成才进下一阶段，要改就是整个翻掉从瀑布头开 11/27 14:48
24F：→ ssccg: 始，没有瀑布是水在半空中还倒流一小段的 11/27 14:49
是的 瀑布确实是被陨石污名化 陨石污名化完瀑布以後又来污名化敏捷
其实方法都只是工具 没有什麽是万用的
※ 编辑: SkankHunt42 (37.19.205.163 日本), 11/27/2024 14:54:21
25F：→ ssccg: 只有神才能违反物理，有神存在的就是陨石开发 11/27 14:53
26F：推 flash789: 你一定跟我同公司 XD 11/27 15:47
27F：→ flash789: 然後每个sprint结束，要计算该sprint点数除以该sprint上 11/27 15:50
28F：→ flash789: 班时数，下降就表示你偷懒... 11/27 15:50
29F：推 xcawszp: 想笑又有点笑不出来 11/27 16:02
30F：推 c80352: 通货膨胀笑死 XD 11/27 16:14
31F：推 O187: 2的公司用敏捷改善产能本身就误会大了 敏捷只会更慢 它的目 11/27 17:33
32F：→ O187: 的不是快 而是不断地试误调整 让最终成品能中途因应局势变 11/27 17:33
33F：→ O187: 化 或是在没有方向时找出最後想要走的方向 11/27 17:33
34F：→ O187: 1也是大错 捷敏的要件就是9人以下的精英组团 非精英勿入呀 11/27 17:34
35F：推 NDark: 楼上正解 敏捷精神是拥抱改变 所以不保证效率会提升 11/27 17:37
36F：→ NDark: 有错误期待的管理层引入一个与目标相反的政策 是悲剧来源 11/27 17:38
37F：推 aria0520: 敏捷（应对所有突发状况和现况改变） 11/27 17:45
38F：→ bndan: story point 当 KPI 这逻辑很直觉 就是做多的贡献多 XD 但 11/27 17:48
39F：→ bndan: 这种想法纳入体制 基本上最後就是逼人与他人合作度降到最低 11/27 17:49
40F：→ bndan: 敏捷本身是怕结果脱离"目标" 所以才会拥抱改变 但这很容易 11/27 17:50
41F：→ bndan: 变成无限加料 然後做出一团和客户需求完全不同的垃圾... 11/27 17:51
42F：→ MOONY135: 「拥抱改变」 11/27 18:04
43F：推 ppppman: 也遇过一家公司scrum都乱做然後搞绩效算kpi 但问题是怎 11/27 18:29
44F：→ ppppman: 麽量化 怎麽评估准确度和公平性 随便想也一堆漏洞可以提 11/27 18:29
45F：→ ppppman: 出 然後就变成为了绩效到处乱看卡 11/27 18:29
46F：推 Lipraxde: 看起来都是用一套新「方法」期待能带来效益，而不是实 11/27 18:31
47F：→ Lipraxde: 务上去解决问题，以为是方法不对，实际上是场景不适合 11/27 18:31
48F：→ Lipraxde: 、能力不足，可笑的是定方法的人不是做事的人XD 11/27 18:31
49F：推 vi000246: 用bug当kPI本来就很智障 我复制贴上就没bug了 傻了才重 11/27 18:56
50F：→ vi000246: 构 11/27 18:56
51F：推 louner: 靠背战力通膨超好笑 很有画面XDDD 11/27 19:07
52F：→ atst2: 菁英组团，不用敏捷也会成啊!? 这干敏捷屁事? 11/27 20:05
53F：推 viper9709: 战力通膨www 11/27 23:28
54F：推 ak78912: 敏捷自助餐 11/28 00:53
55F：嘘 panda04056: 所以 到底有没有哪个公司不是乱搞敏捷 陨石当敏捷的啊 11/28 08:52
56F：→ AvatarH: 有敏捷团队用comment数量当kpi的，讨论愈多绩效愈差 11/28 08:59
57F：推 Csongs: 很多人把scrum当随意改规格的方式 11/28 09:03
58F：推 atpx: 我只能说，每家公司资讯部门都一堆类似鬼故事 11/28 11:13
59F：→ DrTech: 看来大家对scrum误解很深。软体规格本来就可以随意改，但 11/28 12:16
60F：→ DrTech: 要管理优先权。每天有进度也没问题，每天要看KPI或关多少i 11/28 12:16
61F：→ DrTech: ssues也没问题，但要懂得拆成够小的ticket，保证每日 软体 11/28 12:16
62F：→ DrTech: 版本品质。 11/28 12:16
63F：→ DrTech: 无限加料也没什麽，放在back log就好。推文看到最大的问题 11/28 12:18
64F：→ DrTech: 就是：一堆没成功经验的人在乱做scrum。 11/28 12:18
65F：→ DrTech: 另外不是所有软体都适合scrum。固定规格的接案，waterfall 11/28 12:30
66F：→ DrTech: 会比较适合。常常要变更功能的to C端产品，就很适合scrum 11/28 12:30
67F：→ DrTech: 。 11/28 12:30
68F：→ MOONY135: 那有那个成功案例吗？ 11/28 12:40
69F：推 abccbaandy: 同楼上，每次都有护航：这不是敏捷、你们误解敏捷 11/28 13:02
DrTech讲的 我大致认同
本来敏捷就比较适合应付经常变动、需持续与客户沟通理解需求的专案
领域与产品成熟的商品其实不太需要敏捷(避免有人曲解 说明一下不是不能run敏捷)
台湾多数的问题是敏捷自助餐 研发量能我不管 每个任务都是top priority
70F：推 shadow0326: 老实说 你要问台湾有哪个软体的成功案例 都不见得有答 11/28 13:06
71F：→ shadow0326: 案了 再多加一个"使用敏捷开发"的过滤条件 哪会有答案 11/28 13:06
对资方跟股东来说 能赚钱就是成功的案例
如果你要把什麽人员流动率啦 程式码品质啦 员工满意度与WLB、加班时数算进去
那就有点难定义了
※ 编辑: SkankHunt42 (37.19.205.163 日本), 11/28/2024 13:14:09
72F：→ Lordaeron: 我也想知道，什麽样的案子/专案适合scrum. 11/28 14:40
73F：推 WilliamLFY: 遇过用story point 除工时拿来当kpi 的，sp 还给一堆 11/28 14:52
74F：→ WilliamLFY: 搞不懂状况的主管定义，结果就是低sp 高工时，最後我 11/28 14:52
75F：→ WilliamLFY: 不爽就离职了 11/28 14:52
76F：推 sealman234: 确实，然後Bug单不能算工时，或者在绩效报告时点数 11/28 14:54
77F：→ sealman234: 不能算上Bug单的，所以一堆人害怕写出Bug都在复制 11/28 14:54
78F：→ sealman234: 贴上，能动就好 11/28 14:54
79F：推 jamesho8743: 同Lordaeron, 到底什麽案子适合scrum? 商业上的案子 11/28 16:04
80F：→ jamesho8743: 有几件是没规格的? 11/28 16:04
81F：推 ko27tye: 新创/新产品还找不到获利模式，边摸索边开发可以跑敏捷 11/28 16:16
82F：→ Lordaeron: 新创这说法也很怪，一来屎金出生时，还没哪麽多新创的 11/28 16:41
83F：→ Lordaeron: 不可能是以新创为生的，再说新创总得要第一个：产品 11/28 16:41
84F：→ Lordaeron: 才能去圈钱。我们以FB/META 为例，当年要是连第一个 11/28 16:42
85F：→ Lordaeron: 可以用的产品/网站都没有，是怎样屎金来变需求呢？ 11/28 16:43
86F：→ Lordaeron: 用这思路，加上Dr Tech 的讲法，就是先有to C的网路产 11/28 16:44
87F：→ freeloop: 如果只适用新创 那一堆企业推是在？ 11/28 16:44
88F：→ Lordaeron: 品後，後续按C 的变化，去屎金一下。 11/28 16:44
89F：→ Ekmund: 我手上的状况是 算是很成熟的产品 但太熟了 要管理或更动 11/28 19:40
90F：→ Ekmund: 的effort很大 於是排了个比较大的重构 这种时候就会同时 11/28 19:40
91F：→ Ekmund: 有很确定要什麽 与 有些颇ambiguous的东西 不一定能第一 11/28 19:41
92F：→ Ekmund: 时间界定 这时跑scrum我是觉得蛮合适的 反正都是要持续的 11/28 19:41
93F：→ Ekmund: sync-up与跨各单位去确认business logic来订规则 11/28 19:41
94F：→ Ekmund: 但之前在游戏业就没办法 个人管个人的 工项永远爆满 11/28 19:41
95F：→ Ekmund: 陨石术放不用mp的 根本没办法也没意义去做高频率的沟通 11/28 19:41
96F：→ Ekmund: 赶快rush出一个东西推次级市场验证概念比较重要 11/28 19:41
97F：→ WaterLengend: 跟错老板产生这种结果，这算眼光问题，还是人品问 11/28 21:04
98F：→ WaterLengend: 题？ 11/28 21:04
99F：推 v86861062: 哈哈哈 11/28 21:54
100F：推 kurtsgm: 跟错老板这种事情不能怪员工 你各位如果独具慧眼又有远见 11/28 22:06
101F：→ kurtsgm: 自己出来当老板早就发财了 当啥员工 11/28 22:06
102F：推 CodefarmerX: 推通货膨胀，笑死XD 11/28 23:58
103F：→ Lordaeron: 当老板有慧眼就可以，不用资金和人脉？ 11/29 09:40
104F：推 newbiepolice: 点数通膨真的超好笑，一直逼点数搞到大家都高估 12/01 15:30
105F：→ superpandal: 烂公司太多 所以无所谓跟不跟对老板 因为你要糊口 12/01 16:51
106F：→ superpandal: 你就没有多少好的选择 12/01 16:52
107F：→ superpandal: 所以天眼通很重要 不然你就得有门路知道这些东西 12/01 16:56
108F：→ superpandal: 当老板当然要有资金和人脉 但没有慧眼只是造虐而已 12/01 16:59
109F：→ superpandal: 乱花钱都是事小 干坏事才事大 福份消耗很快 12/01 17:00
110F：→ superpandal: 分 12/01 17:01
111F：推 c0758: 有梗XDDD 12/02 23:31
112F：推 oyyyo: 我以为看到我前公司哈哈哈哈 12/03 18:57
113F：推 shortoneal: 基本上没有任何能成功量化软体工程师的KPI指标 12/05 11:46
114F：→ shortoneal: 只要一个顾问进到软体团队喊着KPI量化，87%是神棍，不 12/05 11:46
115F：→ shortoneal: 然就是无脑的PO/PM 12/05 11:47
116F：推 uncleben006: story point 怎麽会是估工时用的？ 01/01 00:42