分享一下我自己經歷過的幾間公司： 1. 職涯最初期，事後回想把 scrum 跑得最好的公司 是一間新創公司，Product owner(PO)就是老闆本人， 如所有的老闆一般，所有他想要的東西都想要最快速度拿到， 而這位PO的優點是，他知道不能要馬兒跑又不讓馬兒吃草， 所以在給他他最想要的東西的同時，他能夠接受其他事情延期， 並不會講出： 我是成熟的大人，我兩個都要。 這種屁話。 此外，所謂「他要的東西」，通常是真真正正的 MVP， PO 決定方向、優先順序，但怎麼驗證 MVP，是整個公司一起決定（沒多少人）， 大家都找到最小的成本去驗證這個功能是否被需要。 在這間公司工作三年，基本上，開發超過兩週的功能都是最後有持續在使用的， 我在的期間開發出來的功能，只有最後被更好的版本迭代掉， 沒有花了大筆資源（人力）開發，結果卻是進垃圾桶這回事。 結論： 曾經與一個前輩討論過，當一個團隊很少開發出不必要的功能的時候， 就是把敏捷的精神做得很好的象徵。 我可以說，這間公司是我待過最敏捷的公司， 有趣的是，這間公司在我離開前幾個月才開始跑所謂的 scrum。 因此，有沒有 scrum、sprint、retro、standup ， 對於是否敏捷，一點關係也沒有，這些工具名詞， 甚至我可以說，這些名詞與行為本身，其實不會幫助你更敏捷， 他還是會讓你保持原樣。 敏捷的團隊還是敏捷、導入了 scrum 之後，可以讓團隊更透明； 瀑布的團隊還是瀑布、導入了 scrum 以後依舊是老樣子。 2. 掛著 scrum 皮、骨子卻是瀑布 大約十個工程師的開發團隊、維護一個公司的重要產品， 100% 把瀑布做成 scrum 的團隊，每天有著 scrum 的皮、但在做瀑布的骨。 為什麼我這麼說？ Scrum 為了敏捷而生、敏捷的用意在於，在「改變中的需求、不確定的需求」的環境下， 保有工程師的產出能力。 我待的這間公司有這樣的需求嗎？ 沒有。 敏捷強調儘早驗證儘早確定資源是否投入、適時的調整人力資源在產品最需要的方向上。 如果沒有這樣的需求， Scrum 就是瀑布，因為你早期驗證做完也沒人給你 feedback， 那幹嘛不直接往最終目標瀑布下去就好了？ 這公司，有看板有 scrum 有 standup 有 retro， 但 retro 都在聊大家的心情、誰狗怎麼樣、關心一下少數族群（我）， 有在跑 scrum ，但最後變成了大家互相關心對方心情的「交談」， 產品方向上有問題嗎？我們下個 sprint 重心是什麼？有沒有什麼要砍、要加的？ 沒人在乎。 3. 瀑布與敏捷混合的公司 最後一間公司就比較有意思， 平常的時候很瀑布，但部分的專案可以跑得很敏捷， 這也是我待過最舒服也最有成就感的公司。 絕大多數的時候把 scrum 跑得很瀑布， 隕石砸下來可以、那瀑布就拉長一點，瀑布不想變長也可以，那就砍功能。 而有全新專案、提高盈利項目的時候， 團隊也能跑得很敏捷，盡快做出 MVP、盡快驗證、投資人力在最重要的地方。 必須說，從個人生活的角度，瀑布絕對是比敏捷舒服的方式， 因為你很清楚自己要做什麼事情，隕石掉下來就加時間或砍功能， 而敏捷是隨時都在想要怎麼用最小的資源來驗證假說， 假說成立以後，該把資源放哪裡可以效益最大化。 如果可以，我會想要瀑布敏捷兩個交替， 想認真搞產品的時候做敏捷、想讓心力休息的話做瀑布（專注在coding即可）， 是我最理想的環境。 -- 我的結論是， 與其扒著 scrum 這個詞不放， 我更在乎的是一個團隊的敏捷與否， 而一個團隊是不是敏捷，其實聊個十分鐘就能感覺出來。 至於工作能不能開心、能不能有 WLB， 主要還是看團隊氛圍，而不是瀑布還是敏捷。 從做產品的角度，敏捷絕對能提高產品存活的機率， 從工程師能維持專注的角度，瀑布能讓工程師更穩定的走在自己的規劃上。 可惜的是，絕大多數的我們沒辦法影響自己身處的團隊， 我也曾經天真的覺得，我體驗過敏捷團隊的好處、希望能帶給團隊正面的影響， 最後發現，一個不需要敏捷的團隊，是不可能把敏捷給跑好的，甚至說， 「為什麼要敏捷？」 如果一個團隊真實得不需要敏捷，那又何必強推呢？ 想通了這個問題， 我就開始能接受大家把 retro、standup、planning 亂搞了。 -- ※ 發信站: 批踢踢實業坊(ptt.org.tw), 來自: 174.164.246.228 (美國) ※ 文章網址: https://ptt.org.tw/Soft_Job/M.1732790712.A.418

