PTT職涯區 / Soft_Job (軟體人)

Re: [討論] 關於敏捷越來越深入台灣職場

看板Soft_Job (軟體人)作者 (3d)時間1月前 (2024/07/26 12:14), 編輯推噓26(29推 3噓 156→)
留言188則, 41人參與, 1月前最新討論串5/9 (看更多)
※ 引述《kuosos520 (kkk)》之銘言： : 小弟就業大概十來年 : 雖然剛入職場時 : 敏捷開發就已經是很紅的議題 : 但至少我前幾份專案都還是很傳統的瀑布 : 個人感覺是近年越來越明顯 : 所有的專案管理方式都越來越朝敏捷的概念走 : 我自己體感 : 比以前痛苦指數提高了很多 痛苦就不是敏捷 : 例如說 : 以前談好一整個版本的spec : 要談時程就是基於一整個版本再談 : 中間有什麼改動很正常 : 基於是整個版本談時程 : 大多數還有arrange的空間 : 時程變動就是整體移，不會在一條一條對 : 通常不太會很細節的追進度 : 頂多每週或每天需要跟自己直屬報一下 這還比較敏捷 : 最近幾年很明顯 : 所有的專案管理方式都往敏捷的精神走 : 工作訂出來就是丟給工程師問時程 : 沒有一個很固定的版本空間 : 就是請你一直做，做到一個程度再確定版本 敏捷跟不確定不相關，這是誤解。這種情況其實就是隕石 : 但是需求一直改本來就很正常 : 所以明面上是工程師自己壓 : 但其實需求根本不固定 : 所以細項時程根本沒參考性 : 每天為了其實很不重要的東西被時間追著跑 壓時間就不是敏捷了。 : 早期都是談1-2個月的版本開發時間 : 需要的話平日加班週末加班趕進度 : 進度狀態比較好也可以適度休息一下 : 只要在講好的時間拿出來，大家都好說話 : 現在偏向每一天都被進度追著跑 : 一個禮拜要報好幾次進度 : 時程沒對到就說工程師自己定的 再重申一次，定時間是完全違反敏捷的精神。敏捷是預估(forecast)不是設定(promise) : 以前傳統瀑布式自己可以抓放工作 : 有些小東西先放一下以後再處理 : 或是卡關太久需要交代進度 : 就抓個小東西出來作 : 交代完進度再來專心面對魔王關 : 現在敏捷其實 : 不會給你自己安排的空間 : 東西丟出來就要定時程 : 每次都跟你逐條討論 : 你根本無法自己安排每天要做什麼 : 甚至上下午可能都被定死 流星雨，不是敏捷 : 先不討論哪一個開發模式對專案品質比較好 : 我也沒有那個視野可以討論這種事情 : 單就痛苦指數來說 : 從工程師角色看，絕對是指數級上升 : 我就很不解 : 為啥很多工程師很熱衷於討論敏捷開發 : 甚至是去學習敏捷開發課程 : 從我的邏輯看 : 相當於工程師用管理者的視角 : 去思考如何壓榨自己 : 然後還去實踐 因為你被假敏捷壓榨。Scrum常常會變成這樣，Scrum是壓榨員工的好工具，如果濫用的話。 --------------------- 敏捷軟體開發宣言 https://agilemanifesto.org/iso/zhcht/manifesto.html 個人與互動 重於 流程與工具 可用的軟體 重於 詳盡的文件 與客戶合作 重於 合約協商 回應變化 重於 遵循計劃 也就是說，雖然右側項目有其價值， 但我們更重視左側項目。 敏捷軟體的 12 個原則 https://agilemanifesto.org/iso/zhcht/principles.html Ron Jefferies有寫Scrum的問題，但問題就是使用的人 https://ronjeffries.com/articles/018-01ff/scrum-not-asd-1/ 特別有講sprint壓時間是完全違反敏捷的精神。 敏捷的起源是跟"toyota way"很有關係的。實做的人（工程師）要主導開發，換句話說是由下往上。瀑布是由上往下。隕石跟流星雨也都是由上往下。 像我就很不欣賞Jira跟Slack，不是工具不好，但使用起來都是追進度，抓戰犯，完全違反敏捷的精神。 敏捷的意義是以人為本，支持工程師，跟客戶良好互動，但台灣很多公司都是用敏捷之名行壓榨員工之實。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 111.248.96.54 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1721967243.A.64F.html
推
07/26 12:22, 1月前 , 1F
敏捷是快速取得回饋並持續改善 廢物公司只想快速結
07/26 12:22, 1F
→
07/26 12:22, 1月前 , 2F
案死不改善
07/26 12:22, 2F
推
07/26 12:27, 1月前 , 3F
你這樣講我勉強認同，唯一一個點，Rd主導開發，但
07/26 12:27, 3F
→
07/26 12:27, 1月前 , 4F
需求還應該給專業的處理吧，我想，jira真的超雷的
07/26 12:27, 4F
→
07/26 12:27, 1月前 , 5F
，slack還比較有用處
07/26 12:27, 5F
推
07/26 12:31, 1月前 , 6F
推, 真的大部分的scrum都是雷缺
07/26 12:31, 6F
推
07/26 13:04, 1月前 , 7F
給原PO:你應該是誤解了 "主導" 可參考"安燈系統"
07/26 13:04, 7F
推
07/26 13:14, 1月前 , 8F
可用的軟體 重於 詳盡的文件 那可用是誰說的算？
07/26 13:14, 8F
→
07/26 13:18, 1月前 , 9F
這樣是不用結案的概念。
07/26 13:18, 9F
→
07/26 13:26, 1月前 , 10F
你說的是理論 他說的是現實
07/26 13:26, 10F
→
07/26 13:29, 1月前 , 11F
Linux Kernel就是很好的敏捷案例。APTON大的"安燈系統"比
07/26 13:29, 11F
→
07/26 13:30, 1月前 , 12F
我剛才想打的一串的好，精簡清楚。
07/26 13:30, 12F
→
07/26 13:46, 1月前 , 13F
說得很好.下次可以直接用貼的.但沒有解決實務問題
07/26 13:46, 13F
→
07/26 14:05, 1月前 , 14F
Linux kernel project 是agile? 給一下出處好吧。
07/26 14:05, 14F
推
07/26 14:09, 1月前 , 15F
員工痛苦股東才會爽
07/26 14:09, 15F
→
07/26 14:18, 1月前 , 16F
@Apton, @原Po, 兩位的'主導'定義好像跟一般不太一樣?
07/26 14:18, 16F
→
07/26 14:18, 1月前 , 17F
能否詳細說明一下，這裡的主導是只有出問題時停下來嗎?
07/26 14:18, 17F
→
07/26 14:19, 1月前 , 18F
還是包括專案的成果評估，方向，業務目標在內?
07/26 14:19, 18F
→
07/26 14:50, 1月前 , 19F
大家都說不是敏捷，那那間公司跑的是真敏捷？
07/26 14:50, 19F
→
07/26 15:20, 1月前 , 20F
按上方的定義：不用結案的公司。
07/26 15:20, 20F
推
07/26 15:39, 1月前 , 21F
國外公司都受不了被壓榨的工作模式，早就已經放棄敏捷開
07/26 15:39, 21F
→
07/26 15:39, 1月前 , 22F
發
07/26 15:39, 22F
→
07/26 15:39, 1月前 , 23F
就台灣人自己越來越盛行www
07/26 15:39, 23F
→
07/26 16:10, 1月前 , 24F
咦...這個說法，給個出處好吧。
07/26 16:10, 24F
推
07/26 16:14, 1月前 , 25F
@atst2 如果以"做產品"的角度 當然是都要包含
07/26 16:14, 25F
→
07/26 16:15, 1月前 , 26F
不然最後遇到狀況，開發還是會回頭去問同樣的問題
07/26 16:15, 26F
→
07/26 16:16, 1月前 , 27F
但是大部分的公司都是分工不合作 各團隊的距離很遠
07/26 16:16, 27F
推
07/26 16:50, 1月前 , 28F
台灣老闆眼中的敏捷=你各位員工員工做快一點
07/26 16:50, 28F
→
07/26 16:50, 1月前 , 29F
怕加班的我把敏捷點滿了...還是繼續加班
07/26 16:50, 29F
→
07/26 17:38, 1月前 , 30F
痛苦就不是敏捷？所以敏捷式宣言包含不能痛苦是不是
07/26 17:38, 30F
→
07/26 18:01, 1月前 , 31F
@APTON, 這個"都要包含"的意思，是指第一線開發者還要兼職
07/26 18:01, 31F
噓
07/26 18:02, 1月前 , 32F
很多時候工程師的立場跟客戶就是相對的，這樣要怎麼玩下
07/26 18:02, 32F
→
07/26 18:02, 1月前 , 33F
去？很多工程師以刪客戶需求作為自己的kpi. 這樣可以良好
07/26 18:02, 33F
→
07/26 18:02, 1月前 , 34F
互動？
07/26 18:02, 34F
→
07/26 18:02, 1月前 , 35F
PM, Market，客服，主管等任務嗎? 還是你有別的意思呢?
07/26 18:02, 35F
→
07/26 18:03, 1月前 , 36F
還望更進一步提供說明.
07/26 18:03, 36F
噓
07/26 18:06, 1月前 , 37F
我看過太多太尊重工程團隊的公司，搞到最後就是沒有人可
07/26 18:06, 37F
→
07/26 18:06, 1月前 , 38F
以叫他們做事
07/26 18:06, 38F
→
07/26 18:08, 1月前 , 39F
PM, 客服, 主管, 客戶通通都不行，最後動用到創辦人下來
07/26 18:08, 39F
還有 109 則推文
→
07/27 18:46, 1月前 , 149F
的人 不去用或是用錯也是白搭
07/27 18:46, 149F
→
07/27 19:10, 1月前 , 150F
AGILE的專家們，請問AGILE 在最開始前，要先寫一些底
07/27 19:10, 150F
→
07/27 19:11, 1月前 , 151F
層的東西嗎? 要架環境嗎? 要的話，要算進sprint?
07/27 19:11, 151F
→
07/27 19:12, 1月前 , 152F
會人人都有工作? 還是只有某幾位負責?
07/27 19:12, 152F
→
07/27 19:13, 1月前 , 153F
再來，何時on production? 按國外大神的說法，沒提到呢
07/27 19:13, 153F
→
07/27 19:13, 1月前 , 154F
若成員的程度差異，導致他的工作無法如期完成，會不會
07/27 19:13, 154F
→
07/27 19:14, 1月前 , 155F
大家都完工了，還要等他? code review 會算進sprint?
07/27 19:14, 155F
→
07/27 19:14, 1月前 , 156F
review 後的modification 要算下一個sprint?
07/27 19:14, 156F
→
07/27 21:35, 1月前 , 157F
1)看團隊自己決定，2)人人有工作，3)隨時都是production，
07/27 21:35, 157F
→
07/27 21:37, 1月前 , 158F
4)每個人拿自己適合的工作，有問題在standup meeting就要
07/27 21:37, 158F
→
07/27 21:38, 1月前 , 159F
提出，如果還是不能解決，轉給可解決的人。如果無人可解，
07/27 21:38, 159F
→
07/27 21:39, 1月前 , 160F
看是要花時間研究，或放棄選另一條路走。
07/27 21:39, 160F
→
07/27 21:40, 1月前 , 161F
code review完才算完成，但有的team不用code review。
07/27 21:40, 161F
→
07/27 21:43, 1月前 , 162F
進度其實是檢視，而不是要追求的目標。做不到，做不快，就
07/27 21:43, 162F
推
07/27 21:44, 1月前 , 163F
待過4個團隊，沒有一個agile是跑到起來的XD
07/27 21:44, 163F
→
07/27 21:46, 1月前 , 164F
是砍功能。如何取捨，排進度，一門藝術。
07/27 21:46, 164F
→
07/28 00:22, 1月前 , 165F
#170rfWYy 這是我的舊帳，在2007年的文章.
07/28 00:22, 165F
→
07/28 00:23, 1月前 , 166F
#1I7R-qV6 這是2013年，我在介紹Lean Programming相關書藉
07/28 00:23, 166F
→
07/28 00:29, 1月前 , 167F
然後在2024年的今天, Agile的傳道士們, 沒有證據，沒有研究
07/28 00:29, 167F
→
07/28 00:29, 1月前 , 168F
面對我提出的問題，把一切都歸結到心態上, 最後再指責有人
07/28 00:29, 168F
→
07/28 00:30, 1月前 , 169F
藉討論之名暗酸?
07/28 00:30, 169F
→
07/28 00:30, 1月前 , 170F
你們是不是真的以為，所有意見不同的人，都沒有跑過敏捷
07/28 00:30, 170F
→
07/28 00:32, 1月前 , 171F
沒有在相關領域，花費時間精力，也不知道安燈, toyota是怎
07/28 00:32, 171F
→
07/28 00:32, 1月前 , 172F
麼回事?
07/28 00:32, 172F
→
07/28 00:34, 1月前 , 173F
面對他人的質疑，你們的回應有符合敏捷宣言的第一條嗎?
07/28 00:34, 173F
→
07/28 03:44, 1月前 , 174F
不知道為什麼敏捷式開發要搞得像宗教信仰
07/28 03:44, 174F
→
07/28 07:10, 1月前 , 175F
還是要講心態很重要。上司，顧客就是隕石，流星雨的需求，
07/28 07:10, 175F
→
07/28 07:14, 1月前 , 176F
不管怎麼敏捷都沒用。能夠抵抗隕石的需求是第一個關鍵，溝
07/28 07:14, 176F
→
07/28 07:16, 1月前 , 177F
通再溝通，沒其他法子。就算所有都作對了，也不保證成功，
07/28 07:16, 177F
→
07/28 07:18, 1月前 , 178F
開心做事就好了。謀事在人成敗由天
07/28 07:18, 178F
推
07/28 10:42, 1月前 , 179F
推 我們team算是一個成功的敏捷範例 我認同這篇內容
07/28 10:42, 179F
→
07/28 10:43, 1月前 , 180F
敏捷跑得好 應該是大家都輕鬆 客戶也開心 但是要跑得起來
07/28 10:43, 180F
→
07/28 10:45, 1月前 , 181F
需要超罩的主管+自律的工程師 人力素質PR95以上
07/28 10:45, 181F
→
07/28 10:47, 1月前 , 182F
這真的非常不容易 所以失敗的敏捷居多
07/28 10:47, 182F
推
07/28 18:27, 1月前 , 183F
加班過勞死的工程師轉生到異世界開始研究敏捷開發
07/28 18:27, 183F
推
07/29 16:41, 1月前 , 184F
推推
07/29 16:41, 184F
→
07/30 10:44, 1月前 , 185F
能壓榨員工的敏捷對老闆來說就是好敏捷
07/30 10:44, 185F
推
07/31 17:08, 1月前 , 186F
推這篇
07/31 17:08, 186F
→
08/01 17:30, 1月前 , 187F
不太同意沒有時程 我覺得是宣言概念 比起壓時程 更注重
08/01 17:30, 187F
→
08/01 17:30, 1月前 , 188F
團隊自發自律
08/01 17:30, 188F
‣ 更多 oopFoo 的文章
文章代碼(AID): #1ceoABPF (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
以下文章回應了本文：
完整討論串 (本文為第 5 之 9 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共9篇)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 oopFoo 的文章
文章代碼(AID): #1ceoABPF (Soft_Job)