同感
有人有類似經驗的 請不要來認親 因為跟你絕對不是同公司 謝謝
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