推 kuosos520: 推 11/28 19:09

推 SkankHunt42: 這文章真讚 11/28 19:11

推 nayeonmywife: 推 11/28 19:13

推 Suleika: 大師返璞歸真惹 11/28 19:26

推 AoShenFengYu: 推 11/28 19:26

推 Csongs: 要有feedback才是重點 11/28 19:38

推 yuinami: 推 11/28 19:44

推 Arbin: 推 11/28 19:46

推 Ekmund: 推這篇 11/28 19:55

推 jackflu: 好文推推 感謝分享 11/28 20:08

推 wusbetz: 要敏捷不就為了可以在人才徵召上寫「我們公司跑敏捷我們 11/28 20:42

→ wusbetz: 很潮喔」嗎 11/28 20:42

推 Nitricacid: 推 11/28 20:43

推 melancholy07: 推推精闢 11/28 21:22

推 freeloop: 推！ 11/28 21:34

推 wayne0530: 這篇不錯 11/28 21:35

推 andytung444: 推 11/28 21:46

推 v86861062: 推推 11/28 21:58

推 imhaha: 推 11/28 23:08

推 holebro: 推推 11/28 23:20

推 APTON: 推 11/28 23:29

推 viper9709: 推分享~原來是這樣 11/28 23:55

推 dmeiki: 推 11/29 00:28

推 justaID: 推 這篇的心路歷程體會滿棒的 11/29 01:54

推 OwOptt: 推 11/29 03:07

推 jobintan: 敏捷或瀑布不是重點，員工有WLB比較重要。 11/29 06:51

→ jobintan: 臺灣有太多公司只知道毫無意義的瞎卷而已… 11/29 06:51

推 umidaisuki: 推 11/29 07:04

推 Lhmstu: 推 11/29 09:27

推 gn00672312: 推 11/29 09:49

推 koyosky: 推，我覺得你可以巡迴演講了 11/29 09:50

推 aquablue: 推 11/29 10:06

推 molopo: 推 11/29 10:10

推 f26724309: 那如果專案owner被主管意見綁架怎辦？ 我比如為了滿足 11/29 11:48

→ f26724309: 各事業體許願而做出來的功能 11/29 11:48

推 MelLynce: 推 11/29 13:27

推 brianwu1201: 推這篇 11/29 15:05

推 APTON: 如果許願不用付出代價，那遲早變成隕石 11/29 15:14

推 purplvampire: 我也覺得應該去演講洗腦那些高官 11/29 16:34

推 flowerbb: 推 11/29 17:36

推 kyukyu: 推 11/29 18:00

推 bewitchsky: 推 11/29 18:21

推 Dommgifer: 11樓正確 11/30 06:10

推 wkwrd: 你已經成為敏捷大師了 11/30 08:59

推 dream1124: 推 反墣歸真 11/30 13:18

推 shortoneal: 很多團隊，大老闆其實才是實質上的PO 11/30 19:06

→ shortoneal: 他會花錢找大師來教團隊敏捷開發跟scrum，但是自己不 11/30 19:07

→ shortoneal: 聽也不參與scrum lol 11/30 19:07

推 sumsum: 推這篇！ 11/30 23:38

推 lytt: 推 12/01 13:35

推 newbiepolice: 遇過聘請外國Scrum大師進來導入敏捷 12/01 15:54

→ newbiepolice: 專案執行一段時間後, 就高歌離席了。 12/01 15:55

→ newbiepolice: 留下了一堆手足無措的開發人員，與專案經理。 12/01 15:55

→ newbiepolice: (已將畢生所學傳授給你們，剩下就看個人造化) 12/01 15:56

推 apley: 還是那句老話【沒有對錯，只有適不適合】，適合就是好的 12/02 01:37

推 prag222: 掛名還是得收個過路費的,哈 12/02 11:43

推 GooglePixel: 對的 到最後最欠教育的還是PO 12/02 16:32

推 l42857: 講的真好 12/03 10:55

推 single4565: 推 12/04 00:27

推 vipri: 推 12/04 22:49

推 answermangtr: 推 12/05 09:30

推 umii: 推 12/05 13:39

推 Eide: 推 12/05 18:54