看板 Soft_Job
※ 引述《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
mercurycgt68: 敏捷是快速取得回饋並持續改善 廢物公司只想快速結 07/26 12:22
mercurycgt68: 案死不改善 07/26 12:22
kuosos520: 你這樣講我勉強認同,唯一一個點,Rd主導開發,但 07/26 12:27
kuosos520: 需求還應該給專業的處理吧,我想,jira真的超雷的 07/26 12:27
Chricey: 馬卡 07/26 18:06
kuosos520: ,slack還比較有用處 07/26 12:27
RX1226: 推, 真的大部分的scrum都是雷缺 07/26 12:31
APTON: 給原PO:你應該是誤解了 "主導" 可參考"安燈系統" 07/26 13:04
Chricey: GABA推薦 07/26 18:08
abccbaandy: 可用的軟體 重於 詳盡的文件 那可用是誰說的算? 07/26 13:14
Lordaeron: 這樣是不用結案的概念。 07/26 13:18
LiebeLion: 你說的是理論 他說的是現實 07/26 13:26
Kroner: 魚油推薦 07/26 18:09
oopFoo: Linux Kernel就是很好的敏捷案例。APTON大的"安燈系統"比 07/26 13:29
oopFoo: 我剛才想打的一串的好,精簡清楚。 07/26 13:30
alongalone: 說得很好.下次可以直接用貼的.但沒有解決實務問題 07/26 13:46
Kroner: b12什麼時候吃 07/26 19:35
Lordaeron: Linux kernel project 是agile? 給一下出處好吧。 07/26 14:05
MoonCode: 員工痛苦股東才會爽 07/26 14:09
atst2: @Apton, @原Po, 兩位的'主導'定義好像跟一般不太一樣? 07/26 14:18
Kroner: 益生菌功效 07/26 19:38
atst2: 能否詳細說明一下,這裡的主導是只有出問題時停下來嗎? 07/26 14:18
atst2: 還是包括專案的成果評估,方向,業務目標在內? 07/26 14:19
MOONY135: 大家都說不是敏捷,那那間公司跑的是真敏捷? 07/26 14:50
Chricey: gaba 是什麼 07/26 19:43
Lordaeron: 按上方的定義:不用結案的公司。 07/26 15:20
ikimerr: 國外公司都受不了被壓榨的工作模式,早就已經放棄敏捷開 07/26 15:39
ikimerr: 發 07/26 15:39
Kroner: 維生素d3功效 07/26 19:46
ikimerr: 就台灣人自己越來越盛行www 07/26 15:39
Lordaeron: 咦...這個說法,給個出處好吧。 07/26 16:10
APTON: @atst2 如果以"做產品"的角度 當然是都要包含 07/26 16:14
Chricey: 瑪卡推薦 07/26 19:55
APTON: 不然最後遇到狀況,開發還是會回頭去問同樣的問題 07/26 16:15
APTON: 但是大部分的公司都是分工不合作 各團隊的距離很遠 07/26 16:16
happy8649: 台灣老闆眼中的敏捷=你各位員工員工做快一點 07/26 16:50
Kroner: 苦瓜胜肽的功效 07/26 19:58
fatb: 怕加班的我把敏捷點滿了...還是繼續加班 07/26 16:50
tzouandy2818: 痛苦就不是敏捷?所以敏捷式宣言包含不能痛苦是不是 07/26 17:38
atst2: @APTON, 這個"都要包含"的意思,是指第一線開發者還要兼職 07/26 18:01
Kroner: 葉黃素 07/26 20:11
hegemon: 很多時候工程師的立場跟客戶就是相對的,這樣要怎麼玩下 07/26 18:02
hegemon: 去?很多工程師以刪客戶需求作為自己的kpi. 這樣可以良好 07/26 18:02
hegemon: 互動? 07/26 18:02
Kroner: 馬卡功效 07/26 20:16
atst2: PM, Market,客服,主管等任務嗎? 還是你有別的意思呢? 07/26 18:02
atst2: 還望更進一步提供說明. 07/26 18:03
hegemon: 我看過太多太尊重工程團隊的公司,搞到最後就是沒有人可 07/26 18:06
Chricey: 馬卡功效 07/26 18:06
hegemon: 以叫他們做事 07/26 18:06
hegemon: PM, 客服, 主管, 客戶通通都不行,最後動用到創辦人下來 07/26 18:08
hegemon: 盯場,但是在看不見的地方還是偷雞摸狗,客戶幹到翻天, 07/26 18:08
Kroner: 蔓越莓錠推薦 07/26 18:08
hegemon: 這樣會比較好? 07/26 18:08
hegemon: 理想當然是工程師能夠自律,能夠以幫助客戶解決問題為目 07/26 18:09
hegemon: 標,現實就是自律的人太少了..給予工程師過大的自由跟權 07/26 18:09
Kroner: 維生素d3 07/26 18:09
hegemon: 限就是什麼事都做不成 07/26 18:09
yuinami: 推 07/26 19:26
oopFoo: (顧客,pm,主管)決定功能,工程師決定時間與作法。 07/26 19:35
Kroner: 苦瓜胜肽推薦 07/26 19:35
oopFoo: 不過夢想很豐滿,現實很骨感。當壓力來的時候,加班,壓時 07/26 19:36
oopFoo: 間,各種非敏捷的作法通通上來,能夠徹底執行敏捷的團隊還 07/26 19:38
oopFoo: 是少。而且敏捷最重要的是所有人都須認同也配合,這也是不 07/26 19:38
Chricey: 鋅的作用 07/26 19:38
oopFoo: 容易的。沒有良好的團隊,或者強力溝通能力的主管,敏捷不 07/26 19:40
oopFoo: 容易執行也不容易成功。這有點像社會主義,理念良好,但常 07/26 19:41
oopFoo: 常淪落到獨裁者模式。敏捷是需要上面的人全力支持,加上所 07/26 19:43
Chricey: GABA 07/26 19:43
oopFoo: 有人的配合才行。國外我看到成功的案例比較多,台灣可能我 07/26 19:44
oopFoo: 也是見識少,看到的比較少。 07/26 19:45
oopFoo: 敏捷真的就是人的互動才是重點,但人的互動真的是最困難的 07/26 19:46
Kroner: 魚油 07/26 19:46
oopFoo: 課題。要願意信任也是個困難。 07/26 19:48
atst2: @oopFoo,如果一個方法論,需要依賴人的素質,才會有用, 這 07/26 19:54
atst2: 個方法論能稱得上是方法論嗎? 07/26 19:55
Kroner: d3功效 07/26 19:55
atst2: 反過來問,有沒有案例是,有良好的團隊但不走敏捷,所以失 07/26 19:56
atst2: 敗,改用敏捷後就成功了? 07/26 19:56
atst2: 還是只要有良好的團隊,不論走不走敏捷,其實都無所謂呢? 07/26 19:58
Chricey: 葉黃素 07/26 19:58
oopFoo: 應該說敏捷是成功率比較高的方法,所有方法都有成功的機會 07/26 20:08
oopFoo: 但敏捷迭代,多許多機會成功。 07/26 20:10
oopFoo: 當初xp的團隊,是良好的團隊,但最後他們的案子是被取消的 07/26 20:11
Chricey: EPA 07/26 20:11
atst2: 關於方法論是否影響產出,NDark網友有提出 #1MWgps7K 07/26 20:15
atst2: 那您這邊提到'成功率'比較高,是否也有研究可以參考呢? 07/26 20:16
oopFoo: 因為Chrysler被Daimler-Benz買走,新東家有不同想法。 07/26 20:16
Chricey: 益生菌 07/26 20:16
atst2: 在您繼續回覆,我先提一下個人對Agile/Scrum/Lean的想法, 07/26 20:17
oopFoo: 老實說,沒有研究。這都是我們觀察跟想當然爾的 07/26 20:18
atst2: 個人覺得敏捷以及相類似的方法論,其實是有一定道理的。 07/26 20:19
atst2: 但個人一直覺得,這些方法論,很多還只是理論, 而非定理. 07/26 20:20
atst2: 從理論到落實一直有很大的落差,而這些落差,目前看不到相 07/26 20:21
atst2: 關推廣的人,有想去填補的努力在,而一直是不斷強調理論有 07/26 20:22
atst2: 多美好. 07/26 20:22
atst2: 也許有團隊/研究已經在努力了,但個人見識有限,無法知曉. 07/26 20:23
atst2: 在這種情況下,去指稱某些公司跑的是'假敏捷',敏捷"不是" 07/26 20:25
atst2: 什麼,是沒有意義的。因為對於想要進入"敏捷",享用到好處 07/26 20:26
atst2: 的團體而言,他們想要知道的是,彌平理論到實作間的落差的 07/26 20:27
atst2: 手段。 07/26 20:27
nathanlu: 敏捷好棒棒,每間都說在跑敏捷,需求完成率很高 07/26 20:30
atst2: 如果沒有這個手段,而只能依賴團隊人員素質的話,老實說, 07/26 20:33
atst2: 與其引入敏捷,不如去增進HR團隊的能力還比較實際一點。 07/26 20:33
Lordaeron: 我做上百個大大小小(錢)的案子,人員倒是沒有哪些一百 07/26 21:16
Lordaeron: 幾十的案子。但三五七個倒有。就是沒有方法論。 07/26 21:17
Lordaeron: 但全部準時收錢。 07/26 21:17
Lordaeron: 數學解題,就是從基本的去解就是好的方法。哪些什麼特 07/26 21:18
Lordaeron: 解,遇到某類題目有專門快速的解法,就是爛解法。 07/26 21:19
howdiee: 只能說牽扯到人的理論在實際上就是會有落差 07/26 21:41
Lhmstu: 台灣文化融合的敏捷等於快速結案 07/26 21:47
Lordaeron: 很多人都認為,用了某某方法,我也可以做出一樣的系統. 07/26 23:20
Lordaeron: 正如看著菜譜,人人都是大廚的概念。 07/26 23:22
viper9709: 推atst2 07/27 00:03
fantasystar: Ron 讓我學到很多,感謝分享 07/27 02:35
fantasystar: *Ron的文章 07/27 02:36
oopFoo: extreme programming系列的書,是一個好入門的書,它提倡 07/27 06:26
oopFoo: test first,短時間的迭代,standup meeting,pair 07/27 06:27
oopFoo: programming和如何計畫,都有很好的解釋跟緣由。現在的人 07/27 06:29
oopFoo: 使用敏捷大部分都不了解背後的緣由。toytota way,也是一 07/27 06:31
oopFoo: 個很好的管理想法,雖然跟軟體有點遠。 07/27 06:32
oopFoo: 好的團隊是需要時間去互相磨合,也不是hr找對人就可以的。 07/27 06:39
oopFoo: 所以敏捷第一條就是"個人與互動"。這真的是最難的課題。 07/27 06:40
notimenofree: Jira只是工具 雷在哪 07/27 06:57
notimenofree: 錯的是用的方式吧 07/27 06:57
oopFoo: 最後我想強調的是,敏捷強調的是心態。但理工人喜歡方法, 07/27 07:09
oopFoo: 想找SOP,想找工具來解決問題。敏捷宣言就是想告訴你那是 07/27 07:11
oopFoo: 次要的。正確的心態才是比較重要的。 07/27 07:13
lchcoding: 我看得少.如果 Debug 和帶新人 07/27 07:45
lchcoding: 不算的話.pair programming 我沒看過餒 07/27 07:45
lchcoding: 兩位程式設計師,寫一份碼 07/27 07:45
lchcoding: 不吵架,可能嗎? 07/27 07:45
lchcoding: (當然,平常就是用嘴巴寫程式 07/27 07:45
lchcoding: 那種不討論) 07/27 07:45
atst2: 我懂了,敏捷就是宗教。站立會議就是早晚課,檢討會議就是 07/27 07:50
atst2: 發露懺悔。每次迭代都是一個輪迴。好好照著做就可以成佛。 07/27 07:50
atst2: 不成的話,就是心態不正,信仰不足。持續做下去就對了。 07/27 07:50
oopFoo: pair programming很少見,大部分人不願意試,主要就是困難 07/27 07:59
oopFoo: 問題一起pair,或帶新人大家比較願意做。 07/27 08:01
oopFoo: 站立會議,檢討會議現在都太形式化了。開會是要了解跟檢討 07/27 08:02
oopFoo: 程式問題。其實兩三個人一組,不要超過五六個人參與,簡短 07/27 08:06
oopFoo: 結束。當變成形式的時候,就是要換個方法做。可惜,現代管 07/27 08:07
oopFoo: 理,無法從SOP跳開。敏捷就是團隊要找出適合的方法,不需 07/27 08:10
oopFoo: 照著教條做。 07/27 08:10
z22771187: 國外立意良好的東西進到台灣後都會歪斜 07/27 09:35
NDark: pair要好好分組訓練 因為這種新制度在學校職場都沒教 07/27 09:46
NDark: 新制度的引入就跟新機器一樣要有教學 07/27 09:46
Csongs: 敏捷很容易壓榨啊 那個宣言都是強者 敏捷就是很多強者一起 07/27 10:11
Csongs: 合作 不會掉棒 07/27 10:11
Csongs: 不欣賞工具這段還是怪怪的 抓戰犯用excel管也能抓 07/27 10:13
tzouandy2818: 信奉敏捷式的人都沒有拿研究或數據佐證 只會說你成 07/27 10:14
tzouandy2818: 效不彰就是沒有敏捷/不夠敏捷 論述充滿不可證偽性 07/27 10:14
oopFoo: excel的好處是,pm花時間填資料就沒那麼多時間騷擾工程師 07/27 10:53
internetms52: jira是工具,不會扭曲流程,如果流程有問題,不能 07/27 12:18
internetms52: 怪jira 07/27 12:18
internetms52: jira也可以不壓時間啊,是用法問題 07/27 12:21
NDark: 某種敏捷有一條規則是"成員都是專家" 而且都假設是全端的 07/27 12:25
labbat: 須符合真空狀態下,且專家是球體的時候才有效 07/27 12:55
sCHb68: 預估根本不準,不然就不會不做不知道一做嚇一跳了, 07/27 13:57
sCHb68: 待過某家公司,就是把預估當成是設定, 07/27 13:57
sCHb68: 一個spint一定要完成,拖延到的話PM還會很不爽。 07/27 13:57
lylu: 我還遇過直接把planning 的點數當成kpi的呢 07/27 14:04
APTON: 嗯...果然根本沒有打算討論,只是想趁機偷酸,還好沒浪費時 07/27 16:32
APTON: 間回覆 07/27 16:32
kckckckc: 真的,還遇到一個連規格都不會開的在那一般說要導入敏 07/27 17:54
kckckckc: 捷xD 07/27 17:54
Ghamu: 覺得問題點在於1. 團隊了解敏捷開發是什麼? 2. 團隊要知道 07/27 18:41
Ghamu: 怎麼執行? 3. 上頭有權力者要相信 了解 決心推動敏捷開發 07/27 18:41
Ghamu: 不懂 執行的不是敏捷 沒有權力只能推半套 都會爆炸 07/27 18:44
Ghamu: 想想人也是很重要的 只有工具也是不可行 再好的工具遇到錯 07/27 18:46
Ghamu: 的人 不去用或是用錯也是白搭 07/27 18:46
Lordaeron: AGILE的專家們,請問AGILE 在最開始前,要先寫一些底 07/27 19:10
Lordaeron: 層的東西嗎? 要架環境嗎? 要的話,要算進sprint? 07/27 19:11
Lordaeron: 會人人都有工作? 還是只有某幾位負責? 07/27 19:12
Lordaeron: 再來,何時on production? 按國外大神的說法,沒提到呢 07/27 19:13
Lordaeron: 若成員的程度差異,導致他的工作無法如期完成,會不會 07/27 19:13
Lordaeron: 大家都完工了,還要等他? code review 會算進sprint? 07/27 19:14
Lordaeron: review 後的modification 要算下一個sprint? 07/27 19:14
oopFoo: 1)看團隊自己決定,2)人人有工作,3)隨時都是production, 07/27 21:35
oopFoo: 4)每個人拿自己適合的工作,有問題在standup meeting就要 07/27 21:37
oopFoo: 提出,如果還是不能解決,轉給可解決的人。如果無人可解, 07/27 21:38
oopFoo: 看是要花時間研究,或放棄選另一條路走。 07/27 21:39
oopFoo: code review完才算完成,但有的team不用code review。 07/27 21:40
oopFoo: 進度其實是檢視,而不是要追求的目標。做不到,做不快,就 07/27 21:43
s06yji3: 待過4個團隊,沒有一個agile是跑到起來的XD 07/27 21:44
oopFoo: 是砍功能。如何取捨,排進度,一門藝術。 07/27 21:46
atst2: #170rfWYy 這是我的舊帳,在2007年的文章. 07/28 00:22
atst2: #1I7R-qV6 這是2013年,我在介紹Lean Programming相關書藉 07/28 00:23
atst2: 然後在2024年的今天, Agile的傳道士們, 沒有證據,沒有研究 07/28 00:29
atst2: 面對我提出的問題,把一切都歸結到心態上, 最後再指責有人 07/28 00:29
atst2: 藉討論之名暗酸? 07/28 00:30
atst2: 你們是不是真的以為,所有意見不同的人,都沒有跑過敏捷 07/28 00:30
atst2: 沒有在相關領域,花費時間精力,也不知道安燈, toyota是怎 07/28 00:32
atst2: 麼回事? 07/28 00:32
atst2: 面對他人的質疑,你們的回應有符合敏捷宣言的第一條嗎? 07/28 00:34
tzouandy2818: 不知道為什麼敏捷式開發要搞得像宗教信仰 07/28 03:44
oopFoo: 還是要講心態很重要。上司,顧客就是隕石,流星雨的需求, 07/28 07:10
oopFoo: 不管怎麼敏捷都沒用。能夠抵抗隕石的需求是第一個關鍵,溝 07/28 07:14
oopFoo: 通再溝通,沒其他法子。就算所有都作對了,也不保證成功, 07/28 07:16
oopFoo: 開心做事就好了。謀事在人成敗由天 07/28 07:18
Druid: 推 我們team算是一個成功的敏捷範例 我認同這篇內容 07/28 10:42
Druid: 敏捷跑得好 應該是大家都輕鬆 客戶也開心 但是要跑得起來 07/28 10:43
Druid: 需要超罩的主管+自律的工程師 人力素質PR95以上 07/28 10:45
Druid: 這真的非常不容易 所以失敗的敏捷居多 07/28 10:47
jacklin2002: 加班過勞死的工程師轉生到異世界開始研究敏捷開發 07/28 18:27
v86861062: 推推 07/29 16:41
shooter555: 能壓榨員工的敏捷對老闆來說就是好敏捷 07/30 10:44
flowerbb: 推這篇 07/31 17:08
b25459870: 不太同意沒有時程 我覺得是宣言概念 比起壓時程 更注重 08/01 17:30
b25459870: 團隊自發自律 08/01 17:30