作者oopFoo (3d)
看板Soft_Job
标题Re: [讨论] 关於敏捷越来越深入台湾职场
时间Fri Jul 26 12:13:55 2024
※ 引述《kuosos520 (kkk)》之铭言：
: 小弟就业大概十来年
: 虽然刚入职场时
: 敏捷开发就已经是很红的议题
: 但至少我前几份专案都还是很传统的瀑布
: 个人感觉是近年越来越明显
: 所有的专案管理方式都越来越朝敏捷的概念走
: 我自己体感
: 比以前痛苦指数提高了很多
痛苦就不是敏捷
: 例如说
: 以前谈好一整个版本的spec
: 要谈时程就是基於一整个版本再谈
: 中间有什麽改动很正常
: 基於是整个版本谈时程
: 大多数还有arrange的空间
: 时程变动就是整体移，不会在一条一条对
: 通常不太会很细节的追进度
: 顶多每周或每天需要跟自己直属报一下
这还比较敏捷
: 最近几年很明显
: 所有的专案管理方式都往敏捷的精神走
: 工作订出来就是丢给工程师问时程
: 没有一个很固定的版本空间
: 就是请你一直做，做到一个程度再确定版本
敏捷跟不确定不相关，这是误解。这种情况其实就是陨石
: 但是需求一直改本来就很正常
: 所以明面上是工程师自己压
: 但其实需求根本不固定
: 所以细项时程根本没参考性
: 每天为了其实很不重要的东西被时间追着跑
压时间就不是敏捷了。
: 早期都是谈1-2个月的版本开发时间
: 需要的话平日加班周末加班赶进度
: 进度状态比较好也可以适度休息一下
: 只要在讲好的时间拿出来，大家都好说话
: 现在偏向每一天都被进度追着跑
: 一个礼拜要报好几次进度
: 时程没对到就说工程师自己定的
再重申一次，定时间是完全违反敏捷的精神。敏捷是预估(forecast)不是设定(promise)
: 以前传统瀑布式自己可以抓放工作
: 有些小东西先放一下以後再处理
: 或是卡关太久需要交代进度
: 就抓个小东西出来作
: 交代完进度再来专心面对魔王关
: 现在敏捷其实
: 不会给你自己安排的空间
: 东西丢出来就要定时程
: 每次都跟你逐条讨论
: 你根本无法自己安排每天要做什麽
: 甚至上下午可能都被定死
流星雨，不是敏捷
: 先不讨论哪一个开发模式对专案品质比较好
: 我也没有那个视野可以讨论这种事情
: 单就痛苦指数来说
: 从工程师角色看，绝对是指数级上升
: 我就很不解
: 为啥很多工程师很热衷於讨论敏捷开发
: 甚至是去学习敏捷开发课程
: 从我的逻辑看
: 相当於工程师用管理者的视角
: 去思考如何压榨自己
: 然後还去实践
因为你被假敏捷压榨。Scrum常常会变成这样，Scrum是压榨员工的好工具，如果滥用的话。
---------------------
敏捷软体开发宣言
https://agilemanifesto.org/iso/zhcht/manifesto.html
个人与互动 重於 流程与工具
可用的软体 重於 详尽的文件
与客户合作 重於 合约协商
回应变化 重於 遵循计划
也就是说，虽然右侧项目有其价值，
但我们更重视左侧项目。
敏捷软体的 12 个原则
https://agilemanifesto.org/iso/zhcht/principles.html
Ron Jefferies有写Scrum的问题，但问题就是使用的人
https://ronjeffries.com/articles/018-01ff/scrum-not-asd-1/
特别有讲sprint压时间是完全违反敏捷的精神。
敏捷的起源是跟"toyota way"很有关系的。实做的人（工程师）要主导开发，换句话说是由下往上。瀑布是由上往下。陨石跟流星雨也都是由上往下。
像我就很不欣赏Jira跟Slack，不是工具不好，但使用起来都是追进度，抓战犯，完全违反敏捷的精神。
敏捷的意义是以人为本，支持工程师，跟客户良好互动，但台湾很多公司都是用敏捷之名行压榨员工之实。
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 111.248.96.54 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1721967243.A.64F.html
1F：推 mercurycgt68: 敏捷是快速取得回馈并持续改善 废物公司只想快速结 07/26 12:22
2F：→ mercurycgt68: 案死不改善 07/26 12:22
3F：推 kuosos520: 你这样讲我勉强认同，唯一一个点，Rd主导开发，但 07/26 12:27
4F：→ kuosos520: 需求还应该给专业的处理吧，我想，jira真的超雷的 07/26 12:27
5F：→ kuosos520: ，slack还比较有用处 07/26 12:27
6F：推 RX1226: 推, 真的大部分的scrum都是雷缺 07/26 12:31
7F：推 APTON: 给原PO:你应该是误解了 "主导" 可参考"安灯系统" 07/26 13:04
8F：推 abccbaandy: 可用的软体 重於 详尽的文件 那可用是谁说的算？ 07/26 13:14
9F：→ Lordaeron: 这样是不用结案的概念。 07/26 13:18
10F：→ LiebeLion: 你说的是理论 他说的是现实 07/26 13:26
11F：→ oopFoo: Linux Kernel就是很好的敏捷案例。APTON大的"安灯系统"比 07/26 13:29
12F：→ oopFoo: 我刚才想打的一串的好，精简清楚。 07/26 13:30
13F：→ alongalone: 说得很好.下次可以直接用贴的.但没有解决实务问题 07/26 13:46
14F：→ Lordaeron: Linux kernel project 是agile? 给一下出处好吧。 07/26 14:05
15F：推 MoonCode: 员工痛苦股东才会爽 07/26 14:09
16F：→ atst2: @Apton, @原Po, 两位的'主导'定义好像跟一般不太一样? 07/26 14:18
17F：→ atst2: 能否详细说明一下，这里的主导是只有出问题时停下来吗? 07/26 14:18
18F：→ atst2: 还是包括专案的成果评估，方向，业务目标在内? 07/26 14:19
19F：→ MOONY135: 大家都说不是敏捷，那那间公司跑的是真敏捷？ 07/26 14:50
20F：→ Lordaeron: 按上方的定义：不用结案的公司。 07/26 15:20
21F：推 ikimerr: 国外公司都受不了被压榨的工作模式，早就已经放弃敏捷开 07/26 15:39
22F：→ ikimerr: 发 07/26 15:39
23F：→ ikimerr: 就台湾人自己越来越盛行www 07/26 15:39
24F：→ Lordaeron: 咦...这个说法，给个出处好吧。 07/26 16:10
25F：推 APTON: @atst2 如果以"做产品"的角度 当然是都要包含 07/26 16:14
26F：→ APTON: 不然最後遇到状况，开发还是会回头去问同样的问题 07/26 16:15
27F：→ APTON: 但是大部分的公司都是分工不合作 各团队的距离很远 07/26 16:16
28F：推 happy8649: 台湾老板眼中的敏捷=你各位员工员工做快一点 07/26 16:50
29F：→ fatb: 怕加班的我把敏捷点满了...还是继续加班 07/26 16:50
30F：→ tzouandy2818: 痛苦就不是敏捷？所以敏捷式宣言包含不能痛苦是不是 07/26 17:38
31F：→ atst2: @APTON, 这个"都要包含"的意思，是指第一线开发者还要兼职 07/26 18:01
32F：嘘 hegemon: 很多时候工程师的立场跟客户就是相对的，这样要怎麽玩下 07/26 18:02
33F：→ hegemon: 去？很多工程师以删客户需求作为自己的kpi. 这样可以良好 07/26 18:02
34F：→ hegemon: 互动？ 07/26 18:02
35F：→ atst2: PM, Market，客服，主管等任务吗? 还是你有别的意思呢? 07/26 18:02
36F：→ atst2: 还望更进一步提供说明. 07/26 18:03
37F：嘘 hegemon: 我看过太多太尊重工程团队的公司，搞到最後就是没有人可 07/26 18:06
38F：→ hegemon: 以叫他们做事 07/26 18:06
39F：→ hegemon: PM, 客服, 主管, 客户通通都不行，最後动用到创办人下来 07/26 18:08
40F：→ hegemon: 盯场，但是在看不见的地方还是偷鸡摸狗，客户干到翻天， 07/26 18:08
41F：→ hegemon: 这样会比较好？ 07/26 18:08
42F：→ hegemon: 理想当然是工程师能够自律，能够以帮助客户解决问题为目 07/26 18:09
43F：→ hegemon: 标，现实就是自律的人太少了..给予工程师过大的自由跟权 07/26 18:09
44F：→ hegemon: 限就是什麽事都做不成 07/26 18:09
45F：推 yuinami: 推 07/26 19:26
46F：→ oopFoo: (顾客，pm，主管）决定功能，工程师决定时间与作法。 07/26 19:35
47F：→ oopFoo: 不过梦想很丰满，现实很骨感。当压力来的时候，加班，压时 07/26 19:36
48F：→ oopFoo: 间，各种非敏捷的作法通通上来，能够彻底执行敏捷的团队还 07/26 19:38
49F：→ oopFoo: 是少。而且敏捷最重要的是所有人都须认同也配合，这也是不 07/26 19:38
50F：→ oopFoo: 容易的。没有良好的团队，或者强力沟通能力的主管，敏捷不 07/26 19:40
51F：→ oopFoo: 容易执行也不容易成功。这有点像社会主义，理念良好，但常 07/26 19:41
52F：→ oopFoo: 常沦落到独裁者模式。敏捷是需要上面的人全力支持，加上所 07/26 19:43
53F：→ oopFoo: 有人的配合才行。国外我看到成功的案例比较多，台湾可能我 07/26 19:44
54F：→ oopFoo: 也是见识少，看到的比较少。 07/26 19:45
55F：→ oopFoo: 敏捷真的就是人的互动才是重点，但人的互动真的是最困难的 07/26 19:46
56F：→ oopFoo: 课题。要愿意信任也是个困难。 07/26 19:48
57F：→ atst2: @oopFoo，如果一个方法论，需要依赖人的素质，才会有用, 这 07/26 19:54
58F：→ atst2: 个方法论能称得上是方法论吗? 07/26 19:55
59F：→ atst2: 反过来问，有没有案例是，有良好的团队但不走敏捷，所以失 07/26 19:56
60F：→ atst2: 败，改用敏捷後就成功了? 07/26 19:56
61F：→ atst2: 还是只要有良好的团队，不论走不走敏捷，其实都无所谓呢? 07/26 19:58
62F：→ oopFoo: 应该说敏捷是成功率比较高的方法，所有方法都有成功的机会 07/26 20:08
63F：→ oopFoo: 但敏捷迭代，多许多机会成功。 07/26 20:10
64F：→ oopFoo: 当初xp的团队，是良好的团队，但最後他们的案子是被取消的 07/26 20:11
65F：→ atst2: 关於方法论是否影响产出，NDark网友有提出 #1MWgps7K 07/26 20:15
66F：→ atst2: 那您这边提到'成功率'比较高，是否也有研究可以参考呢? 07/26 20:16
67F：→ oopFoo: 因为Chrysler被Daimler-Benz买走，新东家有不同想法。 07/26 20:16
68F：→ atst2: 在您继续回覆，我先提一下个人对Agile/Scrum/Lean的想法， 07/26 20:17
69F：→ oopFoo: 老实说，没有研究。这都是我们观察跟想当然尔的 07/26 20:18
70F：→ atst2: 个人觉得敏捷以及相类似的方法论，其实是有一定道理的。 07/26 20:19
71F：→ atst2: 但个人一直觉得，这些方法论，很多还只是理论, 而非定理. 07/26 20:20
72F：→ atst2: 从理论到落实一直有很大的落差，而这些落差，目前看不到相 07/26 20:21
73F：→ atst2: 关推广的人，有想去填补的努力在，而一直是不断强调理论有 07/26 20:22
74F：→ atst2: 多美好. 07/26 20:22
75F：→ atst2: 也许有团队/研究已经在努力了，但个人见识有限，无法知晓. 07/26 20:23
76F：→ atst2: 在这种情况下，去指称某些公司跑的是'假敏捷'，敏捷"不是" 07/26 20:25
77F：→ atst2: 什麽，是没有意义的。因为对於想要进入"敏捷"，享用到好处 07/26 20:26
78F：→ atst2: 的团体而言，他们想要知道的是，弥平理论到实作间的落差的 07/26 20:27
79F：→ atst2: 手段。 07/26 20:27
80F：→ nathanlu: 敏捷好棒棒，每间都说在跑敏捷，需求完成率很高 07/26 20:30
81F：→ atst2: 如果没有这个手段，而只能依赖团队人员素质的话，老实说, 07/26 20:33
82F：→ atst2: 与其引入敏捷，不如去增进HR团队的能力还比较实际一点。 07/26 20:33
83F：→ Lordaeron: 我做上百个大大小小(钱)的案子，人员倒是没有哪些一百 07/26 21:16
84F：→ Lordaeron: 几十的案子。但三五七个倒有。就是没有方法论。 07/26 21:17
85F：→ Lordaeron: 但全部准时收钱。 07/26 21:17
86F：→ Lordaeron: 数学解题，就是从基本的去解就是好的方法。哪些什麽特 07/26 21:18
87F：→ Lordaeron: 解，遇到某类题目有专门快速的解法，就是烂解法。 07/26 21:19
88F：推 howdiee: 只能说牵扯到人的理论在实际上就是会有落差 07/26 21:41
89F：推 Lhmstu: 台湾文化融合的敏捷等於快速结案 07/26 21:47
90F：→ Lordaeron: 很多人都认为，用了某某方法，我也可以做出一样的系统. 07/26 23:20
91F：→ Lordaeron: 正如看着菜谱，人人都是大厨的概念。 07/26 23:22
92F：推 viper9709: 推atst2 07/27 00:03
93F：→ fantasystar: Ron 让我学到很多，感谢分享 07/27 02:35
94F：→ fantasystar: *Ron的文章 07/27 02:36
95F：→ oopFoo: extreme programming系列的书，是一个好入门的书，它提倡 07/27 06:26
96F：→ oopFoo: test first，短时间的迭代，standup meeting，pair 07/27 06:27
97F：→ oopFoo: programming和如何计画，都有很好的解释跟缘由。现在的人 07/27 06:29
98F：→ oopFoo: 使用敏捷大部分都不了解背後的缘由。toytota way，也是一 07/27 06:31
99F：→ oopFoo: 个很好的管理想法，虽然跟软体有点远。 07/27 06:32
100F：→ oopFoo: 好的团队是需要时间去互相磨合，也不是hr找对人就可以的。 07/27 06:39
101F：→ oopFoo: 所以敏捷第一条就是"个人与互动"。这真的是最难的课题。 07/27 06:40
102F：嘘 notimenofree: Jira只是工具 雷在哪 07/27 06:57
103F：→ notimenofree: 错的是用的方式吧 07/27 06:57
104F：→ oopFoo: 最後我想强调的是，敏捷强调的是心态。但理工人喜欢方法， 07/27 07:09
105F：→ oopFoo: 想找SOP，想找工具来解决问题。敏捷宣言就是想告诉你那是 07/27 07:11
106F：→ oopFoo: 次要的。正确的心态才是比较重要的。 07/27 07:13
107F：推 lchcoding: 我看得少.如果 Debug 和带新人 07/27 07:45
108F：→ lchcoding: 不算的话.pair programming 我没看过馁 07/27 07:45
109F：→ lchcoding: 两位程式设计师，写一份码 07/27 07:45
110F：→ lchcoding: 不吵架，可能吗？ 07/27 07:45
111F：→ lchcoding: （当然，平常就是用嘴巴写程式 07/27 07:45
112F：→ lchcoding: 那种不讨论） 07/27 07:45
113F：→ atst2: 我懂了，敏捷就是宗教。站立会议就是早晚课，检讨会议就是 07/27 07:50
114F：→ atst2: 发露忏悔。每次迭代都是一个轮回。好好照着做就可以成佛。 07/27 07:50
115F：→ atst2: 不成的话，就是心态不正，信仰不足。持续做下去就对了。 07/27 07:50
116F：→ oopFoo: pair programming很少见，大部分人不愿意试，主要就是困难 07/27 07:59
117F：→ oopFoo: 问题一起pair，或带新人大家比较愿意做。 07/27 08:01
118F：→ oopFoo: 站立会议，检讨会议现在都太形式化了。开会是要了解跟检讨 07/27 08:02
119F：→ oopFoo: 程式问题。其实两三个人一组，不要超过五六个人参与，简短 07/27 08:06
120F：→ oopFoo: 结束。当变成形式的时候，就是要换个方法做。可惜，现代管 07/27 08:07
121F：→ oopFoo: 理，无法从SOP跳开。敏捷就是团队要找出适合的方法，不需 07/27 08:10
122F：→ oopFoo: 照着教条做。 07/27 08:10
123F：推 z22771187: 国外立意良好的东西进到台湾後都会歪斜 07/27 09:35
124F：推 NDark: pair要好好分组训练 因为这种新制度在学校职场都没教 07/27 09:46
125F：→ NDark: 新制度的引入就跟新机器一样要有教学 07/27 09:46
126F：推 Csongs: 敏捷很容易压榨啊 那个宣言都是强者 敏捷就是很多强者一起 07/27 10:11
127F：→ Csongs: 合作 不会掉棒 07/27 10:11
128F：→ Csongs: 不欣赏工具这段还是怪怪的 抓战犯用excel管也能抓 07/27 10:13
129F：→ tzouandy2818: 信奉敏捷式的人都没有拿研究或数据佐证 只会说你成 07/27 10:14
130F：→ tzouandy2818: 效不彰就是没有敏捷/不够敏捷 论述充满不可证伪性 07/27 10:14
131F：→ oopFoo: excel的好处是，pm花时间填资料就没那麽多时间骚扰工程师 07/27 10:53
132F：推 internetms52: jira是工具，不会扭曲流程，如果流程有问题，不能 07/27 12:18
133F：→ internetms52: 怪jira 07/27 12:18
134F：推 internetms52: jira也可以不压时间啊，是用法问题 07/27 12:21
135F：→ NDark: 某种敏捷有一条规则是"成员都是专家" 而且都假设是全端的 07/27 12:25
136F：推 labbat: 须符合真空状态下，且专家是球体的时候才有效 07/27 12:55
137F：→ sCHb68: 预估根本不准，不然就不会不做不知道一做吓一跳了， 07/27 13:57
138F：→ sCHb68: 待过某家公司，就是把预估当成是设定， 07/27 13:57
139F：→ sCHb68: 一个spint一定要完成，拖延到的话PM还会很不爽。 07/27 13:57
140F：推 lylu: 我还遇过直接把planning 的点数当成kpi的呢 07/27 14:04
141F：推 APTON: 嗯...果然根本没有打算讨论，只是想趁机偷酸，还好没浪费时 07/27 16:32
142F：→ APTON: 间回覆 07/27 16:32
143F：推 kckckckc: 真的，还遇到一个连规格都不会开的在那一般说要导入敏 07/27 17:54
144F：→ kckckckc: 捷xD 07/27 17:54
145F：推 Ghamu: 觉得问题点在於1. 团队了解敏捷开发是什麽？ 2. 团队要知道 07/27 18:41
146F：→ Ghamu: 怎麽执行？ 3. 上头有权力者要相信 了解 决心推动敏捷开发 07/27 18:41
147F：→ Ghamu: 不懂 执行的不是敏捷 没有权力只能推半套 都会爆炸 07/27 18:44
148F：→ Ghamu: 想想人也是很重要的 只有工具也是不可行 再好的工具遇到错 07/27 18:46
149F：→ Ghamu: 的人 不去用或是用错也是白搭 07/27 18:46
150F：→ Lordaeron: AGILE的专家们，请问AGILE 在最开始前，要先写一些底 07/27 19:10
151F：→ Lordaeron: 层的东西吗? 要架环境吗? 要的话，要算进sprint? 07/27 19:11
152F：→ Lordaeron: 会人人都有工作? 还是只有某几位负责? 07/27 19:12
153F：→ Lordaeron: 再来，何时on production? 按国外大神的说法，没提到呢 07/27 19:13
154F：→ Lordaeron: 若成员的程度差异，导致他的工作无法如期完成，会不会 07/27 19:13
155F：→ Lordaeron: 大家都完工了，还要等他? code review 会算进sprint? 07/27 19:14
156F：→ Lordaeron: review 後的modification 要算下一个sprint? 07/27 19:14
157F：→ oopFoo: 1)看团队自己决定，2)人人有工作，3)随时都是production， 07/27 21:35
158F：→ oopFoo: 4)每个人拿自己适合的工作，有问题在standup meeting就要 07/27 21:37
159F：→ oopFoo: 提出，如果还是不能解决，转给可解决的人。如果无人可解， 07/27 21:38
160F：→ oopFoo: 看是要花时间研究，或放弃选另一条路走。 07/27 21:39
161F：→ oopFoo: code review完才算完成，但有的team不用code review。 07/27 21:40
162F：→ oopFoo: 进度其实是检视，而不是要追求的目标。做不到，做不快，就 07/27 21:43
163F：推 s06yji3: 待过4个团队，没有一个agile是跑到起来的XD 07/27 21:44
164F：→ oopFoo: 是砍功能。如何取舍，排进度，一门艺术。 07/27 21:46
165F：→ atst2: #170rfWYy 这是我的旧帐，在2007年的文章. 07/28 00:22
166F：→ atst2: #1I7R-qV6 这是2013年，我在介绍Lean Programming相关书藉 07/28 00:23
167F：→ atst2: 然後在2024年的今天, Agile的传道士们, 没有证据，没有研究 07/28 00:29
168F：→ atst2: 面对我提出的问题，把一切都归结到心态上, 最後再指责有人 07/28 00:29
169F：→ atst2: 藉讨论之名暗酸? 07/28 00:30
170F：→ atst2: 你们是不是真的以为，所有意见不同的人，都没有跑过敏捷 07/28 00:30
171F：→ atst2: 没有在相关领域，花费时间精力，也不知道安灯, toyota是怎 07/28 00:32
172F：→ atst2: 麽回事? 07/28 00:32
173F：→ atst2: 面对他人的质疑，你们的回应有符合敏捷宣言的第一条吗? 07/28 00:34
174F：→ tzouandy2818: 不知道为什麽敏捷式开发要搞得像宗教信仰 07/28 03:44
175F：→ oopFoo: 还是要讲心态很重要。上司，顾客就是陨石，流星雨的需求， 07/28 07:10
176F：→ oopFoo: 不管怎麽敏捷都没用。能够抵抗陨石的需求是第一个关键，沟 07/28 07:14
177F：→ oopFoo: 通再沟通，没其他法子。就算所有都作对了，也不保证成功， 07/28 07:16
178F：→ oopFoo: 开心做事就好了。谋事在人成败由天 07/28 07:18
179F：推 Druid: 推 我们team算是一个成功的敏捷范例 我认同这篇内容 07/28 10:42
180F：→ Druid: 敏捷跑得好 应该是大家都轻松 客户也开心 但是要跑得起来 07/28 10:43
181F：→ Druid: 需要超罩的主管+自律的工程师 人力素质PR95以上 07/28 10:45
182F：→ Druid: 这真的非常不容易 所以失败的敏捷居多 07/28 10:47
183F：推 jacklin2002: 加班过劳死的工程师转生到异世界开始研究敏捷开发 07/28 18:27
184F：推 v86861062: 推推 07/29 16:41
185F：→ shooter555: 能压榨员工的敏捷对老板来说就是好敏捷 07/30 10:44
186F：推 flowerbb: 推这篇 07/31 17:08
187F：→ b25459870: 不太同意没有时程 我觉得是宣言概念 比起压时程 更注重 08/01 17:30
188F：→ b25459870: 团队自发自律 08/01 17:30