作者LeoPan (晴天)
看板Soft_Job
标题[讨论] Scrum敏捷开发是这麽操作吗？
时间Sun Jun 11 09:52:03 2023
最近在工作上遇到主管采用敏捷开发的管理模式，刚好在论坛上在报导高雄某间医院的资
讯室在程式专案开发所采用的管理模式。
报导标题提到”拥抱敏捷开发全台第一家的医院IT”，於是好奇看了报导内容。
看完之後，觉得是不是真的懂什麽是Scrum、迭代循环(黑人问号狂冒出)。
内容当中提到两点：
1. 系统开发过程，不再跟使用者争辩，为什麽这次提出的需求，又跟上次不一样，「沟
通冲突无益於系统本身，」她强调：「不一样没关系，我们改就对了！确定完成的功能是
使用者要的，更重要。
2. 尽可能地不要撰写详细的开发需求书，使用者只需提出申请，简单说明想要完成的事
。但是，资讯室不会要求使用者一开始就能提出明确的需求。
所以不用详细规格书？ 不用跟使用者讨论内容？ 只要使用者提出需求意见，说什麽就做
什麽！
Scrum是这麽操作运作？！
报导来源：
https://www.ithome.com.tw/people/119258?
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 27.242.70.169 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1686448325.A.5C6.html
1F：→ nh60211as: 全盘接受使用者需求也不是不行ㄅ，反正改需求就把 06/11 09:54
2F：→ nh60211as: 时程拉长就对ㄌ 06/11 09:54
3F：→ BlueBird5566: 要讨论内容阿 讨论完就开发 开发完就测试上线 06/11 09:57
4F：→ BlueBird5566: 然後看使用者使用上有啥问题再逐一修改 06/11 09:57
5F：→ BlueBird5566: 喔 原来是想酸人 那个是医院 06/11 10:01
6F：→ BlueBird5566: 医院it本来就没地位 使用者是医护也没空跟你谈需求 06/11 10:01
7F：→ BlueBird5566: 不同产业都会产生出自己的一套方法 很正常 06/11 10:02
8F：推 gary861226: 敏捷开发（X）陨石开发（O） 06/11 10:06
9F：→ foreverk: 这套你拿去套在金融业也完全没问题，就算需求认真访谈 06/11 10:14
10F：→ foreverk: 认真写，最後验收也是另一回事，最後就乾脆走这套，大 06/11 10:14
11F：→ foreverk: 家开始通灵 06/11 10:14
12F：→ foreverk: 陨石开发你还知道陨石长怎样，这种通灵开发要直到验收 06/11 10:15
13F：→ foreverk: 阶段，user跟工程师才会知道需求是什麽 06/11 10:15
14F：推 michellehot: 1. 因为争辩不是SM的职责 SM是要确认情境和优先度 06/11 10:17
15F：→ michellehot: 争辩是PO的任务 06/11 10:17
16F：→ michellehot: 2. 因为Agile就是假定使用者也搞不清处自己要什麽 06/11 10:18
17F：→ michellehot: 而是先做一个雏形再来改需求 06/11 10:18
18F：推 michellehot: 就我经验而言 Scrum利於周期短的开发工程 例如客户 06/11 10:23
19F：→ michellehot: 已经想到预期的产品效果 只是需要快速落地验证 06/11 10:23
20F：→ michellehot: 但也相对的容易制造垃圾：用完发现没用就丢 06/11 10:24
21F：推 yamakazi: Product owner的工作啊，有时候使用者或客户自己也不知 06/11 10:24
22F：→ yamakazi: 道自己要什麽 06/11 10:24
23F：→ foreverk: 我觉得全文重点反而是MVC跟call center，减少重工跟干 06/11 10:25
24F：→ foreverk: 扰提升效率，才有办法真的跑敏捷，关键还是整合资源 06/11 10:25
25F：→ yamakazi: 牛顿迭代法有没有听过，就是先初始值，然後每一次迭代计 06/11 10:25
26F：→ yamakazi: 算後更接近实际值 06/11 10:25
27F：→ michellehot: 一些需要技术堆叠或是研发类的 还是需要一条清楚的 06/11 10:26
28F：→ michellehot: 路线 以保留中间开发的产物 所以有时候公司会有并行 06/11 10:26
29F：→ yamakazi: 实际值根本一开始不晓得 06/11 10:27
30F：→ yamakazi: 通常是有UI的裁会敏捷开发，没UI没使用者的哪需要跟使用 06/11 10:28
31F：→ yamakazi: 者沟通，组内自己桥一下就可以做了 06/11 10:28
32F：推 new122851: 工研院要不要也Scrum一下，哪天飞弹应user的需求可以挂 06/11 10:55
33F：→ new122851: 载排骨便当都不意外 06/11 10:55
34F：推 NDark: 问就是 你们没有跑真的敏捷 都不是敏捷的错 06/11 11:05
35F：嘘 pttano: 嗯你说的都对 06/11 11:17
36F：推 sunsamy: 新创搞敏捷的不是倒了就是在倒的途中,懂的就懂！ 06/11 11:21
37F：→ DrTech: 原文："不会要求使用者一开始就能提出明确的需求。" 你解 06/11 11:26
38F：→ DrTech: 读成：不用跟使用者讨论需求，使用者说什麽就做什麽。你自 06/11 11:26
39F：→ DrTech: 己过度解读也很奇怪吧。 06/11 11:26
40F：→ DrTech: 该文看起来就是一堆没经验的人，尝试做scrum。但原文带风 06/11 11:27
41F：→ DrTech: 向加油添醋解读，也很没必要。 06/11 11:27
42F：推 k798976869: 就是一种管理方法但是最後还是以老板的需求为主 06/11 11:28
43F：嘘 DrTech: 原文到底哪里说了："不用跟使用者讨论需求，使用者说什麽 06/11 11:30
44F：→ DrTech: 就做什麽"乱解读带风险耶 06/11 11:30
45F：→ moom50302: 错了吧…增进沟通、快速调整才是敏捷开发的重点 06/11 11:32
46F：→ DrTech: scrum本来就不需要像UML，PMP，CMMI哪种详细规格书，这篇 06/11 11:36
47F：→ DrTech: 文章说的没错。然後这篇文章也没说使用者来的需求全部不沟 06/11 11:36
48F：→ DrTech: 通都做。HR系统哪段也有说会跟使用者沟通後才做。 是你自 06/11 11:36
49F：→ DrTech: 己误解文章内容，还来带风向耶。 06/11 11:36
50F：推 jack0204: 确认目标，从目标来讨论需求是否有效 06/11 11:36
51F：→ jack0204: PM/老板大多知道做这个需求的目的，但不知道怎麽达成 06/11 11:37
52F：嘘 safe: 所以你跑的敏捷开发都有详细规格书喔？：） 06/11 11:39
53F：推 jack0204: 不过也是有老板只是想花钱找人做事，有没有用没差 06/11 11:39
54F：→ lazarus1121: 敏捷开发本来就先求有再求好吧 06/11 11:41
55F：→ lazarus1121: 免去无意义的讨论，直接弄个demo最快 06/11 11:41
56F：→ lazarus1121: 只要方向正确，细部後续再调整就好 06/11 11:45
57F：推 BaconBao: 哈哈要注意不要/不再一词主要强调的对象。第一点不要的 06/11 11:50
58F：→ BaconBao: 对象偏向”争辩与冲突”；第二点不要的对象偏向”详细的 06/11 11:50
59F：→ BaconBao: ”需求书，此外由申请与说明两词可知需求仍以较简单的文 06/11 11:50
60F：→ BaconBao: 件或交流方式传递。 06/11 11:50
61F：推 TAKADO: 需求加了时程就延啊，干嘛吵架，反正我PG一样每天写code， 06/11 12:11
62F：→ TAKADO: 时间到了不能上线怪我罗？大概是这样 06/11 12:11
63F：→ foreverk: 比较靠背的是真的怪开发者没有sense，没有讲也应该要想 06/11 12:24
64F：→ foreverk: 到（？？？） 06/11 12:24
65F：推 MonkeyCL: 陨石开发 06/11 12:33
66F：→ InfinitySA: 敏捷就是不断地循环修正 06/11 12:39
67F：→ InfinitySA: 至於循环的大小范围频率 自己拿捏 06/11 12:39
68F：→ InfinitySA: 然後 其实一般不太会有"纯"敏捷 多少会混合其他模式 06/11 12:40
69F：嘘 za755188: 因为实务上不可能在一开始就搞清楚全部的需求 06/11 12:50
70F：→ za755188: 所以敏捷提倡先做出可以demo的东西再来改善 06/11 12:51
71F：推 abccbaandy: 重点其实是人跟公司文化，大家好沟通，公司也接受这种 06/11 13:10
72F：→ abccbaandy: 半成品当然没问题，但如果不是的话就... 06/11 13:11
73F：→ abccbaandy: 现实多的是开始不讲清楚，後面再那边吵架，不小心影响 06/11 13:12
74F：→ abccbaandy: 现有系统更惨，工程师87%绩效-- 06/11 13:12
75F：→ loadingN: 你中文里解有问题 你知道什麽是迭代嘛? 06/11 13:15
76F：→ ctrlbreak: 薪水给够 我就不委屈了 06/11 13:43
77F：嘘 askaleroux: Spec不用写得太清楚 意思是实作者看得懂 06/11 13:53
78F：→ askaleroux: 保留Flexibility 去快速迭代修改 06/11 13:54
79F：→ askaleroux: 避免你自以为是的写了一堆到後面做的时候要打掉 06/11 13:54
80F：→ askaleroux: 但并不是说不用写Spec 06/11 13:54
81F：→ askaleroux: Agile 这边的精神跟 Lean methodology类似 06/11 13:54
82F：→ askaleroux: 去快速的验证 而不是想一步到位 06/11 13:55
83F：→ askaleroux: Fail fast, learn faster. 06/11 13:55
84F：推 EricTao: 你的用词怪怪的 应该只是不强求一开始就设计完善 而不是 06/11 14:03
85F：→ EricTao: 反过来强求模糊需求 06/11 14:03
86F：→ labbat: 设计不完善就不完善，搞什麽这不是BUG这是feature 06/11 14:17
87F：→ labbat: 错就是错，没有那种万能许愿机能读心知道开发者到底想要的 06/11 14:18
88F：嘘 tank0701: 台湾搞scrum只会生出四不像 06/11 14:39
89F：→ t64141: 我的理解是这两点的前提建立在先做最小功能版本再一次一 06/11 15:45
90F：→ t64141: 次的改版更新 06/11 15:45
91F：→ t64141: 因为每个版本改动都小所以快，然後使用者会根据每个版本 06/11 15:48
92F：→ t64141: 的结果一直更新需求这样 06/11 15:48
93F：推 SHANGOYANYI: 这不是敏捷 这只是这个案例想跑敏捷带来的结果 06/11 16:08
94F：嘘 brucetu: 原Po有没有看过搞了半年然後给高层一看结果几乎要打掉重 06/11 16:14
95F：→ brucetu: 做的瀑布开发？ 06/11 16:14
96F：嘘 BigCockman: 敏捷的核心就是各自解读 懂？你管人家的敏捷长怎样 06/11 16:29
97F：→ BigCockman: 是不懂敏捷吗？ 06/11 16:29
98F：→ ssccg: 先改先试用，改不好马上再改也是种敏捷 06/11 17:29
99F：→ ssccg: 一样是要通灵，敏捷至少被翻掉的损失的工时少 06/11 17:30
100F：→ ssccg: 看起来他们的确不懂敏捷，换MVC才是真的，但是你不懂医院IT 06/11 17:37
101F：→ ssccg: 医院就点就在医生最大，医生也没有空跟你讨论，你就是得通 06/11 17:38
102F：→ ssccg: 灵，谁管你用什麽开发流程 06/11 17:40
103F：→ testPtt: 我常遇到资料库1对1用一段时间要改成1对多的 06/11 19:17
104F：推 joney641119: 上面说的对,要通灵或是上面随时随意变更工作内容的 06/11 19:36
105F：→ joney641119: 就不要想用敏捷开发了,自找麻烦 06/11 19:36
106F：→ joney641119: 多的是不让你做完一个sprint就要你改的 06/11 19:38
107F：推 prag222: scrum本身就是一种方法论跟专案技术,一堆人看了几本 06/11 20:54
108F：→ prag222: 中文书就以为自己懂了却不知道写书的人自己都不懂 06/11 20:55
109F：→ prag222: 会写书跟会看书不代表有实务经验 06/11 20:55
110F：推 ckp4131025: gradient descent? 06/11 22:15
111F：推 neo5277: 大家能力跟认知都差不多才敏的起来 06/11 22:21
112F：→ Lordaeron: 原来用了Scrum就不用管软体架构了? 06/11 22:29
113F：推 neo5277: 敏捷就是一个做事情的风格，使用什麽技术来达成才是重点 06/11 22:40
114F：推 viper9709: 推prag222 06/11 23:14
115F：→ alihue: 我的工作经验是，敏捷与类似的框架是给一群能力不强的人 06/11 23:17
116F：→ alihue: 用的，而且套上之後大部分时间还会花在讨论改善流程与开 06/11 23:17
117F：→ alihue: 会，产出的软体一点都没变好。在一个同事都足够强的成熟 06/11 23:17
118F：→ alihue: 环境，根本从来不会把时间花在开发流程的讨论 06/11 23:17
119F：→ brucetu: 一个sprint还没做完就要插队改的叫做陨石开发 06/11 23:35
120F：→ brucetu: 是一个对老板来说比敏捷开发更敏捷的方法 马上改! 06/11 23:35
121F：→ stkoso: 台式敏捷开发就是今天说的东西明天就要 06/11 23:50
122F：→ umum29: 敏捷不代表可以让使用者任意改需求 PM和资深工程师要审核 06/12 00:28
123F：→ umum29: 难道使用者随口说我们要做大数据 下礼拜要上线 你也ＯＫ？ 06/12 00:29
124F：→ umum29: 但看到是医院 那就当我没说.... 06/12 00:31
125F：→ DrTech: 真正跑Scrum，遇到插队很平常好吗。头脑不要那麽死，万一 06/12 00:43
126F：→ DrTech: 临时出现一个使线上系统挂掉的Bug，使公司购物系统不能用( 06/12 00:43
127F：→ DrTech: 公司损失持续发生)，你不先去插队修，你还在扯先跑完这个S 06/12 00:43
128F：→ DrTech: print，下个Sprint再排进tickets处理，这样会比较好吗。 06/12 00:43
129F：推 IhateOGC: 接案被教训几次，就知道要收钱了 06/12 00:44
130F：→ DrTech: 原文医院资讯室，根本没说：使用者说什麽，就无脑做什麽。 06/12 00:46
131F：→ DrTech: 全是原PO加油添醋带风像乱解读吧。 06/12 00:46
132F：→ DrTech: ithom的原文到底哪里说了："只要使用者提出需求意见，说什 06/12 00:48
133F：→ DrTech: 麽就做什麽！"？？？ 乱带风向耶。 06/12 00:48
134F：→ DrTech: 原PO你要不要出来解释一下，我什麽要污蔑原文，原文哪里有 06/12 00:50
135F：→ DrTech: 写到："不用跟使用者讨论内容 只要使用者提出需求意见，说 06/12 00:50
136F：→ DrTech: 什麽就做什麽！" 06/12 00:50
137F：→ DrTech: 原文根本没说好吗。这种带风向乱解读的行为，简直可耻。 06/12 00:52
138F：推 internetms52: 第二点应该是对敏捷宣言的误会，可用的软体重於详 06/12 08:01
139F：→ internetms52: 尽的文件，有提到，“虽然右侧项目有其价值，但我 06/12 08:01
140F：→ internetms52: 们更侧重左侧项目”，这其实不代表完全不需要右侧 06/12 08:01
141F：→ internetms52: 项目，只是如果不得已走左侧至少好过一点 06/12 08:01
142F：推 ura1210: 推 DrTech 虽然我知道很多跑敏感是个笑话 但不应该带风 06/12 08:26
143F：→ ura1210: 向 抹煞想努力改变的人 06/12 08:26
144F：→ ura1210: 楼上有人说 跑敏捷适合能力不强的人？我倒是想问 能力不 06/12 08:27
145F：→ ura1210: 强的团队能跑的起来吗 06/12 08:27
146F：推 oyaji5566: 台湾式敏捷开发=今天开会明天上线 06/12 09:00
147F：→ lazarus1121: 其实scrum是概念而不是形式 06/12 10:04
148F：→ lazarus1121: 很多公司只学两周sprint每天立会就觉得是敏捷 06/12 10:04
149F：推 NDark: 搞错了吧 瀑布式才适合能力不强的成员 菁英规划 杂鱼执行 06/12 10:46
150F：→ NDark: 敏捷才需要都是不会偷懒的精英 因为估计时程错误就整个完蛋 06/12 10:46
151F：推 ckp4131025: 会有插队流程啊，但不是想插就插 06/12 12:17
152F：→ yamagishi: 没有story point跟5分钟早会吗？ 06/12 13:33
153F：→ shooter555: 这个叙述是奴隶开发法 不是敏捷 06/12 15:13
154F：→ scott90213: 钱给够 要怎麽改就怎麽改罗 06/12 15:56
155F：→ answermangtr: 真的有符合敏捷精神在跑的是少数 多得是喊喊口号 06/12 16:24
156F：→ answermangtr: 的 06/12 16:24
157F：→ ybon3: 我数学很快.jpg 06/12 16:52
158F：→ Lordaeron: table schema 进负责开啊? 06/12 17:25
159F：→ Lordaeron: 接queue 的呢? 要共用吗? 还是各自写会比较Scrum ? 06/12 17:27
160F：推 StrangeJ: 可以参考敏捷软体开发宣言 06/12 19:21
162F：→ StrangeJ: 可用的软体重於详尽的文件 与客户合作重於合约协商 06/12 19:22
163F：推 atpx: 没必要争成这样, 也许她就是拿个不重要的小系统演给长官看 06/12 20:19
164F：推 showshowman: 主管:我说了算，就是敏捷 06/12 23:22
165F：→ qss05: IT不就这样的工作…就算讨论半天，最後还是跟你说这不是我 06/13 08:08
166F：→ qss05: 想要的,可是你前面说…：我现在就想要改 06/13 08:08
167F：→ shooter555: 敏捷是用来燃烧蜡烛人用的啦 燃尽图 燃烧你的生命 06/13 09:59
168F：推 eplis: 你要了解什麽是行销，本质是不是根本不重要 06/13 10:01
169F：→ shooter555: 对开发人员最有善的还是走瀑布式吧 06/13 10:07
170F：→ shooter555: 友善 06/13 10:07
171F：→ shooter555: 讲好的规格照着开发 使用者才不会一天到晚讲鬼故事改 06/13 10:08
172F：→ shooter555: 规格 06/13 10:08
173F：→ realbout: 使用者和鬼一样，确定这是敏捷开发? 06/13 11:03
174F：推 friends29: Scrum还要搭配一堆配套 不是有在跑sprint就是敏捷式开 06/13 12:25
175F：→ friends29: 发欸 很多台湾公司对外报告都讲的很厉害 结果问个关键 06/13 12:25
176F：→ friends29: 点都没做到 06/13 12:25
177F：→ BoXeX: 敏捷开发对高层来说 就是可以天天盯你进度 06/13 23:02
178F：→ BoXeX: 还有整天改你规格用的 06/13 23:03
179F：→ BoXeX: 而且就算你真照着敏捷开发走 最後还是发现大多状况不适用 06/13 23:06
180F：→ BoXeX: 大概就前端能用吧 06/13 23:06
181F：→ BoXeX: 其他只要你系统复杂起来 你code写再好没详细规划就不行 06/13 23:07
182F：→ shomingchang: 敏捷有规划啊 TDD 就是规划了 只是不想太繁重文件 06/13 23:51
183F：→ BoXeX: 我的规划不是指这个 是指整个系统架构设计 06/13 23:59
184F：推 Sunal: 系统架构还是会改的啊 也是会一直重构的 06/14 00:12
185F：→ Sunal: 这也是TDD过程中会遇到 06/14 00:13
186F：→ atpx: 上面几位讲的是不同的东西吧....B兄说的是大型应用系统 06/14 00:44
187F：→ atpx: 整个业务流程要有说明文件, 不然前後段各写各的最後组不起来 06/14 00:45
188F：推 SHANGOYANYI: 敏捷是从PM角度推行的方法论 本来就不是要帮PG解决 06/14 01:32
189F：→ SHANGOYANYI: 开发问题的 所以导敏捷跟好不好开发or开发的好不好 06/14 01:32
190F：→ SHANGOYANYI: 一点关系都没有 本质上只是让PM比较容易有产出去跟 06/14 01:32
191F：→ SHANGOYANYI: stakeholders交代而已 06/14 01:32
192F：→ shooter555: 楼上正解 就是PM拿来燃烧各位用的 06/14 11:32
193F：→ ChungLi5566: 团队一半都确诊了还在每日站立会议 06/14 18:37
194F：→ imanda0324: 敏捷参考用而已 06/17 22:42
195F：嘘 strlen: 乱扯什麽PM角度 敏捷也包括程式设计好吗 而且还是重中之重 06/19 22:22
196F：→ strlen: 应该说 程式面没到位 你敏捷只是狗屁 06/19 22:23
197F：嘘 iceorz: 敏捷开发是工程师起草的实践方式，少在那边鬼扯 06/24 10:11
198F：→ iceorz: 不要把失败的敏捷转型都推到PM身上 06/24 10:12
199F：推 zaiter: 正解 老人最爱写一堆智障文件sa sd 的 智障废物老派做法 06/24 10:54
200F：推 astt88: 我参加过的Scrum，早上站会是批斗会议 07/06 23:28
201F：→ astt88: 不是表达昨天做了什麽，遇到了什麽问题，也不只是说明今 07/06 23:30
202F：→ astt88: 天要做什麽 07/06 23:30
203F：→ astt88: 每日站会在批谁没有把事做完，说谁已经把工作的好几天的 07/06 23:41
204F：→ astt88: 份都做好了，就是你工作太慢。这就是个人与互动重於流程 07/06 23:41
205F：→ astt88: 与工具。再好的制度在台湾就会变质 07/06 23:41
206F：推 stillcolor: 87%自称agile但实际上根本陨石 07/08 09:17
207F：推 newking761: 第一天在软体业？ 07/15 16:04
208F：→ newking761: 敏捷开发的本质本来就是先搞出一个能动的产品，後 07/15 16:04
209F：→ newking761: 面再改啊，可以 07/15 16:04
210F：→ newking761: 先收钱才是他的目的 07/15 16:04