分享一下我自己經歷過的幾間公司： 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.cc), 來自: 174.164.246.228 (美國) ※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1732790712.A.418.html ※ 編輯: RiverSki (174.164.246.228 美國), 11/28/2024 20:19:16