挺大一串討論串。
可以從裡面看到各種不同的想法，有交集、共識、不同意見，而這些都是學習的養分。
是個很不錯、適合討論的一個主題。
---
你出團的時候，團隊有沒專門的輔助角色呢？例如專門放靈氣的聖騎士 XD
我想到當時的主坦，連解個任務都要別人幫忙的窘境。但至少主坦的缺很多。
有種：Scrum Master 天賦要點過去，得花那麼多精力跟時間養成，要稱職還得吃點天份，點爛了還不能重洗天賦。
我對Scrum中的Scrum Master一直有一個不太認同的感覺。Scrum Master的master就是一個大師的意思，所以本身要對Scrum要有深刻的理解以及自己的看法。但是scrum team中擺了一個scrum master本身就是一個錯誤的事情，為什麼每個scrum team都要有一個scrum大師?
試想想看一個scrum team可能會怎麼形成的?
1. 新創團隊，可能人不超過10個
2. 中小公司，由上而下想要導入敏捷
3. 大公司，某個小團隊想導入敏捷開發流程
這三種團隊scrum master會怎麼產生的?
1. 新創團隊每個人都扮演很多角色，要一個專職scrum master根本就超奢侈
2. 中小企業，可能中高主管有敏捷想法。但是這些主管可能都扮演管理職，而基層團隊沒有人比老闆有scrum知識，誰來當scrum master?
3. 大公司的某個小團隊想要導入敏捷流程。通常也沒有人適合當scrum master，因為他們一定扮演了manager, tech lead, 產品經理等等的角色，本身都有一些其他職責。畢竟組織本身不是從敏捷發展起來的，本身就不是原生的敏捷組織，scrum master找誰來做都怪怪的。
所以scrum master的角色定義根本不符合現實情況。那什麼時候才可能會有scrum master呢? 就是找外部的教練，或說是找一個"顧問"來協助團隊走向敏捷。但是這個scrum master本來就不是屬於一個team的，而是找來的顧問，可能幫助公司的整個組織，或是部分組織服務的功能性角色。所以每次一開始接觸scrum的人都會問，到底誰要來當scrum master? 我覺得每次大家都在討論一樣的問題，那scrum master這個角色本來就有問題。問題就在於根本就不需要強烈要求有scrum master這個角色。
所以我更贊同的是，不需要scrum master，或是每個成員都是scrum master，透過retro，透過實際感覺去調整屬於團隊的scrum流程，而不是一個人要扮演一個scrum master。相信我，你去看看你的團隊中任何一個成員都不適合當scrum master。除非你們組織中已經有成功的敏捷團隊，而這個團隊中某個人出來協助其他團隊的教練，那他才是那個scrum master。對於一個從無到有的scrum team，不應該選一個人來當作scrum master。
#個人淺見
#希望有人打臉
#跑Scrum一年半的小小心得
跑scrum一年半的小小心得 在 [請益] 公司轉型scrum 重談offer - 看板Soft_Job - 批踢踢實業坊 的美食出口停車場
const N = 'U'.charCodeAt() + 'K';
// ------- 前情 ----
我是前端工程師，大概從 VB6 開始做 windows 視窗應用程式介面
Web 是從沒 jQuery 且溝通主流也非 json 而是 XML 時代開始寫的，目前擅長 Vue
現職公司一開始進去是開發 jQuery 前端專案，打包工具是 gulp
後來因為業務需求讓我去從無到有建立一個 Node.js 專案，目前持續運作中
而前端專案因為日益增長的需要，許多元件改用 Vue 製作
為了嵌回去相容舊 jQuery 程式碼架構，跟另一個妹子工程師合作
開發了 Rollup compile Vue component 成一支 js 再 load 進去跑的自動化流程
一年前因為業務接了一個遊戲開始學 cocos，後端公司棄 Node.js 故又重學 C#
半年前因為客戶需要，又獨自用 Vue 開發 website 做了大量 CSS / SVG 動畫特效
比如結合 Vue 特性讓 SVG dom 在 RWD 任意長寬繪製不等曲率的貝茲曲線外框
// ------- 正文開始 ----
公司日漸不穩，獎金從兩年前的 2 個月到今年只能領 0.5 個月，一些人離開了
長期以來應徵前端工程師卻被叫去做很多後端工作，未告知即把 title 換成全端
加上公司實驗了 scrum 一年後決定完全走向 scrum，所以想跟公司重談 offer
對公司來說，scrum 是一種信仰，堅信敏捷是產品唯一成功之道
於是我們的遊戲儲值從手機 app 髮夾彎成桌面區塊鏈連動 metamask
躲過了交易抽成，躲不過區塊鏈加密貨幣風暴
公司從前後端分離、有 QA 有組織的公司，變成敏捷開發小團隊，不分前後端沒 QA
要求每個工程師十項全能，覺得這樣才可以有人請假時別人接手
我的信仰不足，只能緬懷以前組織分工明確的美好
那時同為前端的妹子工程師跟我任一人請假時都能互相 cover
可轉型 scrum 後我與她分開，請假只能找組內的人支援
後不知前，前不知後，分工混亂之火在公司內被點燃
人力不足是公司一直以來都在面對的問題，因為他們盼望拿 N - 10K 找全能人才
想回到過去，前端後端各自明確，雖每人開發專案不同但支援維護時技術沒問題的時代
但公司對 scrum 的決心如脫疆野馬一路狂奔，把敏捷做成隕石開發也要 scrum
梁靜如給再多勇氣應該也不敢在板上用 N 找 C# + Node + Vue + Cocos 都會的人
// ----- 協商狀況 -----
公司有展現誠意，談之前主動先幫我加成 N+15K，並認為這是恩賜沒幾個人有
可回顧一路來我在公司走過的足跡 cocos js css ts vue Node.js PHP C# Redis ...
我試著提了 N+25K，向公司說如果沒這個數字我應該不會想做這麼多技術面不同的東西
公司的反應
Q: 你就算會一堆語言，你也不是同時寫
A: 不只語言用法不同，還要懂公司的商業邏輯，都需要時間學習成本
Q: 語言只是換寫法，邏輯都一樣，前後端根本沒差
A: 前後端甚至前端在 web 與 cocos、後端在演算法與 DB 相關 know how 都不同
Q: 產出品質是 RD 自己的責任，公司不需要 QA
A: RD 或PO / PM 是規格的創造者與開發者，QA 才能從第三方角度去驗證
Q: 美術沒工作時幫忙當 QA 測試產品，展現 scrum 團隊意識，很棒
A: ....美術私下反應這超不尊重他們的專業
Q: 就算前端去寫後端他也不用真的很精通
A: 公司讓一知半解的人去寫 server 只會加重後端資深工程師 review 的負擔
Q: 你要的話也可以不加薪以後純前端，但打 KPI 就是對團隊沒貢獻的角色
A: ....直接威脅了，無話可說
// ------ 意外收穫 -----
或許是意氣用事，或許是心有不甘，我把 Linkedin 打開後將自己的技能填了上去
意外收到面試，也上線做了測驗，拿了不錯的分數去新公司談 N+25K
已收 offer，工作內容單純只寫 Vue，新公司前後端分離且有 QA team 是吸引我的點
考慮的點
1. 舊公司老闆除了公司營運方針很奇怪外對員工親和好相處，新公司未知
2. 舊公司營收一落千丈但有富爸爸，新公司穩定運作多年
3. 舊公司的產品商業邏輯是我比較有興趣且擅長的，新公司未知
4. 舊公司跑 scrum team 的夥伴大多磨合過了，新公司未知
5. 舊公司在技術選型方面沒權亦無責，新公司要負責帶前端從 .Net MVC 轉型 Vue
6. 舊公司可能這個 sprint 寫前端下個寫後端再下個兩邊各寫一點，新公司純前端
除此之外還有兩個機會
一個是 Vue + Node.js 全端，連新創都談不上的類物聯網，沒 scrum 因為根本沒 team
因為我過去有開發 NAS 經驗，要一條龍把嵌入式系統的資料即時連網
以前是定期去撈機器 data 產出 report 寄給客戶
未來用 Node.js 讀 data 開 http server 前端寫 Vue 即時資料視覺化
談到 N+35 K 但能做多久連業主都不知道
另一個是離職的妹子工程師在新公司要廣徵 Vue 一樣開到 N+15K 但工作內容單純很多
完全是自己擅長的領域，合作的又是熟悉的同事，默契好到不用註解對方就知道你在寫啥
板上有看到我的前同事發文，也是在這一波混亂中離開的，離開後也拿到很好的職務
讓我也開始思考自己是不是要離開這個根本稱不上舒適只是習慣了被搞的舒適圈
公司已經言明 N+15K 是給我的極限也沒得談了，不然如果有機會 N+25K 就留了吧
不知道有無曾經面對公司轉型 scrum 的板友可以給點意見
是否往 scrum 走就是一個不尊重專業、大家都全端又沒有 QA 的開發環境?
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.169.59.7 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1657340052.A.A27.html
只是每兩週擬定一個目標，時間內做好份內工作，上線看反應再調整下個 sprint 計劃
所以今年遇到 scrum 是不分前後端不分職位甚至沒有 QA 我也是滿頭問號
※ 編輯: shter (1.169.59.7 臺灣), 07/09/2022 12:51:21
最初公司的組織分工專精效率不錯，做事情目標明確也有衝勁
付出都有得到回報，獎金夠高，前端的同事有人請假要互相支援都沒問題
但拆成 scrum 小組編制後你的代理人成了另一端的工程師，支援困難
前端又分成 web / cocos，自己就要先學兩套不同的技術才能勝任工作
然後考核又變的相當繁瑣，一堆奇怪的互評，制度讓人無法專心應付工作
看著原本對公司有向心力的同事一個個感受到公司變了不如求去的消極態度
實在很難想像老闆們到底是遇到了什麼樣的 scrum 指導
非要把一個大型專案拆成幾個部分讓每個小組用一前一後漸進全端去進行
對員工而言，過往瀑布式開發反而目標明確
公司強調 scrum 是有效率的、比較能切合市場應變的
但員工看到的是過去半年可以上線一個專案，新的 scrum 專案一年半了還上不了線
說是敏捷來配合市場改變開發方向，實際上一堆東西做到一半砍掉
公司要大家把產品當成自己的事業去努力，卻不斷以敏捷為由砍掉大家努力的成果
誰會樂於一直砍掉自己的心血呢....
也知道公司正走在那些教科案例踩過的痛點上，似乎是轉型必經之路
如果能親身經歷 scrum 轉型的過程，也算是人生中的一個經驗吧
今天看了很多 scrum 文章，用別的一群人才成功，應該也是必然的
https://buzzorange.com/techorange/2017/07/05/why-scrum-doesnt-work-in-asia/
看這篇文章有提到
任何公司裡有更強的政治權力的人都能隨意蓋過 Product Owner 的決定！
Product Owner 基本上就是個裝飾人物，對他/她管理的產品沒有任何控制力！
敏捷方法中所需的優秀成員及軟體開發人員通常都不便宜！
其實就是公司面對的狀況...
感慨的是不論你或其他人，離開公司都馬上換了多十幾二十K 的 offer
且專注於工作或產品本身而不是有無遵守 scrum 與敏捷的思維
不過出價低於市場行情請不到符合敏捷要求大神也是需要時間去推升的
改革或變法不可能一次到位，即使我留下來也會有這樣的覺悟
只是公司覺得給很高的薪水，一開履歷卻發現外面很多更高薪又單純的工作機會
真的是五味雜陳，畢竟還在公司一天就還是希望公司的制度跟產品能成功
偏偏你自己的薪水就比外面公司給的低，如何期待公司能招來比你更強的大神
※ 編輯: shter (27.246.132.217 臺灣), 07/10/2022 00:26:11
特色是態度先於能力、不分前後端純看問題的解決分工、成員彼此補位
我覺得成功的實例有它的天時地利人和，我也不敢妄言公司未來成敗
對基層員工的我們而言目前感受到這些信條帶來的問題多過好處，如此而已
對 $$ 感到委屈我不否認
以前有明確的目標、有價值的產品、有適合一起工作的人，就算多 cover 一點也很開心
現在公司從兩年前幾乎老員工覺得完美的工作環境變得怨聲載道，就開始向錢看了
原本是想過要達到一個數字自己才會心甘情願做這麼多事
被公司否定後想拼盡全力用 Vue C# Node.js PHP cocos 加總技術去面試證明全端價值
沒想到光是在 Vue 的前端專長就可以比現職公司加完薪還多一萬，秒拿 offer
其實自己受到的打擊也不小，原來這兩年薪資跟市場脫勾有點大
這間公司還是有其他優點值得留下，文章只是如 scrum 聚焦在解決問題所以不言其他
對敏捷和 scrum 我自己也有很多誤解需要檢討，不能單從公司政策對它有偏見
新 offer 也要在這週內決定要離開就得提離職，看完板友推文心裡有底了，謝謝大家
※ 編輯: shter (1.169.59.7 臺灣), 07/10/2022 09:42:14
如果 scrum 是信仰，我還無法感受到神的開示，能應付各端業務充其量算是入境隨俗吧
因為 scrum 解決了部分問題同時，卻帶來其他的新問題，且持續至今沒有解決
對團隊成員而言，喊 QA 已是無數次 retrospective 的結論
但公司持續宣導補位跟無 QA，卻沒有 scrum master 出來領導團隊在 sprint 中分工
所有的 RD 將開發塞滿 point，只為了在 deadline 前上 production
然後叫美術來當 QA，不尊重專業到對方寧可離開這間公司
今天也有板友推文他們的 scrum 中前後端各自分工亦有 QA，顯然世事無絕對
或許 scrum 對公司不只是解決開發上的問題，也要解決提出問題的人，免得不合
當然，公司也可以選擇讓 scrum master 來指導如何在沒有 QA 的團隊中進行測試驗證
是要解決不合的人，還是解決開發團隊遇到的難題，端看公司智慧
如果開發團隊面臨的問題解決了，那麼願意相信 scrum 是有幫助的人才會增加，是嗎?
一如板友說的，自己的價值只有出去試過才知道
或許，這就是東漢末年荀彧忠於漢室又想讓曹操成功的心情吧
不過來板上請益有很多收穫，也慢慢改變了我原本的想法，很謝謝各位板友
因為專心做產品上線、充滿成就感、獎金領的開心、工作面向單純
現在這種 scrum 要消耗在開發外的心力自己覺得要多 25K 才能吞，當然就談不攏囉
如果團隊的問題能獲得解決，各司其職把產品做好，也不見得會想往上喊
就像妹子工程師那邊同樣只加 15K 但還是會列入考慮一樣
Offer 的薪水雖是主體，文化與工作內容還是會影響選擇啊，多元比較囉
// ----- 更新 -----
看完您在下面的新文章謝謝你的意見，公司已經變了就不要緬懷過去
確實，scrum 團隊的問題公司想不想解決也不是團隊成員的勞工們能決定的
那就讓事情單純化....反正公司肯 +25K 那要配合公司政策也沒問題
如果公司不肯加那就去外面其他 +25K 的公司或 +15K 有熟人的公司
雖然新公司很多未知元素，起碼已知是前後端分離有 QA 的組織架構
不管會的技能多不多、值不值錢、公司願不願意給，自己的價值都不用被公司局限
※ 編輯: shter (1.169.59.75 臺灣), 07/11/2022 07:12:30
Scrum 累積經驗、持續改善、自我管理這些法則其實有落實於我們團隊
如 state machine 管理 life cycle 般的運作流對寫程式的人是熟悉的
每次執行階段到 retrospective 都有檢討出問題，但跑偏也由此開始
近半年我們於沒有 scrum master 狀態下運作，案子每兩週要交付客戶 review
為了敏捷調整，開發團隊日益走向每個人專精於自己擅長的部分以維持開發進度
很自然的前後端分離，前端的 web 與 cocos、後端的 state machine 和 DB 擅長也不同
因為從開發經驗的累積上，團隊自然發現專精分工是最有效率的模式
若跨領域結對開發，反而讓兩個工程師都變慢而來不及應付客戶改動的需求
初見時美麗的她，隔月再看已認不出來，檔案程式結構因業務需要在月內有多次改動
所以你下個月和陌生的那端約會時，她不但帶給你新鮮感，也讓你捉摸不定
即便是簡單的邏輯調整，她都可能耍小脾氣給你修不完的 side effect
因為你沒注意到她的地雷踩了坑，還得靠她的現任修好 bug 哄她消氣
最終，走向自己領域專精成為團隊維持開發效率的心得，激化了專業測試驗證需求
渴望 QA 拯救產品穩定度來自長期經驗累積的自然催生，無奈與公司政策違背
公司希望 scrum 團隊長成它想要的模板，不知基因突變還是環境污染終究長歪了
或許有 scrum master 帶領，在提出 QA 需求時給予調整或從基礎上用不同的開發模式
解決團隊的問題與困惑，那不用 setInterval 說 scrum 的好開發團隊也能自然感受到
感情需要時間培養，scrum 需要時間內化，但過了熱戀期後生活上有許多瑣碎待磨合
無法改變、共同找出兩人都能接受的方向，分手前的時間都是在消磨彼此的感情而已
下一次，希望 scrum 園丁能養出老闆想要的花色，而不要產品成功上了方向卻走偏了
※ 編輯: shter (1.169.59.75 臺灣), 07/12/2022 20:11:42
... <看更多>