前言
在 Facebook Scrum Community 社團中,Odd-e Taiwan 同事 David (是的,柯仁傑, 敏捷三叔公,現在是我 Odd-e Taiwan 的同事唷)拋出了一個議題:「大家覺得 Scrum Master 要懂技術嗎?」當然,這邊「懂」的定義,每個人心裡都不同,所以要先說清楚「懂」是什麼。
而 Odd-e 香港同事 Steven 在回覆討論串貼上了 Odd-e founder Bas 在 LeSS 上的一篇文:The Scrum Master as a Technical Coach,這篇文點出了我們在台灣看到大部分 scrum master 對團隊的幫助所欠缺的短板能力。
這也讓我不禁回想起,我身為一個技術職能的工程師,在一開始是如何以 Scrum 來進行軟體產品開發的。
Agile 與 Scrum 對我來說是不一樣範圍的東西,身為開發人員,我在職涯剛開始時就奠定極限編程(Extreme Programming, XP) 的基礎,但 scrum 的團隊協作方式,是在職涯約 6-7 年之後才開始的
我在 Scrum Team 裡面的工作
回想起來,只能說自己的經歷真的算是誤打誤撞,幸運地走出了還蠻上軌道的路。
我過去是個 team leader, 也是團隊中的 tech lead, 但在 Scrum 轉型時期,我是一個預設不領 task 的 lead。(對,我們一開始連 Scrum Master 這樣的角色都沒有,但其實我現在回想,我其實大部份的工作內容都是 Scrum Master 的守備範圍。但一開始缺少引導/教練 的相關技能)
我的主要工作,是跟團隊一起 pair, 從 pair 的過程中把產品品質做好,把團隊技能拉起來,把基礎建設跟團隊規範持續改善,pair 過的就節省 code review 的時間。
當然,單元測試、code review、持續整合 with build server、自動部署、重構,產品共享,甚至是 TDD,這些在我們進行 scrum 之前,該有的基礎、規範、技能,都已經有一定程度了。(因為我在 scrum 之前負責的工作,仍然包含把 XP 相關的實踐引入產品開發流程中)
除了 pair 以外,scrum 初期我還會跟團隊中一位專業的 QA 一起與 PO 進行一場小小的 pre-refinement, 從需求、開發、測試三個維度來看,需求是否已經到 ready 的程度,避免整個 team 在 refinement 會議時間過長、效益過低,並且提前抓出技術可行性、產品功能設計的盲點,以及商業價值評估。
除此之外,我稍微盤點了一下,我還有其他 5 個機動性的任務:
- 幫助 PO 跟 stakeholder 的交流:當需要我時,我會站在技術端的角色,協助 PO 一起去跟 stakeholders 說明,或是爭取時間、資源,或是跨 team 的協調工作。我也能第一手獲得從 stakeholder 那邊來的資訊、重點、限制和期待。
- 監控線上營運與 bug 分析:我會幫忙觀察線上營運狀態,bug 的類型,緊急程度跟影響範圍。從 bug 的部分往往可以分析出來我們流程還有哪些地方可以改善的。如果是緊急程度最高的 bug, 而其他人正在忙,我會跳下去處理,讓影響範圍降到最低。
- 用來應付重要且緊急插件的機動戰力:如果 PO 或部門臨時有什麼插件需求,我就是一顆很好用的活棋,我可以從 pair 過程抽出身來,幫他處理這些插件,以解燃眉之急。
- 架構、決策、跨部門協作、基礎建設、技術研究:系統架構面的設計,整個部門技術選擇的決策,跟各個專案 kickoff 的 reviewer,跨部門團隊合作(例如安全、資料部門、search),推進部門與產品的基礎建設、自動測試、流程開發規範、技術前沿研究、技術教育訓練,也是我在團隊內外的職責。
- 讓工作流更順暢,尤其是 PO 身上的工作負擔:因為我們的 PO 當時還算是要兼任 help desk,我們出現過零星幾次,團隊功能做完了,但 PO 還在忙,瓶頸出現在 PO 身上,因為她被線上的營運問題搞得喘不過氣。
當時我們團隊當時把手上的工作都先暫停,然後跟 PO 盤點一下她現在手上除了放到我們 product backlog 的部分,還有多少事情得要處理,分析有哪一些是會重複發生的。
後來我們針對會重複發生的,要定時觀測的,寫了幾隻報表,設定好 cron job 週期,固定週期就會撈資料寄給 PO, 然後一些快速修正資料的,寫好程式讓她下次處理有介面可以用,而且其他人也可以迅速透過介面幫她處理。
關於 bug/issue 我們的作法
關於 bug 或線上異常的處理,在台灣 Scrum 剛開始盛行前幾年蠻多人問的,但最近幾年比較少見。這邊也分享一下我們當時的作法。
我們的 bug (issue/ticket) 是會排入 product backlog 的。或許是我們的 bug 大部分都會經過 PO, QA 而來,對 PO 來說,她能判斷 bug 的緊急程度,與現在正在進行的 sprint backlog item 何者重要。(別忘了還有我這顆活棋可用)
如果真的就是要當插件進來,我們也會一起討論跟決定,最後還沒領的 item 是否該排出 sprint 挪到下個 sprint 做。
如果大家都認同該插件的必要程度,以及 sprint items 全都不能 miss 在這次是很有意義的,我們就會討論作法的調整(技術債換時間的可能性),或是透過加班,考量多點時間消化掉插件的可行性。
喔,對了,我們的 PO 跟 RD 職級是平行的,我們就是一個團隊,大家負責自己的角色職責、互相 cover、互相學習,榮辱共享。所以沒什麼「壓迫強逼」的問題,一切事情都可以團隊一起商量出來。(當然,我們團隊每個人對產品的 ownership 都很強,就是有問題都會主動跳出來關心發生什麼事,可以怎麼解決那種)
而且我們沒有專屬的 support 團隊或是角色,我們會排 on-call 的情況,只有農曆過年這種大家可能大部分都出國,手機/網路可能連不上的那種,才需要確保每天都有人可以處理。(這段就是考驗大家的 ownership 了)
關於線上異常處理
順帶一提,對於線上營運跟 bug 的處理,我們能有如此餘裕,也是因為我們對於 production 發生的 exception 基礎建設投入了不少心力。
我們可以每段時間檢查線上出了哪些新型態的 exception,統計該時段該 exception 的發生次數以及拋出 exception 的來源。並且跟上個時段,或是上週同一時段(電商通常會以上週同一時間來當作對比,因為對比樣本會更具備代表性)的差異。
超過了限定的 criteria,系統就會發通知給大家。所以一般在剛上線之後,每個人都會盯著系統定時送出的線上異常報表,以及系統警告通知。
對我來說,身為產品的開發團隊或 owner(不是指 PO,而是絕對的 ownership),我們對線上的營運狀況、異常處理的目標是:當線上出現問題,客戶、使用者或相關 stakeholder 用任何形式通知我們的時候,我們可以答出這樣的回覆:
感謝你的問題回報,我們在「xx:xx」時已經第一時間發現了問題,影響範圍大約是「xxxx」,我們預計在「oo:oo」將問題排除,初步判定可能原因為「xxxxxxx」。
當團隊外的使用者碰到了問題,在他們還沒回報產品團隊前,我們就先掌握了線上的相關資訊,並安排人員進行問題分析、影響範圍分析、準備對應的解決方案,這會讓團隊對外的 credit 非常好。客戶一般能理解系統難免會有 bug,他們會發怒的原因通常是因為團隊後知後覺,甚至是不知不覺。
當每次我們都能第一時間掌握線上異常的先機,這對做 7×24 小時服務的產品,非常非常重要,也是許多公司忽略的基礎建設的一環。
結語
回想起來我真的挺幸運的,誤打誤撞走出 technical coach 這條職涯路線。後來再接觸了更多引導相關、Lean、LeSS 之後,就更能擔任 agile coach 的角色。而 Odd-e 裡面的大部分同事,再加入 Odd-e 之前的經歷,其實也都蠻像的,只是各角色的比重不同而已。
最後補上我對於原討論串內容的觀點:
Scrum Master 就是幫助整個團隊(scrum master 對我來說,也可以換頂帽子變成團隊的一員)持續改善、成長。
如果團隊的瓶頸點在技術面,那 scrum master 如果要能讓團隊突破瓶頸,他就得懂「團隊現在技術面少了什麼東西」,如果團隊不懂那個東西是什麼,scrum master 就要想辦法讓團隊懂那個東西是什麼。(辦法可以有很多種)
大部分的改善都止步於團隊「不知道自己不知道什麼」,而 scrum master 對產品開發過程中團隊所需要的東西,至少都要到「知道」的程度,再稱職一點,應該要到能「輔導」、「協助」、「共同進行」的程度。再專業一點,就是要能夠「指導」、「示範」、「以身作則」。
所以後來 林明洋 在回覆討論串中,補上了另一位 極限編程 大師 Ron Jefferies(軟件開發本質論 的作者,如果你沒看過,一定要買來看一下,比起一堆 agile/scrum 的書,都來得更實務、核心、精準描述本質一點)的一則 twitter:
Let’s have a new rule: you don’t get to say what agile software development is, or say how to do it, if you cannot personally develop software as part of a team, in the agile style.
Ron Jefferies
是的,因為我做得到,所以我也是很認同這條新 rule 的:
如果你自己沒法在團隊中以那種敏捷方式來開發軟體,那就不要出張嘴告訴大家,敏捷開發是什麼,或是敏捷開發該怎麼做。
我們很常提到的兩句話:
- Show, don’t tell.
- Talk is cheap, show me the code.
以身作則的示範,甚至 pair,才是讓團隊了解的最佳方式。