自己隨意摸索個兩個月後，
剛好有機會參加外訓
由 AgileCommunity.tw,DevOps Taiwan,HashiCrop User Group TAIPEI,iThome 主辦的
Scrum Drawing Game 一日體驗營
這個課程是由講師 Juggernaut 用輕鬆風趣的方式帶領著學員以遊戲的方式體會為什麼 Scrum 要這樣跑。
課程細節就先不提了，主要精神就是要讓大家認識 Scrum 裡面的角色在 Sprint (衝刺週期) 內的職責履行
有興趣的話可以參考講師分享於 slideshare 分享的檔案(連結放在底部參考資料，感謝他以及眾多對敏捷產業無私奉獻的人)
那究竟 Scrum 主要分成哪些角色呢？(以下為個人見解)
首先來講講昨天提到的 user >> stakeholder
利害關係人。基本上跟專案有關，但沒有親身投入開發的人都算是利害關係人。
上至想做這個產品的老闆，旁至公司的行銷與法務，廣至同業競爭對手
有些專案不太方便接觸到實際的 user 時，往往還會展開 brainStorming
讓團隊自己腦補出多名 persona ，創造他們的興趣以及使用場景，甚至到取名字、貼照片、血型、星座
每天與他們培養感情，讓我們的產品可以更貼近使用者需求
(注:未經統計計算，了解 Stakeholder 的 Developer 防呆功能更完善。 ~~我可沒說誰呆~~)
產品負責人，並且翻譯著 Stakeholder 所說的話，使其變成相對好理解的工程師語言。
並且也因為有這個角色的存在，讓團隊理解為誰而戰、為何而戰
從單單的接受 user 所提的需求 變成 共同討論怎麼做比較好
從幫別人做東西 變成 這是我們的專案
(注:未經實驗證實，專案認同度可以有效降低離職率)
開發人員，團隊內的寶貝，是整個 Scrum 團隊內最軟的一塊。
很多書上都會說，Member 都是最好能夠跨職能的組成，但我這邊有另外一個見解。
當今工程師的職涯規劃多數走向越來越精細專精的部分(可能是因為薪資、興趣...種種原因)
真的很難讓專職於前端的工程師去寫複雜的 Java 邏輯(甚至是更新的語言)
也不太可能放著後端工程師獨自跟 scss 奮鬥。
所以我這邊是認為所謂的跨職能應該要改成跨穀倉團隊
當今天 Sprint 後端比例比較重的時候，
前端的人員也會因為 Sprint 的成敗是團隊的事情，去支援去幫忙測試。
這份主動性，會比本身技能樹的廣泛來得重要，總是有事情可以協助的。
(注:根據個人經驗，雖然前後端各自專精在 Sprint 的安排上會比較需要費心，但整體產出體感比較高)
敏捷教練敏捷大師，這是一個有很多面向的角色。但也常常陷入認知的誤區
這邊以常見的例子來講，諸君會覺得 Master 是底下哪種呢？
我個人認為 Scrum Master 比較像是位引導者
不論是 Agile 的精神、Scrum 流程甚至是團隊的規範
都是以引導的方式來展現給團隊，很少直接跟團隊說出答案(甚至舉出反例)
希望團隊能夠自己講出答案，自己做出承諾
就像我很喜歡 Agile Games 一樣，一開始會誤導參與者執行一些不符合敏捷精神的遊戲動作
然後引導其改善作法，營造出團隊自己想出 solution 的概念
讓團隊自己信服 “為何 Master 會要要求這些事”
也就是所謂的 aha moment 進而成為敏捷的信徒
(注：關於 Agile Games 以後我會專門出一天來講解)
不知道我所詮釋的角色跟諸君心中是否有出入，有的話也請各位在下方留言
讓我們一起切磋切磋
參考資料：
iThome鐵人賽
看影片追技術