看板 Soft_Job
作者
標題 Re: [討論] 關於敏捷越來越深入台灣職場
時間 Fri Jul 26 12:13:55 2024
作者
標題 Re: [討論] 關於敏捷越來越深入台灣職場
時間 Fri Jul 26 12:13:55 2024
※ 引述《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 (臺灣)
※ 作者: oopFoo 2024-07-26 12:13:55
※ 文章代碼(AID): #1ceoABPF (Soft_Job)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1721967243.A.64F.html
※ 同主題文章:
07-25 10:30
07-25 11:52
07-25 16:17
Re: [討論] 關於敏捷越來越深入台灣職場
07-26 12:13
推 : 敏捷是快速取得回饋並持續改善 廢物公司只想快速結案死不改善1F 07/26 12:22
推 : 你這樣講我勉強認同，唯一一個點，Rd主導開發，但
需求還應該給專業的處理吧，我想，jira真的超雷的
，slack還比較有用處3F 07/26 12:27
需求還應該給專業的處理吧，我想，jira真的超雷的
，slack還比較有用處3F 07/26 12:27
推 : 推, 真的大部分的scrum都是雷缺6F 07/26 12:31
推 : 給原PO:你應該是誤解了 "主導" 可參考"安燈系統"7F 07/26 13:04
推 : 可用的軟體 重於 詳盡的文件 那可用是誰說的算？8F 07/26 13:14
→ : 這樣是不用結案的概念。9F 07/26 13:18
→ : 你說的是理論 他說的是現實10F 07/26 13:26
→ : Linux Kernel就是很好的敏捷案例。APTON大的"安燈系統"比我剛才想打的一串的好，精簡清楚。11F 07/26 13:29
→ : 說得很好.下次可以直接用貼的.但沒有解決實務問題13F 07/26 13:46
→ : Linux kernel project 是agile? 給一下出處好吧。14F 07/26 14:05
推 : 員工痛苦股東才會爽15F 07/26 14:09
→ : @Apton, @原Po, 兩位的'主導'定義好像跟一般不太一樣?能否詳細說明一下，這裡的主導是只有出問題時停下來嗎?
還是包括專案的成果評估，方向，業務目標在內?16F 07/26 14:18
還是包括專案的成果評估，方向，業務目標在內?16F 07/26 14:18
→ : 大家都說不是敏捷，那那間公司跑的是真敏捷？19F 07/26 14:50
→ : 按上方的定義：不用結案的公司。20F 07/26 15:20
推 : 國外公司都受不了被壓榨的工作模式，早就已經放棄敏捷開發
就台灣人自己越來越盛行www21F 07/26 15:39
就台灣人自己越來越盛行www21F 07/26 15:39
→ : 咦...這個說法，給個出處好吧。24F 07/26 16:10
推 : @atst2 如果以"做產品"的角度 當然是都要包含
不然最後遇到狀況，開發還是會回頭去問同樣的問題
但是大部分的公司都是分工不合作 各團隊的距離很遠25F 07/26 16:14
不然最後遇到狀況，開發還是會回頭去問同樣的問題
但是大部分的公司都是分工不合作 各團隊的距離很遠25F 07/26 16:14
推 : 台灣老闆眼中的敏捷=你各位員工員工做快一點28F 07/26 16:50
→ : 怕加班的我把敏捷點滿了...還是繼續加班29F 07/26 16:50
→ : 痛苦就不是敏捷？所以敏捷式宣言包含不能痛苦是不是30F 07/26 17:38
→ : @APTON, 這個"都要包含"的意思，是指第一線開發者還要兼職31F 07/26 18:01
噓 : 很多時候工程師的立場跟客戶就是相對的，這樣要怎麼玩下去？很多工程師以刪客戶需求作為自己的kpi. 這樣可以良好互動？32F 07/26 18:02
→ : PM, Market，客服，主管等任務嗎? 還是你有別的意思呢?
還望更進一步提供說明.35F 07/26 18:02
還望更進一步提供說明.35F 07/26 18:02
噓 : 我看過太多太尊重工程團隊的公司，搞到最後就是沒有人可以叫他們做事
PM, 客服, 主管, 客戶通通都不行，最後動用到創辦人下來盯場，但是在看不見的地方還是偷雞摸狗，客戶幹到翻天，這樣會比較好？
理想當然是工程師能夠自律，能夠以幫助客戶解決問題為目標，現實就是自律的人太少了..給予工程師過大的自由跟權限就是什麼事都做不成37F 07/26 18:06
PM, 客服, 主管, 客戶通通都不行，最後動用到創辦人下來盯場，但是在看不見的地方還是偷雞摸狗，客戶幹到翻天，這樣會比較好？
理想當然是工程師能夠自律，能夠以幫助客戶解決問題為目標，現實就是自律的人太少了..給予工程師過大的自由跟權限就是什麼事都做不成37F 07/26 18:06
推 : 推45F 07/26 19:26
→ : (顧客，pm，主管）決定功能，工程師決定時間與作法。
不過夢想很豐滿，現實很骨感。當壓力來的時候，加班，壓時間，各種非敏捷的作法通通上來，能夠徹底執行敏捷的團隊還是少。而且敏捷最重要的是所有人都須認同也配合，這也是不容易的。沒有良好的團隊，或者強力溝通能力的主管，敏捷不容易執行也不容易成功。這有點像社會主義，理念良好，但常常淪落到獨裁者模式。敏捷是需要上面的人全力支持，加上所有人的配合才行。國外我看到成功的案例比較多，台灣可能我也是見識少，看到的比較少。
敏捷真的就是人的互動才是重點，但人的互動真的是最困難的課題。要願意信任也是個困難。46F 07/26 19:35
不過夢想很豐滿，現實很骨感。當壓力來的時候，加班，壓時間，各種非敏捷的作法通通上來，能夠徹底執行敏捷的團隊還是少。而且敏捷最重要的是所有人都須認同也配合，這也是不容易的。沒有良好的團隊，或者強力溝通能力的主管，敏捷不容易執行也不容易成功。這有點像社會主義，理念良好，但常常淪落到獨裁者模式。敏捷是需要上面的人全力支持，加上所有人的配合才行。國外我看到成功的案例比較多，台灣可能我也是見識少，看到的比較少。
敏捷真的就是人的互動才是重點，但人的互動真的是最困難的課題。要願意信任也是個困難。46F 07/26 19:35
→ : @oopFoo，如果一個方法論，需要依賴人的素質，才會有用, 這個方法論能稱得上是方法論嗎?
反過來問，有沒有案例是，有良好的團隊但不走敏捷，所以失敗，改用敏捷後就成功了?
還是只要有良好的團隊，不論走不走敏捷，其實都無所謂呢?57F 07/26 19:54
反過來問，有沒有案例是，有良好的團隊但不走敏捷，所以失敗，改用敏捷後就成功了?
還是只要有良好的團隊，不論走不走敏捷，其實都無所謂呢?57F 07/26 19:54
→ : 應該說敏捷是成功率比較高的方法，所有方法都有成功的機會但敏捷迭代，多許多機會成功。
當初xp的團隊，是良好的團隊，但最後他們的案子是被取消的62F 07/26 20:08
當初xp的團隊，是良好的團隊，但最後他們的案子是被取消的62F 07/26 20:08
Re: [徵才]麥奇數位誠徵 DevOps 成員(40K~80K) - 看板 Soft_Job - 批踢踢實業坊
作者: NDark (溺於黑暗) 關於方法論， 我跟幾個國外的前輩在去年做了一個針對遊戲產業組織文化及專案開發的問卷 叫 "The Game Outcomes Project" 在最後產出的五篇統計分析文章中 特別有一篇談到方法論( )
作者: NDark (溺於黑暗) 關於方法論， 我跟幾個國外的前輩在去年做了一個針對遊戲產業組織文化及專案開發的問卷 叫 "The Game Outcomes Project" 在最後產出的五篇統計分析文章中 特別有一篇談到方法論( )
→ : 因為Chrysler被Daimler-Benz買走，新東家有不同想法。67F 07/26 20:16
→ : 在您繼續回覆，我先提一下個人對Agile/Scrum/Lean的想法，68F 07/26 20:17
→ : 老實說，沒有研究。這都是我們觀察跟想當然爾的69F 07/26 20:18
→ : 個人覺得敏捷以及相類似的方法論，其實是有一定道理的。
但個人一直覺得，這些方法論，很多還只是理論, 而非定理.從理論到落實一直有很大的落差，而這些落差，目前看不到相關推廣的人，有想去填補的努力在，而一直是不斷強調理論有多美好.
也許有團隊/研究已經在努力了，但個人見識有限，無法知曉.在這種情況下，去指稱某些公司跑的是'假敏捷'，敏捷"不是"什麼，是沒有意義的。因為對於想要進入"敏捷"，享用到好處的團體而言，他們想要知道的是，彌平理論到實作間的落差的手段。70F 07/26 20:19
但個人一直覺得，這些方法論，很多還只是理論, 而非定理.從理論到落實一直有很大的落差，而這些落差，目前看不到相關推廣的人，有想去填補的努力在，而一直是不斷強調理論有多美好.
也許有團隊/研究已經在努力了，但個人見識有限，無法知曉.在這種情況下，去指稱某些公司跑的是'假敏捷'，敏捷"不是"什麼，是沒有意義的。因為對於想要進入"敏捷"，享用到好處的團體而言，他們想要知道的是，彌平理論到實作間的落差的手段。70F 07/26 20:19
→ : 敏捷好棒棒，每間都說在跑敏捷，需求完成率很高80F 07/26 20:30
→ : 如果沒有這個手段，而只能依賴團隊人員素質的話，老實說,與其引入敏捷，不如去增進HR團隊的能力還比較實際一點。81F 07/26 20:33
→ : 我做上百個大大小小(錢)的案子，人員倒是沒有哪些一百幾十的案子。但三五七個倒有。就是沒有方法論。
但全部準時收錢。
數學解題，就是從基本的去解就是好的方法。哪些什麼特解，遇到某類題目有專門快速的解法，就是爛解法。83F 07/26 21:16
但全部準時收錢。
數學解題，就是從基本的去解就是好的方法。哪些什麼特解，遇到某類題目有專門快速的解法，就是爛解法。83F 07/26 21:16
推 : 只能說牽扯到人的理論在實際上就是會有落差88F 07/26 21:41
推 : 台灣文化融合的敏捷等於快速結案89F 07/26 21:47
→ : 很多人都認為，用了某某方法，我也可以做出一樣的系統.正如看著菜譜，人人都是大廚的概念。90F 07/26 23:20
推 : 推atst292F 07/27 00:03
→ : Ron 讓我學到很多，感謝分享
*Ron的文章93F 07/27 02:35
*Ron的文章93F 07/27 02:35
→ : extreme programming系列的書，是一個好入門的書，它提倡test first，短時間的迭代，standup meeting，pair
programming和如何計畫，都有很好的解釋跟緣由。現在的人使用敏捷大部分都不了解背後的緣由。toytota way，也是一個很好的管理想法，雖然跟軟體有點遠。
好的團隊是需要時間去互相磨合，也不是hr找對人就可以的。所以敏捷第一條就是"個人與互動"。這真的是最難的課題。95F 07/27 06:26
programming和如何計畫，都有很好的解釋跟緣由。現在的人使用敏捷大部分都不了解背後的緣由。toytota way，也是一個很好的管理想法，雖然跟軟體有點遠。
好的團隊是需要時間去互相磨合，也不是hr找對人就可以的。所以敏捷第一條就是"個人與互動"。這真的是最難的課題。95F 07/27 06:26
噓 : Jira只是工具 雷在哪
錯的是用的方式吧102F 07/27 06:57
錯的是用的方式吧102F 07/27 06:57
→ : 最後我想強調的是，敏捷強調的是心態。但理工人喜歡方法，想找SOP，想找工具來解決問題。敏捷宣言就是想告訴你那是次要的。正確的心態才是比較重要的。104F 07/27 07:09
推 : 我看得少.如果 Debug 和帶新人
不算的話.pair programming 我沒看過餒
兩位程式設計師，寫一份碼
不吵架，可能嗎？
（當然，平常就是用嘴巴寫程式
那種不討論）107F 07/27 07:45
不算的話.pair programming 我沒看過餒
兩位程式設計師，寫一份碼
不吵架，可能嗎？
（當然，平常就是用嘴巴寫程式
那種不討論）107F 07/27 07:45
→ : 我懂了，敏捷就是宗教。站立會議就是早晚課，檢討會議就是發露懺悔。每次迭代都是一個輪迴。好好照著做就可以成佛。不成的話，就是心態不正，信仰不足。持續做下去就對了。113F 07/27 07:50
→ : pair programming很少見，大部分人不願意試，主要就是困難問題一起pair，或帶新人大家比較願意做。
站立會議，檢討會議現在都太形式化了。開會是要了解跟檢討程式問題。其實兩三個人一組，不要超過五六個人參與，簡短結束。當變成形式的時候，就是要換個方法做。可惜，現代管理，無法從SOP跳開。敏捷就是團隊要找出適合的方法，不需照著教條做。116F 07/27 07:59
站立會議，檢討會議現在都太形式化了。開會是要了解跟檢討程式問題。其實兩三個人一組，不要超過五六個人參與，簡短結束。當變成形式的時候，就是要換個方法做。可惜，現代管理，無法從SOP跳開。敏捷就是團隊要找出適合的方法，不需照著教條做。116F 07/27 07:59
推 : 國外立意良好的東西進到台灣後都會歪斜123F 07/27 09:35
推 : pair要好好分組訓練 因為這種新制度在學校職場都沒教
新制度的引入就跟新機器一樣要有教學124F 07/27 09:46
新制度的引入就跟新機器一樣要有教學124F 07/27 09:46
推 : 敏捷很容易壓榨啊 那個宣言都是強者 敏捷就是很多強者一起合作 不會掉棒
不欣賞工具這段還是怪怪的 抓戰犯用excel管也能抓126F 07/27 10:11
不欣賞工具這段還是怪怪的 抓戰犯用excel管也能抓126F 07/27 10:11
→ : 信奉敏捷式的人都沒有拿研究或數據佐證 只會說你成效不彰就是沒有敏捷/不夠敏捷 論述充滿不可證偽性129F 07/27 10:14
→ : excel的好處是，pm花時間填資料就沒那麼多時間騷擾工程師131F 07/27 10:53
推 : jira是工具，不會扭曲流程，如果流程有問題，不能怪jira
jira也可以不壓時間啊，是用法問題132F 07/27 12:18
jira也可以不壓時間啊，是用法問題132F 07/27 12:18
→ : 某種敏捷有一條規則是"成員都是專家" 而且都假設是全端的135F 07/27 12:25
推 : 須符合真空狀態下，且專家是球體的時候才有效136F 07/27 12:55
→ : 預估根本不準，不然就不會不做不知道一做嚇一跳了，
待過某家公司，就是把預估當成是設定，
一個spint一定要完成，拖延到的話PM還會很不爽。137F 07/27 13:57
待過某家公司，就是把預估當成是設定，
一個spint一定要完成，拖延到的話PM還會很不爽。137F 07/27 13:57
推 : 我還遇過直接把planning 的點數當成kpi的呢140F 07/27 14:04
推 : 嗯...果然根本沒有打算討論，只是想趁機偷酸，還好沒浪費時間回覆141F 07/27 16:32
推 : 真的，還遇到一個連規格都不會開的在那一般說要導入敏捷xD143F 07/27 17:54
推 : 覺得問題點在於1. 團隊了解敏捷開發是什麼？ 2. 團隊要知道怎麼執行？ 3. 上頭有權力者要相信 了解 決心推動敏捷開發不懂 執行的不是敏捷 沒有權力只能推半套 都會爆炸
想想人也是很重要的 只有工具也是不可行 再好的工具遇到錯的人 不去用或是用錯也是白搭145F 07/27 18:41
想想人也是很重要的 只有工具也是不可行 再好的工具遇到錯的人 不去用或是用錯也是白搭145F 07/27 18:41
→ : AGILE的專家們，請問AGILE 在最開始前，要先寫一些底層的東西嗎? 要架環境嗎? 要的話，要算進sprint?
會人人都有工作? 還是只有某幾位負責?
再來，何時on production? 按國外大神的說法，沒提到呢若成員的程度差異，導致他的工作無法如期完成，會不會大家都完工了，還要等他? code review 會算進sprint?review 後的modification 要算下一個sprint?150F 07/27 19:10
會人人都有工作? 還是只有某幾位負責?
再來，何時on production? 按國外大神的說法，沒提到呢若成員的程度差異，導致他的工作無法如期完成，會不會大家都完工了，還要等他? code review 會算進sprint?review 後的modification 要算下一個sprint?150F 07/27 19:10
→ : 1)看團隊自己決定，2)人人有工作，3)隨時都是production，4)每個人拿自己適合的工作，有問題在standup meeting就要提出，如果還是不能解決，轉給可解決的人。如果無人可解，看是要花時間研究，或放棄選另一條路走。
code review完才算完成，但有的team不用code review。
進度其實是檢視，而不是要追求的目標。做不到，做不快，就157F 07/27 21:35
code review完才算完成，但有的team不用code review。
進度其實是檢視，而不是要追求的目標。做不到，做不快，就157F 07/27 21:35
推 : 待過4個團隊，沒有一個agile是跑到起來的XD163F 07/27 21:44
→ : 是砍功能。如何取捨，排進度，一門藝術。164F 07/27 21:46
--
作者 oopFoo 的最新發文:
- 這次的縮缸問題終於到了段落。這次的bug正式名稱為"Vmin Shift Instability" 確定長期過高電壓燒到縮缸的是clock tree circuit 。縮缸的clo …173F 59推 3噓
![]()
【AVITA】15.6吋i5簡潔美學筆電(i5-1235U/8GB/512G SSD/W11H/SATUS S102/FHD/粉)【9900元】 i5-1235u 15.6 ips螢幕 8GB dd …73F 42推- 35F 12推
- 51F 7推 14噓
- 23F 2推 14噓
點此顯示更多發文記錄