當一個Scrum Master 是一個怎樣的體驗？

Role 角色 · Product Owner · Scrum Master / Agile Coach · Development Team / Dev Team · Stakeholder TechBridge技術共筆部落格 Menu Home About Tags Archives RSS SignIn 前言 Scrum是一個以團隊為基礎來開發複雜系統和產品的敏捷開發框架和方法論。

相信很多軟體開發人員都聽過Scrum，而且也把它運用在產品開發中，然而每個團隊在使用Scrum時都會遇到不同的問題，有些是共通性的問題，有些是個別團隊所遇到的問題。

過去一段時間在筆者的職業生涯中因緣際會地經歷了開發者、產品負責人以及ScrumMaster等角色，對於不同角色的特性和所應具備的特質和能力以及Scrum的能與不能都有些許的認識。

接下來，本文將透過一個ScrumMaster視角去探討ScrumMaster在ScrumTeam中所扮演的角色和可能遇到的挑戰和機遇。

Scrum先修課：關於Scrum你必須先明白的專有名詞 Role角色 ProductOwner 負責規劃產品roadmap，負責釐清使用者和Stakeholder的需求並轉化成具有商業價值的UserStory，並評估Story的優先順序，決定哪些項目要從Backlog進入到sprint當中。

此外，ProductOwner也必須和DevTeam成員討論出Story的Acceptancecriteria和負責驗收成果 ScrumMaster/AgileCoach 又稱敏捷教練，負責導入Scrum流程並培養團隊成員具備agile思維。

ScrumMaster負責主持Scrum相關會議與process和協助管理分析Sprint產出物，此外也必須協助整個流程持續改善，最終讓團隊達到processself-managed狀態。

一般而言，ScrumMaster在團隊裡通常沒有實際管理權但必須協助其他成員在遇到block事情時去除障礙，有時也要扮演輔導長的角色激勵團隊士氣。

簡言之，ScrumMaster是一個必須對於產品開發流程以及溝通能力有一定掌握並具備一定的技術實力的角色。

說真的，真正要當的好ScrumMaster，不容易 DevelopmentTeam/DevTeam 具備跨職能的開發團隊成員（可以完成UserStory的所有開發工作，包含開發、測試等），一般遵守兩塊pizza原則，以不超過6-8人為原則。

團隊成員必須具備互助合作的騎士精神，以團隊目標為目標，在互相協助的基礎下一起在Sprint結束前完成於Sprint開始時所承諾應該交付的任務 Stakeholder 利害關係人，需求的起源地。

在直接面對消費者市場的產品團隊可能是一般消費者，若是開發內部工具或是面對企業市場的產品團隊，利害關係人可能會是AM（客戶經理）、BD（商務拓展）、TechSupport（技術支援）、Marketing（行銷）等單位的同仁 Event活動 Sprint Sprint在橄欖球中為衝刺的意思，指的是一個Scrum的週期。

通常以2-4週為一個單位，理論上除了緊急bug或是task外，不能於Sprint開始後額外新增Story進入Sprint當中 SprintPlanning，會議時間：1-2hours 於Sprint開始前舉辦的會議。

根據ProductOwner的優先順序和團隊可以消耗的點數（velocity）評估哪些Story需要進入到Sprint當中的會議。

由ScrumMaster主持，ProductOwner和DevTeam參與，由DevTeam認領想要負責的Story，DevTeam於會議結束後根據Story劃分成更細部的task，然後ScrumMaster確認沒問題後開始Sprint的週期 SprintGromming(BacklogRefinement/Stroytime)，會議時間：一次2-3hours或分成兩次，每次1-1.5hours 於Sprint中間舉辦的會議，主要目的在評估下一個Sprint中要從Backlog中拿出來做的Story點數的估計（Planningpoker）。

一般透過ProductOwner說明UserStory然後和DevTeam討論定義出以User角度表述的Acceptancecriteria。

記得這邊的StoryPoint是相對值並不是完全mapping到時間，而且每個team的狀況都會不一樣，主要是根據你們team對於這項Story的Complexity、Uncertainty和Effort去做評估，一般使用費式數列表示（1、2、3、5、8、13、21...）。

