同感
有人有类似经验的 请不要来认亲 因为跟你绝对不是同公司 谢谢
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公司每年人均点数都是几万点
敏捷对我有利的说词、作法我都想要
敏捷我要负责、我不喜欢的 不是改不动就是文化不同
这就是亚洲式敏捷

点数通膨是一大问题，每个人都说这个sprint 要做10点，结果每个task估计的点数越来越宽松，变成没做啥事情就达成10点，剩下的时间都在玩耍，美其名叫WLB

目标导向就是这样囉，最经典的就是用行数，大家就各种复制贴上...

story point 是估工时人天用的，把KPI挂勾一定烂掉

亚洲有亚洲的玩法 不能让大家更穷忙 我们可是不要的 嘻嘻

笑死

把 story point 当 KPI，明显主管就还是没有把自己的脑袋革新。

笑死

换一套管理流程，但骨子里思想没变。

笑死,从一开始就觉得这个到台湾就是垃圾的机制,果然~不理解下面的人在做什么,你用几百种管理方式都一样啦~

东亚文化圈先改变自己的文化再去玩高文明的管理技巧

结果脑袋都在思考公司政治 XDDDDDD

血淋淋的经验QQ

有遇过敏捷一天要报4次工时的以半小时为单位

笑死 以为在讲敝司

谢谢大家TT 看到这么惨的 我心情好一些了

瀑布被污名化了，那些都是殒石。瀑布其实很爽，就是很死的每阶段产出完成才进下一阶段，要改就是整个翻掉从瀑布头开始，没有瀑布是水在半空中还倒流一小段的只有神才能违反物理，有神存在的就是陨石开发

你一定跟我同公司 XD然后每个sprint结束，要计算该sprint点数除以该sprint上班时数，下降就表示你偷懒...

想笑又有点笑不出来

通货膨胀笑死 XD

2的公司用敏捷改善产能本身就误会大了 敏捷只会更慢 它的目的不是快 而是不断地试误调整 让最终成品能中途因应局势变化 或是在没有方向时找出最后想要走的方向1也是大错 捷敏的要件就是9人以下的精英组团 非精英勿入呀

楼上正解 敏捷精神是拥抱改变 所以不保证效率会提升有错误期待的管理层引入一个与目标相反的政策 是悲剧来源

敏捷（应对所有突发状况和现况改变）

story point 当 KPI 这逻辑很直觉 就是做多的贡献多 XD 但这种想法纳入体制 基本上最后就是逼人与他人合作度降到最低敏捷本身是怕结果脱离"目标" 所以才会拥抱改变 但这很容易变成无限加料 然后做出一团和客户需求完全不同的垃圾...

“拥抱改变”

也遇过一家公司scrum都乱做然后搞绩效算kpi 但问题是怎么量化 怎么评估准确度和公平性 随便想也一堆漏洞可以提出 然后就变成为了绩效到处乱看卡

看起来都是用一套新“方法”期待能带来效益，而不是实务上去解决问题，以为是方法不对，实际上是场景不适合、能力不足，可笑的是定方法的人不是做事的人XD

用bug当kPI本来就很智障 我复制贴上就没bug了 傻了才重构

靠背战力通膨超好笑 很有画面XDDD

菁英组团，不用敏捷也会成啊!? 这干敏捷屁事?

战力通膨www

敏捷自助餐

所以 到底有没有哪个公司不是乱搞敏捷 陨石当敏捷的啊

有敏捷团队用comment数量当kpi的，讨论愈多绩效愈差

很多人把scrum当随意改规格的方式

我只能说，每家公司资讯部门都一堆类似鬼故事

看来大家对scrum误解很深。软件规格本来就可以随意改，但要管理优先权。每天有进度也没问题，每天要看KPI或关多少issues也没问题，但要懂得拆成够小的ticket，保证每日 软件版本品质。无限加料也没什么，放在back log就好。推文看到最大的问题就是：一堆没成功经验的人在乱做scrum。另外不是所有软件都适合scrum。固定规格的接案，waterfall会比较适合。常常要变更功能的to C端产品，就很适合scrum。

那有那个成功案例吗？

同楼上，每次都有护航：这不是敏捷、你们误解敏捷

老实说 你要问台湾有哪个软件的成功案例 都不见得有答案了 再多加一个"使用敏捷开发"的过滤条件 哪会有答案

我也想知道，什么样的案子/专案适合scrum.

遇过用story point 除工时拿来当kpi 的，sp 还给一堆搞不懂状况的主管定义，结果就是低sp 高工时，最后我不爽就离职了

确实，然后Bug单不能算工时，或者在绩效报告时点数不能算上Bug单的，所以一堆人害怕写出Bug都在复制贴上，能动就好

同Lordaeron, 到底什么案子适合scrum? 商业上的案子有几件是没规格的?

新创/新产品还找不到获利模式，边摸索边开发可以跑敏捷

新创这说法也很怪，一来屎金出生时，还没哪么多新创的不可能是以新创为生的，再说新创总得要第一个：产品才能去圈钱。我们以FB/META 为例，当年要是连第一个可以用的产品/网站都没有，是怎样屎金来变需求呢？用这思路，加上Dr Tech 的讲法，就是先有to C的网络产

如果只适用新创 那一堆企业推是在？

品后，后续按C 的变化，去屎金一下。

我手上的状况是 算是很成熟的产品 但太熟了 要管理或更动的effort很大 于是排了个比较大的重构 这种时候就会同时有很确定要什么 与 有些颇ambiguous的东西 不一定能第一时间界定 这时跑scrum我是觉得蛮合适的 反正都是要持续的sync-up与跨各单位去确认business logic来订规则但之前在游戏业就没办法 个人管个人的 工项永远爆满陨石术放不用mp的 根本没办法也没意义去做高频率的沟通赶快rush出一个东西推次级市场验证概念比较重要

跟错老板产生这种结果，这算眼光问题，还是人品问题？

哈哈哈

跟错老板这种事情不能怪员工 你各位如果独具慧眼又有远见自己出来当老板早就发财了 当啥员工

推通货膨胀，笑死XD

当老板有慧眼就可以，不用资金和人脉？

点数通膨真的超好笑，一直逼点数搞到大家都高估

烂公司太多 所以无所谓跟不跟对老板 因为你要糊口你就没有多少好的选择所以天眼通很重要 不然你就得有门路知道这些东西当老板当然要有资金和人脉 但没有慧眼只是造虐而已乱花钱都是事小 干坏事才事大 福份消耗很快分

有梗XDDD

我以为看到我前公司哈哈哈哈

基本上没有任何能成功量化软件工程师的KPI指标只要一个顾问进到软件团队喊著KPI量化，87%是神棍，不然就是无脑的PO/PM