作者kuosos520 (kkk)
看板Soft_Job
标题[讨论] 关於敏捷越来越深入台湾职场
时间Thu Jul 25 10:30:45 2024
小弟就业大概十来年
虽然刚入职场时
敏捷开发就已经是很红的议题
但至少我前几份专案都还是很传统的瀑布
个人感觉是近年越来越明显
所有的专案管理方式都越来越朝敏捷的概念走
我自己体感
比以前痛苦指数提高了很多
例如说
以前谈好一整个版本的spec
要谈时程就是基於一整个版本再谈
中间有什麽改动很正常
基於是整个版本谈时程
大多数还有arrange的空间
时程变动就是整体移，不会在一条一条对
通常不太会很细节的追进度
顶多每周或每天需要跟自己直属报一下
最近几年很明显
所有的专案管理方式都往敏捷的精神走
工作订出来就是丢给工程师问时程
没有一个很固定的版本空间
就是请你一直做，做到一个程度再确定版本
但是需求一直改本来就很正常
所以明面上是工程师自己压
但其实需求根本不固定
所以细项时程根本没参考性
每天为了其实很不重要的东西被时间追着跑
早期都是谈1-2个月的版本开发时间
需要的话平日加班周末加班赶进度
进度状态比较好也可以适度休息一下
只要在讲好的时间拿出来，大家都好说话
现在偏向每一天都被进度追着跑
一个礼拜要报好几次进度
时程没对到就说工程师自己定的
以前传统瀑布式自己可以抓放工作
有些小东西先放一下以後再处理
或是卡关太久需要交代进度
就抓个小东西出来作
交代完进度再来专心面对魔王关
现在敏捷其实
不会给你自己安排的空间
东西丢出来就要定时程
每次都跟你逐条讨论
你根本无法自己安排每天要做什麽
甚至上下午可能都被定死
先不讨论哪一个开发模式对专案品质比较好
我也没有那个视野可以讨论这种事情
单就痛苦指数来说
从工程师角色看，绝对是指数级上升
我就很不解
为啥很多工程师很热衷於讨论敏捷开发
甚至是去学习敏捷开发课程
从我的逻辑看
相当於工程师用管理者的视角
去思考如何压榨自己
然後还去实践
-----
Sent from MeowPtt on my SM-S9110
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 1.200.249.3 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1721874647.A.BE4.html
1F：→ alongalone: 因为推的人都是传道者 07/25 10:37
2F：→ infinitlee: 这只是披着敏捷开发实际上是waterfall的变体 07/25 10:41
3F：推 fishfish1314: 敏捷(X) 陨石(O) 07/25 10:42
4F：推 KyuubiKulama: 敏捷不是要有个有经验的PM来带比较好吗 07/25 10:49
5F：推 ghost90331: 这就要看思考角度了，单纯只想领薪水的话敏捷很痛苦 07/25 10:50
6F：推 Lhmstu: 因为推的人，只负责开会 07/25 10:57
7F：推 lonelytea: 还要浪费时间开会 白吃东西 07/25 10:58
推 brucetu: 工程师的谈判力不如管
理职，不管你换什麽玩法这个本质不 07/25 10:58
8F：→ brucetu: 会改变 07/25 10:58
9F：→ brucetu: 工程师精於解决需求，管理职精於靠嘴压榨出价值，不论哪 07/25 11:00
10F：→ brucetu: 种开发方法都不能扭转这样的利益关系 07/25 11:00
11F：→ brucetu: 最简单的，你敢不敢拿着需求去跟你带的新人说，这个本来 07/25 11:01
12F：→ brucetu: 一个月要完成的东西麻烦你们赶工一下两个礼拜完成 07/25 11:01
13F：→ brucetu: 然後再转头跟上面报告说这个没有一个半月做不出来 07/25 11:02
14F：推 gino0717: 现在路边的猫猫狗狗都可以直接跑去找工程师押时程了 07/25 11:24
15F：推 nayeonmywife: 当然是方便插单跟临时改scope呀 07/25 11:28
16F：推 abccbaandy: 因为老板听到敏捷就高潮阿...你痛不痛苦关他屁事 07/25 11:28
17F：→ abccbaandy: PM也爽，需求讲不清楚可以说我们是敏捷 07/25 11:29
18F：→ abccbaandy: 每天一堆会搞得好像很忙 有在做事 07/25 11:30
19F：→ stepnight: 一堆打着敏捷开发，实际上整天浪费时间开会 07/25 11:36
20F：推 fg008kimo: 就是一种新的压榨手法阿 老板听到当然开心 07/25 11:36
21F：推 johnbill: 习惯就好 07/25 11:47
22F：→ johnbill: 整天在那边装忙 07/25 11:47
23F：推 Abbee: 你这不是敏捷 是陨石石开发法 真正的敏捷是目标小又明确 07/25 11:48
24F：→ Abbee: 全力在短时内作出来 而不是乱改 07/25 11:48
25F：→ Abbee: 而且成员是全职在写 本来就不给你自己安排想作别的 07/25 11:49
26F：推 WaterLengend: 需求不明确不叫敏捷，这叫陨石 07/25 11:57
27F：推 SHANGOYANYI: 那些热衷的通常是想转PM的开发XD 07/25 11:58
28F：推 Obama19: 就是产出最大化啊 不把人当人看 当工具用 07/25 12:03
29F：→ MOONY135: 插单+hotfix+milestone都要同时间做好喔，做不完的时候 07/25 12:04
30F：→ MOONY135: 还可以说给工程师自由规划工作时间的空间了。 07/25 12:04
31F：推 NTUTM04: 比较痛苦的瀑布式开发 07/25 12:07
32F：推 chen09885: 根本没有敏捷，只是换个名词继续催你而已 07/25 12:15
33F：→ holmes2136: 其实对於QA也是折磨,例如regression testing只给了更 07/25 12:16
34F：→ holmes2136: 短的时间跑整个流程 07/25 12:16
35F：→ bill0205: 会强调敏捷的80%都是陨石 07/25 12:19
36F：→ kuosos520: 有时候不一定强调敏捷这个名称，只是业界大多往这 07/25 12:23
37F：→ kuosos520: 个方向走了 07/25 12:23
38F：推 Ghamu: 你们是不是都没用jira之类的管理工具然後一直用开会对进度 07/25 12:26
39F：→ Ghamu: 的方式做事？ 07/25 12:26
40F：推 Ghamu: 我们公司说穿也是常常什麽周会连站会都在细究进度 07/25 12:28
41F：→ kuosos520: 用jira，走敏捷精神，还是一样， 07/25 12:29
42F：→ kuosos520: 问题不是实践方法 07/25 12:29
43F：→ kuosos520: 是被被短时程追着跑的痛苦 07/25 12:29
44F：→ kuosos520: 我感觉用什麽工具都差不多，就这种精神很反人性 07/25 12:30
45F：推 Ghamu: 看到你说一直报进度 感觉是不是浪费很多时间开会 07/25 12:30
46F：→ kuosos520: 我总有燃烧自己的时间跟融化的时间 07/25 12:30
47F：→ kuosos520: 不能一直让我燃烧 07/25 12:30
48F：→ Ghamu: 我倒不觉得反人性 敏捷应该是及早发现及早治疗 我前公司我 07/25 12:31
49F：→ Ghamu: 们做了一个软体做超久 丢上市场才发现没半个用 07/25 12:31
50F：→ Ghamu: 要是能小步快跑 早点验证早点发现不对 我们就不用浪费时间 07/25 12:32
51F：→ Ghamu: 了 07/25 12:32
52F：→ kuosos520: 那是公司的角度看，不是工程师的角度看 07/25 12:33
53F：→ kuosos520: 工程师的时间有换到薪水，就不是浪费时间，除非你 07/25 12:33
54F：→ kuosos520: 说你创业 07/25 12:33
55F：→ Ghamu: 那感觉你应该多抓一点自己的buffer吧 顺风就提早做完 不顺 07/25 12:34
56F：→ Ghamu: 就on time 这样对管理方也比较好暗算 07/25 12:34
57F：→ Ghamu: 也可以请假吧 需要休息就好好休息 07/25 12:34
58F：→ Ghamu: 另外我没记错的话敏捷精神不是要大家专注在一个sprint上吗 07/25 12:35
59F：→ Ghamu: ？你怎麽有很多进度要追 07/25 12:35
60F：→ kuosos520: 不讨论细节跟实践方式，是指目前大多往这个方向做 07/25 12:37
61F：→ kuosos520: 管理 07/25 12:37
62F：→ kuosos520: 敏捷到底应该怎样，窝不知道，窝只知道比瀑布痛苦 07/25 12:37
63F：→ kuosos520: 很多 07/25 12:37
64F：→ panda04056: 因为大部分公司是假敏捷啊 只会站立咪听+陨石 07/25 12:40
65F：→ Ghamu: 我觉得很多都是假敏捷 搞错重点弄成他不舒服我也很痛苦的样 07/25 12:40
66F：→ Ghamu: 子 07/25 12:40
67F：→ alan3100: 道理简单 跨过学习门槛後公司竞争力会提升很多 07/25 12:42
68F：推 NDark: Scrum Master就是小PM的变形 07/25 12:54
69F：→ NDark: 不过我现在都不讲敏捷 都化整为零直接精算时间 07/25 12:56
70F：→ NDark: 你要一天就上版也行 那少掉的测试时间自己要负责任 07/25 12:56
71F：→ NDark: 没有测试人员的组织 基本上是轻视测试这项专业 07/25 12:57
72F：→ NDark: 甚麽叫做 "开发人员应该..." 那都是一种不负责任的话术 07/25 12:58
73F：→ NDark: 年纪越大我越觉得有个专门的品管人员会很安心 07/25 12:59
74F：推 NDark: 很多开发人员认为测试人员不会测 那只是打资讯落差而已 07/25 13:01
75F：→ NDark: 如果在开发过程中测试人员提早进场做测试计画 07/25 13:01
76F：→ NDark: 那麽测试人员的准备不一定会比开发人员少 07/25 13:02
77F：推 googoo1102: 假scrum 真daily review, push进度 会议又超时 07/25 13:02
78F：→ NDark: 差异就在於成本 (不好意思离题了讲一堆) 07/25 13:02
79F：推 miloisgood: 最近也遇到 跟原po深有同感 07/25 13:09
80F：推 CRPKT: 你知道十家公司一般会有十一种敏捷跑法吗 07/25 13:14
81F：推 gmoz: 这不是敏捷的问题 是你公司制度的问题 看起来不是敏捷 07/25 13:16
82F：→ gmoz: 时间是在grooming跟planing时就决定的 也是左移提早发现问题 07/25 13:17
83F：→ gmoz: 做到一半改需求改AC 这看起来根本没有敏捷 07/25 13:17
84F：推 NDark: "那是因为没有执行真正的敏捷" 07/25 13:20
85F：→ BoXeX: 真正的敏捷只存在於幻想中吧 07/25 13:21
86F：→ BoXeX: 人不是机器 每天叫你全力 最好能做到 07/25 13:26
87F：→ BoXeX: 又不是国外可以按时休长假 07/25 13:26
88F：推 vencil: 本来就是来压榨出工程师生产力的机制... 07/25 13:28
89F：→ MOONY135: 最後可能发现真正的敏捷速度比瀑布还慢XDDD 07/25 13:31
90F：→ abccbaandy: 敏捷的总时程本来就会比瀑布慢啊... 07/25 13:34
91F：推 wsad50232: 想要用一条鞭的方式管理，结局就是悲剧 07/25 13:37
92F：→ alan3100: 敏捷不会比较快 只是一种管理方式 不会让工作变少 07/25 13:42
93F：→ alan3100: 主要是提早发现随时调整 暴露隐藏成本 07/25 13:43
94F：→ alan3100: 瀑布最糟方向错了最後60分也没有 敏捷边做边调能80分 07/25 13:44
95F：推 CRPKT: 不知道原 po 只是想上来抱怨一下还是想改变现状 07/25 13:47
96F：推 ko27tye: 瀑布方向错了也能一颗陨石砸成80分阿 07/25 13:48
97F：→ CRPKT: 抱怨的话大家可以陪嘴一下，想改变就跳槽吧 07/25 13:48
98F：推 NDark: 上面说的对 其实敏捷并不保证快 敏捷是保证"逐步"趋近需求 07/25 13:52
99F：→ alan3100: 不太可能吧XD 砸成80分可能是花200分工的後果 07/25 13:52
100F：→ atst2: 问题在於, 团队中最应该了解需求，最能反应改变的，会是工 07/25 14:16
101F：→ atst2: 程师吗? 07/25 14:17
102F：→ atst2: 如果不是，那团队中谁该负责去明确需求? 07/25 14:18
103F：→ atst2: 不管瀑布还是敏捷, 需求还不明确就要求订时程，都不合理吧? 07/25 14:20
104F：推 NDark: Product Owner可是有明确定义的喔 这点没错 07/25 14:31
105F：→ NDark: 能决定事情的这个人必须进入团队 老板在外围点菜就失格 07/25 14:32
106F：推 jyunwei: 因为这是瀑布群 07/25 14:35
107F：推 k7ji91ab5m: 敏捷可以快速反应变化 瀑布不行 想请问原PO假设 07/25 15:22
108F：→ k7ji91ab5m: 你们现在回到瀑布是可行的吗? 周期多长呢? 07/25 15:22
109F：→ k7ji91ab5m: 那麽做到一半有需求改变了 工程师可以拒绝吗? 07/25 15:23
110F：推 NDark: 这样不能比应该要设定 两个礼拜的瀑布vs两个礼拜的敏捷 07/25 15:33
111F：→ NDark: 或是半年的瀑布vs半年一个sprint的敏捷 这样才能比出差异 07/25 15:33
112F：推 shadow0326: 你的描述看起来不像敏捷 07/25 15:37
113F：推 APTON: 你和你的公司都不熟敏捷和瀑布，倒是都很懂陨石XD 07/25 16:03
114F：推 jack0204: 敏捷不是在追进度，是你们公司认为的敏捷是那样而已 07/25 16:10
115F：推 viper9709: 推这篇&二楼07/25 16:25
116F：→ DrizztMon: 这篇重点到真的不是敏捷式开发 07/25 16:26
117F：→ DrizztMon: 有效率的工作模式当然包含压榨劳工的心力阿 07/25 16:26
118F：→ DrizztMon: 你可以为了钱拚老命 也可以自己设定工作步调 07/25 16:27
119F：→ DrizztMon: 反正我们只是打工仔 要自己决定平衡点阿 07/25 16:28
120F：推 holebro: 假敏捷 07/25 17:14
121F：→ ku399999: 这不是敏捷，只是错误理解没被纠正而已 07/25 18:11
我觉得有些荒谬的是
很多人反应的是，这不是敏捷
那我想反问，敏捷是什麽？
就我而言
追求快速跌代，就是敏捷开发
至於怎麽实现，每个地方都不一样
就算瀑布开发
每个公司，每个部门，甚至每个专案
流程一定都不一样
难道有一些固定形式必须满足才能称为XXX模式
这怎麽感觉变成哲学问题
我认知
垂直运作是瀑布
快速跌代是敏捷
而且单就工程师角度看
追求快速跌代这个精神，本身就比较折磨人
※ 编辑: kuosos520 (1.200.249.3 台湾), 07/25/2024 18:40:39
122F：→ lazarus1121: 以前三天做完的喊一礼拜，改成三小时做完喊一天而已 07/25 18:35
123F：→ lazarus1121: 唯一的差别就是每天站会很浪费时间，耽误拉屎跟看盘 07/25 18:35
124F：推 kwanles: 在台湾的敏捷 大概都会变成压榨工具 压迫开发时程 07/25 18:38
125F：→ lazarus1121: 敏捷是给pm或po失败的藉口之一 07/25 18:46
126F：→ lazarus1121: 最好有工程师会喜欢敏捷XD 07/25 18:46
127F：推 johney719: 台湾只有陨石式开发 07/25 18:46
128F：推 keel90135: 陨石：找我? 07/25 19:11
129F：→ infinitlee: 你认为的敏捷开发跟别人认为敏捷的开发，双方起始点就 07/25 19:19
130F：→ infinitlee: 不一定相同。某个pm认为的敏捷开发是在一个sprint不断 07/25 19:20
→ infinitlee: 变动需
求，但工程师要能够快速反应，这也能称为快速跌 07/25 19:21
131F：→ infinitlee: 代。上线後有问题，就在下一个sprint再来调整。 07/25 19:21
132F：→ infinitlee: 这样的敏捷开发，是原po认定的敏捷开发吗? 07/25 19:22
133F：→ infinitlee: 敏捷开发会因为不同环境而有所异动，但大部分公司说的 07/25 19:23
134F：→ infinitlee: 敏捷开发就只是单纯的压榨跟抱怨工程师速度不够快，不 07/25 19:23
135F：→ infinitlee: 够敏捷。但有定义好每个sprint的目标是什麽? 07/25 19:24
136F：推 NDark: 我觉得在相同的buffer比例之下 不会比较折磨人 07/25 19:25
137F：→ kuosos520: 回覆楼上，只要是开发中快速跌代我都认知是偏敏捷 07/25 19:26
138F：→ kuosos520: 的管理模式 07/25 19:26
139F：→ NDark: 敏捷开发有一个条件是 "拥抱改变" 07/25 19:26
140F：→ NDark: 也就是说敏捷开发的成员 心态上 就不要太把规格改变放心上 07/25 19:27
141F：→ NDark: 也就是说心态反倒是要训练改变为 "你改我就下一周期开时程" 07/25 19:27
142F：→ infinitlee: 那使用waterfall开发，就无法快速跌代吗?一定要用敏捷 07/25 19:27
143F：→ infinitlee: 才能快速跌代? 07/25 19:28
144F：→ NDark: 改越多越好 等於是PO自己不在意时程问题 07/25 19:28
145F：→ NDark: 敏捷开发比较适合那种老板不知道怎麽准确描述需求的案子 07/25 19:28
146F：→ NDark: 所以只好一步步改 07/25 19:28
147F：→ NDark: 对於大型系统的模仿案就不应该用敏捷 因为参考对象已经有了 07/25 19:29
148F：→ NDark: 模仿案反而在意时程问题 因为要抢时间赶快上线 07/25 19:30
149F：→ infinitlee: 今天真的使用waterfall，难道就真的先等SA,SD把文件写 07/25 19:30
150F：→ infinitlee: 好，pg才进来开发吗?其实也没有，难道今天需求有变动 07/25 19:30
151F：→ infinitlee: pg能说文件先改好，我才能动程式，其实也没有阿 07/25 19:31
152F：→ NDark: 确实有PG说你规格不完全接露我无法开发 通常是资料库人员 07/25 19:32
153F：→ infinitlee: @NDark，因为DBA通常就是你给我什麽我就做甚麽 07/25 19:33
154F：→ NDark: 敏捷的规格可以模糊(少)一点 只满足现在想得到的规格 07/25 19:33
155F：→ NDark: 若不在意变化那就很有敏捷精神了.那就是他改归他改.任我行. 07/25 19:34
无意争辩
这样偏瀑布
https://tinyurl.com/y93q5nr6
这样偏敏捷
https://tinyurl.com/ybbqoexd
这只是我的认知，以大家自己认知为主
※ 编辑: kuosos520 (1.200.249.3 台湾), 07/25/2024 19:37:12
156F：→ NDark: 就我的经验 规格差一点 资料库关联开起来会差很多 07/25 19:35
157F：→ infinitlee: 然後就会有人出来说专案品质很差，程式品质很差 07/25 19:35
158F：→ infinitlee: 原po若开发快速跌代就是敏捷开发，那你应该也只有取你 07/25 19:37
159F：→ NDark: 效能很差就继续改.这也是PO要自己承受. 07/25 19:37
160F：→ infinitlee: 觉得有意义的地方，而忽略整各精神 07/25 19:37
161F：→ lazarus1121: 敏捷我怎麽听都觉得是现在游戏的EA模式 07/25 19:38
162F：→ lazarus1121: 硬要套在开发上只能说推的人根本没开发过 07/25 19:38
163F：→ lazarus1121: 最好瀑布式开发spec开完团队下次见面就是成品交付了 07/25 19:38
164F：→ ku399999: 不是 大家不用这麽激动 把变动造成的影响通通丢给RD负责 07/25 19:40
165F：→ NDark: 除了时程周期长短之外 两者差在哪里? 我认为是完整规格揭露 07/25 19:40
166F：→ ku399999: 是错的 这应该所有人认知都一致吧 07/25 19:40
167F：→ NDark: 敏捷允许一次只接露一点(瞎子摸象) 07/25 19:40
168F：→ infinitlee: 原po贴的连结是理论，但跟现实实作相距甚远 07/25 19:41
169F：→ NDark: 瀑布式因为时程长揭露的比较多这个周期开始就往产品奔跑了 07/25 19:41
170F：→ NDark: 所以我认为差异最大是在PO能否把目标描述清楚 07/25 19:41
171F：推 Csongs: 差异只是在不用等所有需求都厘清才开始做而已 07/25 19:42
172F：→ NDark: 如果一开始就能描述100%(抄袭作) 那时程长短就不是问题 07/25 19:42
173F：→ NDark: 如果PO很难把事情讲清楚或这项产品没有参考作品那适合敏捷 07/25 19:42
174F：→ lazarus1121: 允许虾子摸象只是模糊po的责任罢了 07/25 19:45
175F：→ lazarus1121: 我还遇过要我一起参加产品发想的XD 07/25 19:45
176F：推 NDark: 长周期能投注在设计上的时间多 所以能揭露/思考多一点再干 07/25 19:45
177F：→ NDark: 楼楼上 有一条是 "每个成员都是专家" ,老板不专业只好花钱 07/25 19:46
178F：→ lazarus1121: 所以我就说敏捷是分散po责任的开发方式啊 07/25 19:50
179F：→ lazarus1121: 所以这样的模式对开发来说没啥帮助 07/25 19:50
180F：→ MOONY135: 敏捷的奥义是不管规格怎样改 开发周期都已经订好了吗? 07/25 19:53
181F：→ MOONY135: 真的有人敢跟上面说 因为你改了规格所以之前承诺的时间 07/25 19:53
182F：→ MOONY135: 不算吗? 07/25 19:53
183F：推 NDark: 新规格就下一个周期再作啊 这跟瀑布与敏捷无关 07/25 19:54
184F：→ NDark: 瀑布也不可能作出没讲好的规格 07/25 19:55
185F：→ infinitlee: @MOONY135，这时候就会把这各异动放到下一个sprint 07/25 19:56
186F：→ NDark: 只是短周期比较好转向改规格弹性比较大(心态) 07/25 19:56
187F：→ MOONY135: 之前遇过某PM 弄出来的东西不能开发 07/25 20:01
188F：→ MOONY135: 开发周一边顺需求一边先改写 然後让他去改文件的 07/25 20:01
189F：→ MOONY135: 最後pm还是说就算改了做法也是这个开发周要完成 07/25 20:01
190F：推 CRPKT: 回到原 po 的论点好了，假设敏捷就是这个样子 07/25 20:02
191F：→ MOONY135: 新的规格顺好都周三下班了 剩两天开发 07/25 20:02
192F：→ lazarus1121: 敏捷的问题就是道理都很多 07/25 20:02
193F：→ lazarus1121: 但开发真的实作起来就跟小瀑布没啥两样 07/25 20:02
194F：→ CRPKT: 那原 po 可能性格上就是不喜欢这样，也没什麽不对 07/25 20:02
195F：→ CRPKT: 那问题是，然後呢？原 po 想改变什麽吗 07/25 20:03
196F：→ CRPKT: 如果想改变，原 po 也说了不想管工程以外的东西 07/25 20:04
197F：→ CRPKT: 那必然无法在组织内部造成影响，所以就只有换环境了 07/25 20:05
198F：→ Abbee: 原PO的图没错, 但每个sprint都要重订时程 07/25 21:20
199F：→ fgh81113: 你有没有想过是你的问题 时间就这麽多 速度就这样 做 07/25 22:03
200F：→ fgh81113: 不来就是做不来 有没有尝试说不行 07/25 22:03
201F：→ ku399999: 这根本不是敢不敢的问题吧 一个sprint就1-4周 改到生不 07/25 22:34
202F：→ ku399999: 出来当然是要资源 要人要时间啊 07/25 22:35
203F：→ ku399999: 敏捷不是剩两天但我大改需求你照样要生给我吧 07/25 22:36
204F：推 ktasl: 没有 Scrum Master 就不要说自己敏捷了好吗 07/25 23:09
205F：→ ktasl: 有 Scrum Master 还把需求跟会议搞成这样就叫 SM 出来面对 07/25 23:10
206F：→ kuosos520: 我刚刚想了一下，楼上的说法有点类似如果没有用nod 07/25 23:44
207F：→ kuosos520: e.js就不要说你会Javascript这样 07/25 23:44
208F：→ Ghamu: 如果需求变动不改时程 此例一开不管是否敏捷以後都很难过吧 07/25 23:53
209F：推 newking761: 因为好交差啊 07/26 00:00
210F：推 wulouise: 啊？你一次要做很多事怎麽敏捷？单位都是用周算的吧 07/26 00:13
211F：推 popcool: 你这就真的不是敏捷，所谓快速迭代指的是需求拆小快速实 07/26 00:49
212F：→ popcool: 现并上线，不是把时间塞满就叫敏捷好吗。不同需求之间也 07/26 00:49
213F：→ popcool: 会有几天修整期，另外，开发时间给工程端喊，啊你自己要 07/26 00:49
214F：→ popcool: 喊这麽紧有意外就自己吞很正常，如果是需求变动那就是时 07/26 00:49
215F：→ popcool: 间重拉这你们团队要有共识 07/26 00:49
216F：推 lchcoding: 要不改时程，可以啊 07/26 00:57
217F：→ lchcoding: 压“最後需求变动时间” 07/26 00:57
218F：→ lchcoding: 过了，就进入闭关状态了 07/26 00:57
219F：→ lchcoding: 其他，等出来再说 07/26 00:57
220F：推 LuLuCow: 唯一推荐「敏捷总舵主-Hermes」 07/26 01:50
221F：推 hengsao: 这是假敏捷 我们团队也是这样 超痛苦 07/26 03:00
222F：推 kwanles: 之前遇到的都是时程不能变 需求 规格一直变.. 07/26 05:29
223F：→ Nitricacid: 敏捷(x) 流星雨(o) 07/26 08:12
224F：推 Nitricacid: 说原 po 这不是敏捷 阿敏捷就 10 间公司有 11 种方案 07/26 08:25
225F：→ Nitricacid: 实际上敏捷只有壳没有料 根本给喇叭嘴唬烂进度推卸 07/26 08:25
226F：→ Nitricacid: 责任用的 我现在都只要改规格就把时间往後估 陪这 07/26 08:25
227F：→ Nitricacid: 些喇叭嘴慢慢耗 07/26 08:25
229F：→ ssccg: 台湾公司做的才不是敏捷，是需求乱改时间不能再多 07/26 10:36
230F：嘘 gmoz: 啊你们现在流程就离敏捷太远了啊 跟你自己的定义没什麽关系 07/26 10:42
231F：→ gmoz: 快速迭代是目的 你们达到目的的手段就是陨石小瀑布 07/26 10:43
232F：→ gmoz: 手段差这麽多 哪里算敏捷??? 07/26 10:43
233F：→ TSMCfabXX: 有一种敏捷 = 老板叫你做甚麽你就做甚麽 07/26 10:46
234F：→ TSMCfabXX: 这种敏捷不叫做敏捷 07/26 10:46
235F：→ ssccg: 能达成快速迭代且工程师没靠北才叫敏捷 07/26 11:06
236F：推 NDark: "老板叫你做甚麽你就做甚麽" 这就是工作(雇佣) 07/26 11:07
237F：→ ssccg: 只是追求快速迭代不论方法，那就是流星雨也可以啊 07/26 11:07
238F：→ NDark: "用我的方法满足雇主需求" 这叫委托(承揽) 07/26 11:07
239F：→ ssccg: 你说的瀑布其实也不对，瀑布就是每阶段要切得乾净，需求一 07/26 11:14
240F：→ ssccg: 直改并不正常，只能整个做完，或开发全推翻回去设计重来 07/26 11:15
241F：→ ssccg: 基本上你就是从时程长的陨石，转到时程短的流星雨而已 07/26 11:16
242F：推 gmoz: 瀑布里面不是水 是陨石群～～ 07/26 11:29
243F：→ LiebeLion: 就一堆无能高层觉得新东西很潮 07/26 13:24
244F：→ LiebeLion: 实际上都是陨石开发 07/26 13:24
245F：推 answermangtr: 你是对的 台湾搞敏捷的一堆都效率更差 笑死 07/26 16:18
246F：推 asdf121250: 真的 打着敏捷旗帜 PM把他要做的工作带到每次会一请大 07/26 18:24
247F：→ asdf121250: 家「讨论」 PM根本就会议提醒机器人 07/26 18:24
248F：嘘 KanzakiHAria: 陨石不要装敏捷 07/26 21:21
249F：→ viper9709: 瀑布里不是水而是陨石群XDDD 07/26 23:58
250F：推 prag222: 潮阿,可以拿来嘴炮,业界常态拉 07/27 05:08
251F：推 molopo: 假敏捷 07/27 05:56
252F：推 avmm9898: 敏捷开发就是别人要敏捷一点的意思 07/27 09:34
253F：→ z22771187: AGI点高，写程式会比较快吗 07/27 09:36
254F：→ Firstshadow: 干真的 每天都被进度追== 07/27 11:33
255F：→ bndan: 敏捷的本质不是这样 但是敏捷的"做法" 到是学的8成像 只能 07/27 17:40
256F：→ bndan: 说最终就是求最高压榨是真 但这也是军备竞赛产生的..只能说 07/27 17:41
257F：→ bndan: 合作的本质是竞争+合作 而当重点放在前者时 就会压力爆增.. 07/27 17:41
258F：推 npkalala: 同意三楼，多得是用敏捷在跑瀑布开发。还看过PO在sprint 07/27 20:43
259F：→ npkalala: 快结束还插单整个story硬说是bug的 07/27 20:44
260F：推 mepowerlmay: 传产 比较不会管这些欧 07/27 23:21
261F：推 Litfal: 你的敏捷怎麽怪怪的 07/27 23:32
262F：推 acenova: 恭喜悟得台式敏捷 07/29 14:41
263F：→ shooter555: 敏捷开发就是叫开发者敏捷一点 燃尽图就是要把你燃尽 07/30 10:41
264F：推 yuiweq1999: 推2楼XD 07/30 16:49
265F：→ ChungLi5566: 我这边长官技术底的 也为了搏名声搞敏捷 07/31 08:26
266F：→ ChungLi5566: 大家也都做做样子而已 实际上就一个人开发 是要怎麽 07/31 08:27
267F：→ ChungLi5566: 敏捷 07/31 08:27
268F：→ ChungLi5566: 一个人当ScrumMaster 自己拆Sprint 自己开发自己检 07/31 08:31
269F：→ ChungLi5566: 视自己每日跟自己开会 07/31 08:31
270F：推 jiujibye: 有感 没有喘息空间 07/31 18:09
271F：推 Verse: 讨厌 +1 ，总是那些不把手弄脏又要名声的人在推 07/31 19:53
272F：推 kaibaseto: 同样一套管理工具在不同文化传统的地方用 08/01 02:07
273F：→ kaibaseto: 想起英国试用中国式的教育也让英国学生受不了 08/01 02:08
274F：推 JFLung9536: 我自己就是敏捷开发的实践者 08/01 10:24
275F：→ JFLung9536: 我变动规格的速度与幅度 08/01 10:24
276F：→ JFLung9536: 常常比客户跟主管还快 08/01 10:24
277F：→ JFLung9536: 都是我追着客户跟主管要工作 08/01 10:24
278F：→ JFLung9536: 所以主管不太会追我进度 08/01 10:24
279F：→ his8891: 台商就只会学国外的学半套：敏捷压榨在台湾适用。WFH在台 08/05 06:20
280F：→ his8891: 不适用，这里不是欧美 08/05 06:20
281F：推 xrururururu: 台湾跟风却压榨 08/22 23:11