這個會議十分重要，透過Planningpoker的過程可以讓大家對於Story的認知和知識可以align到同一條線上（例如估計點數不一致時彼此說明和討論，增進對於Story和系統的了解）。

記得，若是UserStory過大，沒辦法在一個Sprint完成會建議把它切成比較小的Story。

若是連ProductOwner都沒辦法描述很清楚的UserStory會要求ProductOwner先去釐清需求在下一次SprintGromming會議或是SprintPlanning前再次repoint SprintReview(SprintDemo)，會議時間：兩次30mins（利害關係人/內部團隊） 在SprintReview中，ScrumMaster會邀請Stakeholder參與會議，由ScrumMaster簡介這次Sprint所完成的ShippableProductIncrement（可交付的產品增量）和DevTeam展示開發成果。

讓市場業務端和系統開發端可以彼此溝通並確認產品方向與市場吻合，若是有需要產品改善或是新的需求產生將由ProductOwner釐清後放入Backlog中 SprintRetrospective（SprintRetro），會議時間：一次1hour SprintRetro簡而言之式是Scrumteam於Sprint結束時的閉門會議。

通常在透過感謝的對象來緩和氣氛，並檢討這次Sprint的流程是否有需要檢討的部份或是做的不錯的部份，若是沒有完全完成所承諾要完成的事情，必須了解原因（例如低估複雜度或是中間有遇到block影響開發）。

通常會搭配SprintPlanningDoc和Burndownchart以及上次的SprintRetrospectiveDoc列出的todoitem來進行檢討 DailyScrum(DailyStandupMeeting) 每天約15分鐘的站立會議，每位Scrumteam更新自己昨天完成的事項、今天預計完成的事項以及是否有遇到什麼block阻礙。

若是有block將由ScrumMaster溝通協調並調度團隊資源協助移除成員障礙。

若是有無法在Sprint結束前完成的Story也要讓ProductOwner提早知道。

另外，Burndown也是需要在DailyScrum大家要一起觀看Sprint是否有正常運作的指標 UserStroyMapping/workshop，會議時間：一次1.5-2hours 一般不能算是標準的SprintEvent，通常是ProductOwner在對於開發新產品的掌握度比較低，需要開發成員一起協助定義UserStory所召開的會議 Artifact產出物 Backlog 裝有待完成的Story或是Bug的袋子，在SprintGromming時根據Priority進行點數估計，於SprintPlanning決定哪些已估計Story需要進入這次的Sprint當中 SprintPlanningDoc 記錄當次Sprint所承諾要完成的Story和需要修復的Bug（通常為插單緊急Bug或是不緊急但有在Gromming進行點數估計的Story），DevTeam成員需要定期更新所負責的Story的相關文件 SprintGrommingDoc 記錄當次Sprint所承諾要完成的Story/Acceptancecriteria和需要修復的Bug的點數估計。

SprintRetrospectiveDoc 記錄Sprint檢討會議中的待辦事項和檢討事項 Burndownchart/Burnupchart 以團隊為單位，記錄Sprint完成狀況的圖表，Burndownchart記錄點數完成下降的趨勢。

Burnupchart記錄累積完成的點數和scope的趨勢 ScrumBoard 記錄Sprint過程中每一個Story以及Story下task的狀況，是在Todo還是InProgress還是Done DefinitionofDone（DoD） 團隊定義的驗收成果標準，例如開發一個新功能必須含：Dev+QA+Doc+Deploy才算Done，是每一個Story都必須遵守的完成標準 Epic/Theme/UserStory/Acceptancecriteria UserStory是用使用者需求角度撰寫的有商業價值的一段敘述，而Acceptancecriteria則是更為細部的補充描述。

