作者hidog (.....)
看板Soft_Job
标题Re: [讨论] 故 CTO 对於 Scrum 的看法
时间Wed Mar 12 15:14:17 2025
※ 引述《JasperChang (PeterChou)》之铭言：
: Scrum 造不出车、造不出火箭、做不出 IC，可能甚至连台电视都做不出来。
: 但我也同意在某些情境下 Scrum 是很好的工具，
: 特斯拉车上有三套电脑，
: 车控和自驾电脑完全符合 ISO16949 和 ISO26262 的严格规范，
: 每一行程式码都经过严格的静态分析和解析、测试才能 deploy；
: 负责 UI 的 MCU 电脑
: 就真的是没事一直更新一直打 patch 一直有新 feature 一直有 bug 一直给人惊喜。
: 但我认为我们的摄影机凡是牵涉到串流的软体，
: 都是核心功能，不应该走得太激进。
: 但你在处理 PIP 和 SS 功能时并不这麽认为。
: ------
: 小弟刚接触软工只听说 Scrum 强无敌只是你不会用用不好
: 上面资深技术长的看法是不是有修正余地?
先聊一下为什麽会有敏捷式开发
软体市场环境变动快,规格容易说改就改
今天开发功能A,用waterfull方式开发
开发完後发现功能A没多少人用,市场主要竞品重点放在功能B
要改做B也来不及了,产品直接GG
敏捷式开发的方式大概是做功能A,但不会做到100%,
可能做个20%有概念性产品时就先丢出来给合作厂商试用
做个40%有个雏形後丢试用版出来蒐集使用者回馈
如果这时候发现功能A回馈不如预期,提早修正或是放弃功能A
对新创(尤其是软体)来讲,最重要的是活下来
新创缺少资源,会需要尽快做出东西方便老板募资等等等
但敏捷式+新创这个组合常常发生问题
例如很多人说敏捷式开发容易缺少文件
因为敏捷式开发是尽快生出能动的东西,功能又常常说变就变
对工程人员来讲,我写了功能A的开发文件,结果一个月後功能A被放弃
那我写文件写心酸的吗?
同时因为功能常常说改就改,时程又压得很紧
工程师大量靠work around做出能动的东西
久了以後软体到处都是地雷,怎麽改都是修不完的bug
这时候很容易进入一个状况...
公司缺少资金,出不起高薪或是扩编增加员工数量
软体bug多时程紧,导致常常需要加班,工作环境变差
工程师受不了离职,因为缺少文件,导致新进工程师找不到参考资料
下git blame结果看到一堆已离职员工的名字,想问都找不到人问
新进工程师阵亡率高,公司产品每次更新都一堆bug,进入死亡恶性循环
以上应该是很多人都遇过的真实情况.
云云CTO个人感觉是这样....
CTO写了一个计画,掰了一个计画名字(因为老板喜欢看起来很潮的名字?)
内容推测是分析哪些程式模组容易产生bug,分析後进行重构
针对常用功能写文件,消化TODO list等等
结果这个计画被老板否决,外加拔权限泼脏水等,导致CTO受了一肚子委屈...
至於到底是scrum还是waterfall,说实话不重要
混用的开发模式也不是没有,这两个东西并不是二分法的关系
scrum也不是什麽万灵丹,台湾一堆老板都把陨石开发包装成敏捷式开发
然後一天到晚丢陨石下来...|||
敏捷点满也躲不过连续陨石攻击阿 XD
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 111.241.177.240 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1741763659.A.775.html
1F：→ atst2: 更根本的问题是,不论号称是scrum还是waterfall,最基本的 03/12 15:19
2F：→ atst2: 分析, 设计，开发，测试，维护有没有缺漏? 03/12 15:19
3F：→ atst2: 目前观察下来，不论scrum/waterfall,很多团队是连分析都没 03/12 15:20
4F：推 gino0717: 我觉得测试部门应该要有更大的话语权 应该要有个 03/12 15:21
5F：→ atst2: 有，市场调查也不做，直接"我觉得是这样"就往後跑了... 03/12 15:21
6F：→ gino0717: CT(test)O 东西没稳不准出去 03/12 15:21
7F：→ gino0717: 不然就像二哥守荆州 你不知道哪天会出包整天抖 03/12 15:22
8F：推 abccbaandy: 问题是大部分敏捷也是要做100%...问就是都要做 03/12 15:58
9F：→ abccbaandy: 根本不是啥MVP，超完整的 03/12 15:59
10F：→ stepnight: 有没有scrum，套啥框架，不生文件都一样XDD 03/12 16:09
11F：→ ChungLi5566: 想走敏捷就看空X 同时建好几个火箭 试飞成功就把其他 03/12 16:16
12F：→ ChungLi5566: 建到一半的舍弃掉 03/12 16:16
13F：推 kuosos520: 躺平打工仔主点防御，照顾好自己，敏捷是游击队的 03/12 16:16
14F：→ kuosos520: 事 03/12 16:16
15F：→ hidog: 敏捷但又要100%就没敏捷的意义了吧orz 03/12 16:28
16F：推 OyodoKai: 大部分都 kanban 跑起来而已 03/12 16:41
17F：推 ktasl: 敏捷有文件 不可能没有文件 难道需求拆分不算文件？ 03/12 17:09
18F：推 abccbaandy: 有文件又怎样，jira只写个标题也算开ticket阿 03/12 17:13
19F：→ hidog: 要有能支援开发的文件... 03/12 17:24
20F：→ ssccg: 他们可是原本JIRA跑好好的，老板说要改用便利贴和实体板 03/12 19:30
21F：推 shadow0326: 什麽是100%? 从来没看过任何产品是100%的 03/12 20:11
22F：→ labbat: 开发部门有权直接关闭议题，管你稳不稳东西就是要推出去的 03/12 22:12
23F：嘘 dream1124: 敏捷的重点不是什麽做个20%概念吧。重点是定期频繁发布 03/12 23:43
24F：→ dream1124: 然後冲次过程不要随便乱改计划，好让大家能按一定节奏 03/12 23:44
25F：→ dream1124: 共同前进。你一个大愿景只做20%是能试出什麽水温？ 03/12 23:45
26F：→ dream1124: 更何况就算瀑布式也能先做基础版上市後续再修改。 03/12 23:47
27F：→ dream1124: 敏捷在我看就是把原本一个大瀑布拆成好几个小瀑布罢了 03/12 23:47
28F：推 neo5277: 几个小冲刺没错啊，但是现在想起来硬体迭代的确考虑要比 03/12 23:51
29F：→ neo5277: 较多耶，也不是不能跑但是就是麻烦，一开始要弄得很活 03/12 23:51
30F：→ DrTech: 几%？ 会用这个词代表你还在waterfall思考模式啊。 minimu 03/12 23:54
31F：→ DrTech: m "viable" product。 最简化的"可行性"产品。 是否可行， 03/12 23:54
32F：→ DrTech: 根本不是%来订的，没人知道使用者的20%，100%到底是什麽。 03/12 23:54
33F：→ DrTech: 而且100%的定义随时变动，才是Scrum与MVP开发的精髓啊。你 03/12 23:54
34F：→ DrTech: 能订出20%, 100%是什麽，你干嘛浪费时间用Scrum一直变需求 03/12 23:54
35F：→ DrTech: 与优先权。 03/12 23:54
36F：→ DrTech: 就是因为没人知道100%的产品是什麽，才演化出了Scrum啊。 03/12 23:56
37F：→ DrTech: 频繁发布更不是精髓，频繁发布只是达成目的的方法手段。Sc 03/13 00:00
38F：→ DrTech: rum精髓：可用最小开发成本，应对当前最有价值的需求，使 03/13 00:00
39F：→ DrTech: 产品价值最大化才是精髓。 03/13 00:00
实务上我不会用%数来评估,但如果老板比较喜欢%数,我就会想办法掰%数给他.
只要能适应快速变动的市场,要用%数还是用其他方式决定release时间并不重要吧.
40F：→ DrTech: "敏捷在我看就是把原本一个大瀑布拆成好几个小瀑布罢了"， 03/13 00:04
41F：→ DrTech: 错误的观念。正确观念：用"最小成本"，选择当前"最有价值" 03/13 00:04
42F：→ DrTech: 的小瀑布开发才是重点。 03/13 00:04
43F：→ shooter555: 敏捷的精神应该是同步共享 资讯透明 吧 把瀑布的每一 03/13 00:23
44F：→ shooter555: 阶段同步跑 03/13 00:23
45F：→ shooter555: 算了 我也不了 大家就敏捷自助餐 各取所需 03/13 00:24
46F：推 OyodoKai: 一堆DT在讨论PO跟SM烦恼的东西 甚至是没有SM的Scrum 03/13 00:25
47F：推 Lhmstu: 软体新创真的一堆那种，难怪台湾软体很难起来 03/13 00:43
48F：推 viper9709: 推敏捷式+新创这个组合常常发生问题+1 03/13 01:07
49F：推 strlen: 敏捷这两个字当初翻译就有问题了才导致华文圈管理模式乱用 03/13 01:34
50F：→ strlen: 敏捷不是快快快 什麽都讲求快 敏捷是短周期频繁检视现实需 03/13 01:35
51F：→ strlen: 求 然後修正开发方向 这跟快不快一点关系也没有 也跟什麽 03/13 01:36
52F：→ strlen: 最小可行性产品一点关系都没有 敏捷开发真正的精神可以用 03/13 01:36
53F：→ strlen: 在任何一种产品上 就是 短周期检视小成果 频繁讨论修正方 03/13 01:37
54F：→ strlen: 向 一步一步让软体慢慢演化 你整个工期要快要慢跟敏捷一点 03/13 01:37
55F：→ strlen: 关系都没有 敏捷真正的意思 是让整个系统的架构更快更容易 03/13 01:38
56F：→ strlen: 做修改 做调整 做扩展 也就是能快速做出改变 快是指这个 03/13 01:39
57F：→ strlen: 要达到这种效果 你的软体模组化要做好 SOLID原则要用好 设 03/13 01:40
58F：→ strlen: 计模式也要仔细检讨 而且重点不是一股脑全把这些东西尻进 03/13 01:40
59F：→ strlen: 去 你还要判断哪边该加入SOLID和设计模式 哪边不要 以免过 03/13 01:41
60F：→ strlen: 度设计 结果适得其反 所以敏捷非常非常注重架构设计 大区 03/13 01:42
61F：→ strlen: 块中区块小区块的各种设计 也非常非常重视单元测试整合测 03/13 01:42
62F：→ strlen: 试 因为你没有这些东西怎麽能保证你改了啥 东西不会坏？ 03/13 01:43
63F：→ strlen: 架构设计最麻烦的就是没有标准答案 你怎麽知道这个部份要 03/13 01:44
64F：推 OyodoKai: 楼上讲的敏捷也太高大上了 03/13 01:44
65F：→ strlen: 用哪个设计模式？工厂？还是策略？所以跑敏捷大家要常常吵 03/13 01:45
66F：→ strlen: 架 常常讨论 所以要pair programming 要老的带小的 学徒制 03/13 01:46
67F：→ strlen: 团队要公开透明 甚至对需求方窗口也要公开透明 03/13 01:46
68F：→ strlen: 对工程师的要求也相当高 光是每个人都一定要写测试就饱了 03/13 01:47
69F：→ strlen: 敏捷要认真跑 工期绝对比什麽陨石瀑布长啦 03/13 01:47
70F：→ strlen: 这就是真正的敏捷开发 那要魔改乱七八糟的 随便啦 爽就好 03/13 01:48
71F：→ strlen: 敏捷也不是没有文件 而是文件辅助用 重点团队沟通 和与需 03/13 01:49
72F：→ strlen: 求方沟通 紧密合作 公开透明 无所保留 也不要搞什麽政治 03/13 01:49
73F：→ strlen: 反正敏捷最终要达到的最高目标 就是让系统能更快速的修改 03/13 01:51
74F：→ strlen: 和扩展 而且还不能弄坏 要稳定 那些管理模式都是为了这事 03/13 01:51
75F：→ strlen: 一般瀑布和陨石开发根本做不到快速修改扩展 做到一半要改 03/13 01:52
76F：→ strlen: 因为设计写死了要改又要花大半时间 而且没测试 一边改bug 03/13 01:53
77F：→ strlen: 就一边出 挖东墙补西墙 最後整锅都砸了 03/13 01:53
78F：→ strlen: 当然你们很屌用瀑布陨石开发 然後还可以让系统做到能快速 03/13 01:54
79F：→ strlen: 修改扩展而且也非常稳定测试也都有写 那你天生神力 03/13 01:55
80F：→ strlen: 要让产品能够快速做出改变适应需求还要稳定不能坏掉 这是 03/13 01:58
81F：→ strlen: 要付出代价的 03/13 01:58
82F：推 OyodoKai: 待过成功上市的新创 虽然不是跑真的Scrum 应该也不可能 03/13 02:00
83F：→ strlen: agile这个字其实是灵活上的敏捷 而不是快速上的敏捷 03/13 02:01
84F：→ OyodoKai: 期待陨石开发天生神力保佑 03/13 02:01
85F：→ strlen: 一堆老板大概看到敏捷 就觉得原文是fast...... 03/13 02:03
86F：→ strlen: 你啥设计都没有把功能直接从头写到尾 这叫fast 最快 03/13 02:04
87F：→ strlen: 但你如果要考虑设计 还要跟同事吵架 东想西想才弄出一个架 03/13 02:04
88F：→ strlen: 构 然後再加上测试 可能花你两倍以上时间 但要改就很快 03/13 02:05
89F：→ strlen: 你从头写到尾的 前面很快 等到後面要改 就是还债罗 03/13 02:05
90F：→ strlen: 我讲白一点 这云三洨的果然云 老董跟CTO两个老人真的啥都 03/13 02:06
91F：→ strlen: 不懂在胡说八道 鸡同鸭讲 其实agile也够老了也能乱扯一通 03/13 02:07
92F：→ strlen: 什麽scrum造不三洨督三洨的 这跟那有何关系？混业界混几十 03/13 02:09
93F：→ strlen: 年了 上网搞懂这些管理模式花几小时而已很难吗 可悲喔 03/13 02:09
94F：→ strlen: 难怪公司烂成这样 哈 03/13 02:10
95F：→ OyodoKai: scrum如果真的能满足老板(PO) 大家就老老实实跑了 03/13 02:11
96F：→ OyodoKai: 新创基本上都魔改成kanban来接陨石 03/13 02:13
97F：→ strlen: 其实重点还是在达成目标 把产品做成可快速修改的稳定系统 03/13 02:15
98F：→ strlen: 你要自己发明什麽鬼模式都可以 能尻出这种效果就行 03/13 02:16
99F：推 OyodoKai: 老板要的是赚钱的系统 XD 03/13 02:17
100F：→ strlen: 可快速修改的稳定系统 这可并不容易 应该说 非常困难 03/13 02:17
101F：→ strlen: 你东西不能快速修改 跟不上需求 就赚不了钱 可以改 但不稳 03/13 02:17
102F：→ strlen: 定 客户体验烂 一样不赚钱 所以罗 03/13 02:18
103F：→ OyodoKai: 大部分公司聘不起能做出可快速修改的稳定系统的工程师 03/13 02:18
104F：推 dio0204: 结论：跟共产主义一样 只有小屁孩相信 03/13 02:45
105F：→ strlen: 也不是什麽共产主义 这就经验累积的结果 就是这样 03/13 02:49
106F：→ strlen: 你的目标是开发出能快速修改扩充又稳定的产品 03/13 02:49
107F：→ strlen: 前人累积了许多心酸血泪 最後才试出一套敏捷开发模式 是最 03/13 02:50
108F：→ strlen: 有机会能达成这个目标的 别的模式不是不行喔 就说你屌炸天 03/13 02:50
109F：→ strlen: 自己发明什麽碗糕模式也能达到一样效果 那算你厉害罗 03/13 02:51
110F：推 OyodoKai: 我觉得该来个scrum九宫格了 形式自由 03/13 02:52
111F：→ strlen: 这葛云三洨的产品 很明显就是 能快速修改 但极不稳定 哈哈 03/13 02:53
112F：→ strlen: 敏捷玩一半就会变成这样 可怜哪 03/13 02:53
113F：嘘 B0988698088: 感觉文就别发了 你讲的大家早就知道了 03/13 08:47
※ 编辑: hidog (111.241.148.153 台湾), 03/13/2025 09:24:45
114F：推 luke72: 20%这种事跑mini waterfall也行，没规定waterfall要100% 03/13 12:18
115F：→ luke72: 再来CTO跟这串文讲的都是硬体跟核心，就不适合agile啊 03/13 12:20
116F：推 jack0204: 硬体可以参考Toyota高效工作术，也是敏捷精神 03/13 16:42
117F：→ jack0204: 特斯拉造车也是想方法各种加速 03/13 16:43
118F：推 NDark: 特斯拉造车法就是解决不能接受改变的人 03/13 17:00
119F：→ NDark: 因为马斯克每个站点都自己盯敢说不的就被ＦＩＲＥ了 03/13 17:01
120F：→ lonelytea: 第一段确实 03/13 17:55
121F：→ superpandal: 不会有无敌的系统出来的 真有也不会甘心献给一个不是 03/13 18:30
122F：→ superpandal: 自己所有的公司或单位 虽然我自己随手做的灵活性就不 03/13 18:31
123F：→ superpandal: 错了 但我绝对不会想做一个让人可以在技术上躺赢 03/13 18:33
124F：→ superpandal: 并且危害到自己生存的东西 因为人不可尽信 03/13 18:36
125F：→ superpandal: 职场上经验就是王八蛋人数远远超过好人 03/13 18:39
126F：→ superpandal: 故现实上这些东西是不可能完美进行的 不管你打算用几 03/13 18:48
127F：→ superpandal: % 灾难如果可以意料就不是灾难 03/13 18:49
128F：→ superpandal: 即便全部没算漏 但薪水明显就是不合理 03/13 18:53
129F：推 AudiA4Avant: Toyota 的 Kanban被应用在执行敏捷开发。不等於Toyot 03/13 19:14
130F：→ AudiA4Avant: a是敏捷开发吧 03/13 19:14
131F：→ atst2: Toyota方法比较接近的是Lean吧? 而且要走Toyota方法，前提 03/13 19:42
132F：→ atst2: 相当严格, 生产要有完整自动化机制，遇到问题要能随时叫停 03/13 19:43
133F：→ atst2: 所有问题都要排除後才能往下走. 对於很多企业来说，连前提 03/13 19:45
134F：→ atst2: 要达到都很难... 03/13 19:45
135F：→ dildoe: 要原型肥宅会直接用现成硬体直接尽量用现成套件来拼 03/13 20:08
136F：推 jack0204: 高效工作术不只硬体层面的规划，还有计划如何推进 03/13 20:08
137F：→ jack0204: 例如下午要跟多个客户讨论能怎麽减少时间浪费 03/13 20:10
138F：→ jack0204: 怎麽防止问题再犯，都跟敏捷有关，只是它不用敏捷称呼 03/13 20:11
139F：→ jack0204: 实际上要运用要看你够不够格啦，职位不够想搞什麽都难 03/13 20:12
140F：推 viper9709: 听起来满猛的 03/14 00:03
141F：→ superpandal: 楼上有人讲的高效工作术我看了大纲 那看起来就是超级 03/14 00:59
142F：→ superpandal: 螺丝钉的概念 什麽思考how前先思考why... 这本身就是 03/14 01:00
143F：→ superpandal: 上层思考的 什麽管好自己的不丢给别人 社会很复杂的 03/14 01:02
144F：→ superpandal: 洗脑人当超级牛马 高层当棋手下都下不好都没责任 03/14 01:04
145F：→ superpandal: 况且我不信可以当面问why 最後不是心里os就是走人 03/14 01:12
146F：→ hegemon: 一直问why到最後就是会被搞..螺丝钉就好好扮演螺丝钉好吗 03/14 07:52
147F：→ hegemon: ..整天问why只会拖慢速度..等到你真的上位有时间跟资源压 03/14 07:52
148F：→ hegemon: 力的时候看底下的人一直问why你就会有体会了 03/14 07:52
149F：推 moon2519: 中肯 03/14 08:48
150F：推 CRPKT: 也有些公司会鼓励工程师了解一下商业脉络 03/14 08:57
151F：→ CRPKT: 但不是所有工程师都会对这个有兴趣 03/14 08:57
152F：推 shadow0326: 鼓励工程师问聪明的问题，不鼓励问智障问题 03/14 14:23
153F：→ shadow0326: 至於哪种问题聪明哪种问题智障，我他妈怎麽会知道 03/14 14:23
154F：→ ssccg: 鼓励工程师通灵，不鼓励工程师自己乱想 03/14 15:56
155F：→ strlen: 问不问也不是重点 重点是企业有没有公开透明大家吵架的文 03/14 17:12
156F：→ strlen: 化 什麽事都拿出来吵 拿出来公开讨论 包括需求 03/14 17:12
157F：→ strlen: 通常都是表面上讲open mind 但是你开口就被记仇 再讲你就 03/14 17:13
158F：→ strlen: 被捅 嘻嘻嘻 03/14 17:13
159F：→ strlen: 连真话都不能讲 还跑什麽敏捷 敏你个洨 工程师不要刻意塞 03/14 17:14
160F：→ strlen: bug就祖宗保佑惹 甚至也不需要故意塞 就故意粗心一点做事 03/14 17:14
161F：→ gino0717: 桑原老师说过 架是要两个人才能吵的 03/14 17:19
162F：推 AudiA4Avant: 有的时候有问题的不是方法，而是执行的时候忽略人性 03/15 21:19
163F：推 new122851: 开发测试比至少要1比3，团队10个开发者，就要搭配30个 03/16 13:22
164F：→ new122851: 测试人员 03/16 13:22
165F：嘘 s860134: 通常测试开发比例是1：3 测试是1 03/16 15:09
166F：→ labbat: 抱歉测试人员去帮忙开发了，所以是0 03/16 15:50
167F：推 luke72: 测试？我快十年没看过公司有测试了… 03/17 21:05
168F：推 atowng: 怎麽还再吵这个？产品品质下降就是事实，使用者哪管你妈妈 03/19 09:55