當有數個story隸屬於某一個相關feature時通常會把它歸為同一個Theme，若是一個大的產品或是系統需要橫跨數個sprint時會把這些Story都歸類為同一個Epic #UserStroy 我是一個網站使用者 我想要可以提交feedback 這樣網站開發者就可以根據使用者的回饋去優化網站 #Acceptancecriteria 當使用者點選右下角的圓點按鈕後，可以看到表單，表單上面有姓名、email和回饋訊息三個欄位 當使用者填完表單送出後若成功會閃出一個提交成功的訊息 當使用者表單項目有缺漏時會有提示訊息提示 那些擔任ScrumMaster學到的事 在了解Scrum相關的專有名詞後我們就可以開始我們Sprint啦！但事實上，Scrum只是一種框架和方法論，實際我們在執行Scrum時往往會因為團隊成員的不同或是組織文化的不同而產生不同的效果。

接著讓我們來看看實際上在執行Scrum會有哪些需要留意的觀念 基礎建設和團隊素質很重要 CI/CD基礎建設、DevOps文化、Agile精神、團隊是否具備開發上所需的所有技能等都是Scrum運作能否順暢很重要的一環，若是基礎建設不穩，很多時候我們的點數估計往往會低估，造成Sprint運作上的困難。

另外若是團隊成員都具備T型人才的能力也將讓Scrum運作更順暢 我們是一個職業球隊 Sprint是以團隊為基礎，Burndownchart不是一個人的Burndownchart，所以若是有團隊夥伴遇到困難是需要其他夥伴協助（例如：對於系統架構不熟悉），其他比較熟悉的夥伴應該主動給予協助。

若是有夥伴無法如期完成任務，其他若有夥伴已經完成手上的事情，也可以主動協助一起完成剩下的工作，確保Sprint結束後當初承諾的任務都是有可交付的產出 Scrum是一面照妖鏡 透過Scrum可以讓當初不清楚的使用者需求、無根據的預估工作時間和無限制需求的亂象可以被攤在陽光下檢視和討論，才有機會透過Scrumprocess來管理和改善 通常絆腳石是你不能說名字的那個人 在推行Scrum時，公司高層和文化的支持也是十分重要，因為通常公司推展Scrum或是敏捷開發會失敗，通常絆腳石是你不能說名字的那個人 保持你的步伐 排定好時間後就固定下來，讓團隊成員可以調整好自己的節奏並有更多事情可以專注在任務完成上而非冗長會議或是雜事上 要測量才能進步 每次Sprint結束一定要有檢討並透過數據圖表等檢視可以改善的部分，持續優化整個流程 軟體開發流程沒有銀彈 講了那麼多，事實上Scrum也並非萬能，碰上常常會有臨時性任務或是operationissue特性任務的團隊，或許可以考慮使用Kanban，更甚於Scrum。

另外，像是技術研究單位，使用Scrum也未必是一種好選擇 總結 以上透過一個ScrumMaster視角去探討ScrumMaster在ScrumTeam中所扮演的角色和可能遇到的挑戰和機遇。

ScrumMaster是一個必須對於產品開發流程以及溝通能力有一定掌握並具備一定的技術實力的角色。

說真的，真正要當的好ScrumMaster，不容易。

事實上，Scrum真正目標在於建立一個自我管理的組織，讓Process而非人來管理。

當Scrum真正成功的時候，就是ScrumMaster可以退休的時候了。

關於作者： @kdchang文藝型開發者，夢想是做出人們想用的產品和辦一所心目中理想的學校。

AStarter&Maker.JavaScript,Python&Arduino/Androidlover.:) 參考文件 燃尽图（BurnupandBurndownChart）—介绍 ClearAcceptanceCriteriaandWhyThey’reImportant 當一個ScrumMaster是一個怎樣的體驗？ （imageviaeohcoastal） #scrum #scrummaster #productowner #devtame #軟體工程師 #軟體工程 #softwareengineering #敏捷開發 #agile KDChang Follow Following Founder@TechBridge/CoderBridge AStarter,SoftwareEngineer&Maker.JavaScript&Pythonlover.:) 工程師/創業者/教育者/寫作者 Facebook RelatedPosts 猜數字 mijouhsieh HowtocreateatwodimensionalarrayinJavaScript? Rich 側邊選單 JingTeng Newsletter Subscribe Comments Submit SignIntojoininthediscussion. Edit Submit Edit Submit Reply Submit