關於 backlog商業 ，我們在網路上蒐集到這些相關的討論、資訊與評價

Bas點出了我們看到的大部分 scrum master 缺少的部分。

只能說自己的經歷真的算是誤打誤撞，幸運地走出了還蠻上軌道的路。

我過去是個 team leader, 也是tech lead, 但在 scrum 轉型時期，我是預設不領 task 的 lead.

我的主要工作，是跟團隊一起 pair, 從 pair 的過程中把產品品質做好，把團隊技能拉起來，把基礎建設跟團隊規範持續改善，pair 過的就節省 code review 的時間。

其他的工作則是和團隊一位專業的 QA 一起與 PO 進行一場小小的 pre-refinement, 從需求、開發、測試三個維度來看，需求是否已經到 ready 的程度，避免整個 team 的 refinement 時間過長、效益過低，提前抓出技術可行性、產品功能設計的盲點，以及商業價值評估。

我還有其他 5 個機動性的任務：
1. 需要我時，我會協助 PO 一起去跟 stakeholders 說明，或是爭取時間、資源，或是跨 team 的協調工作。

2. 我會觀察線上營運狀態，bug 的類型，緊急程度跟影響範圍。從 bug 的部分往往可以分析出來我們流程還有哪些地方可以改善的。

如果是緊急程度最高的 bug, 而其他人正在忙，我會跳下去處理，讓影響範圍降到最低。

3. 如果臨時有什麼插件需求，我就是 PO 一顆很好用的活棋，我可以從 pair 過程抽出身來，幫他處理這些插件，以解燃眉之急。

4. 系統架構面的設計，整個部門技術選擇的決策，跟各個專案 kickoff 的 reviewer，跨部門團隊合作（例如安全、資料部門、search），推進部門與產品的基礎建設、自動測試、流程開發規範、技術前沿研究、技術教育訓練，也是我在團隊內外的職責。

5. 協助 PO, 因為我們的 PO 當時還算是要兼任 help desk，我們出現過零星幾次，團隊功能做完了，但 PO 還在忙，瓶頸出現在 PO 身上，因為她被線上的營運問題搞得喘不過氣。

我們團隊當時把手上的工作都先暫停，然後跟 PO 盤點一下她現在手上除了放到我們 product backlog 的部分，還有多少事情要處理，有哪一些是會重複發生的。

後來我們針對會重複發生的，要定時觀測的，寫了幾隻報表，設定好 cron job 週期，固定週期就會撈資料寄給 PO, 然後一些快速修正資料的，寫好程式讓她下次處理有介面可以用，而且其他人也可以迅速透過介面幫她處理。

註：還有一點，一開始幾年蠻多人問的，但最近幾年比較少見。

我們的 bug (issue/ticket) 是會排入 product backlog 的。或許是我們的 bug 大部分都會經過 PO, QA 而來，對 PO 來說，她能判斷 bug 的緊急程度，與現在正在進行的 sprint backlog item 何者重要。（別忘了還有我這顆活棋可用）

如果真的就是要當插件進來，我們也會一起討論跟決定，最後還沒領的 item 是否該排出 sprint 挪到下個 sprint 做。

如果大家都認同 插件的必要程度，以及 sprint items 全都不能 miss 在這次是很有意義的，我們就會討論作法的調整（技術債換時間的可能性），或是加班，多點時間消化掉插件的可行性。

喔，對了，我們的 PO 跟 RD 職級是平行的，我們就是一個團隊，大家負責自己的角色職責，榮辱共享。所以沒什麼「壓迫強逼」的問題，一切事情都可以團隊一起商量出來。（當然，我們團隊每個人對產品的 ownership 都很強，就是有問題都會主動跳出來關心發生什麼事，可以怎麼解決那種）

而且我們沒有專屬的 support 團隊或是角色，我們會排 oncall 的，只有農曆過年這種大家可能大部分都出國，手機/網路可能連不上的那種，才需要確保每天都有人可以處理。（這段就是考驗大家的 ownership 了）

那段 scrum 轉型的過程，我們其實並沒有ㄧ個特定的 scrum master 角色，但其實我幹的事情就跟 scrum master 很像（只是少了引導者的部分）。

所以我說挺幸運的，誤打誤撞走出 technical coach 這條職涯路線。再接觸了更多引導相關、Lean、LeSS 之後，就更能擔任 agile coach 的角色。

而 Odd-e 裡面的大部分同事，再加入 Odd-e 之前的經歷，其實也都蠻像的，只是各角色的比重不同而已。

Bas 原文連結：https://less.works/blog/2019/12/05/scrum-master-as-technical-coach.html

上完課有個恐怖的傳說....

如果非得替這個傳說加上一個 timebox, 我會說是....六個月。

---
守破離、以終為始、定義好自己的TA、切細切細切細，可以降低風險、加速調整、增加生存機會。

週一到週三參加了三天的CSPO(Certificated Scrum Product Owner)課程，到現在總算可以沈澱一下來記錄一下感想。

雖然說三天的課程很像很長，必且灌入了很多的知識，但是脈絡清晰。課程概觀是這樣，產品發展分為探索(discovery)跟交付(delivery)，而這門課主要重點都在教怎麼探索。

探索的過程就是從
1. 做夢。找出你想做的..
2. 商業目標的迭代，可能從早期的試錯學習，到中期的從中獲取利益，到晚期的守成或是停止等等。
3. 每個迭代找到每個目標的關鍵角色
4. 這些關鍵角色可以為他解決什麼問題? 而對這個問題有哪些假設，並且試著證偽。如果假設沒有辦法推翻，證明是個問題，那就試著去解決它，這就接到後面的交付的部份，後面會補充。

而有了商品要怎麼行銷它?
1. 先期使用者跟他貼身肉搏
2. 中期使用者的營銷策略
3. 晚期使用者透過社會壓力而不得不用你的產品 (我都被迫安裝Line跟微信der)

至於交付的部份，就是我們常認知的Scrum PO要做的那些部分。例如如何做User Story Mapping，如何切近光燈遠光燈，好的Backlog應該有哪些味道等等的。不過也有些從Daniel的觀點看到對Scrum PO有一些不一樣的闡述。例如PO不用寫Acceptance Criteria而由dev team寫，過期的Backlog item其實可以扔了。這些請大家爭酌使用 XDDD

所以上述的課程三大塊要怎麼看
"探索"所描述的做產品部份是1，行銷是0。做對產品有了1後，才可以用其他的行銷補上0。這樣才會是1000000...，不然就只是000000，那還是0啊。那什麼樣的產品才是好產品，那就是要Remarkable，或說是個"紫牛"。因為工業時代的產品是大眾商品，追求的是大量標準化便宜品質好的產品。所以做這條路的產品永遠只會有人比你更好。而現在是連結經濟(connected economy)，我們可以輕易地透過互聯網找到你的終端客戶並且跟他貼身肉搏，所以你應該做出一個像是"紫牛"這種讓人關注的產品，在一個niche的地方找到空間。你做不了京東，但是你可以專門賣鋼賣銀的京東。找出一個狹窄的空間把它做到最好，這是目前比較可行的機會。而如果說產品跟行銷是戰略的話，那交付就更像是戰術。找到方向後，但要做到產出最小化(小到只剩內褲)，結果最大化($$或是學習)，以及影響最大化。有點像是我們所說的MVP。

這些大概就是課程的內容，來講講自己的體悟。

我喜歡做事的人，而且是從行動的經驗來表達理念是我最佩服的，而這堂課的講師Daniel就是這樣的講師。這次三天的CSPO課程最吸引我的不是那些方法論，而是方法背後的理論實踐。例如講到Odd-e在每年辦的AHA大匯用的那些出不著痕跡但出神入化的行銷技法，講到Odd-e的團隊如何共同運作來開發新事業，講到如何用訓練課程來建立connection，以及如何在平日生活中做到探索與試錯。如果說理論信條的闡述顯得虛無縹緲，而實際的實踐則可以深深讓下信服。從他的理念 Show don't tell，用行動來傳遞理念比那些說了一堆方法或爭論那些教條更有感染力。

而我第一天有個疑惑。第一天Daniel說了一堆反agile，反scrum的說詞，他是不是覺得敏捷不對了? 帶著滿滿的疑問第二天跟Daniel討論後，他說了Scrum不是最後，但是是不錯的開始。我還有一點搞不太懂，好像懂了，但是還是有點錯亂。但是最後比較想通了，那就是"守破離"。Scrum是一個Best practice，對於初次接觸照著做不會錯太多。但是best practice是一個很可怕的字，因為總是有不適合所有團隊的process，如果只固守那些教條，那跟嘲笑waterfall的人有什麼不一樣? 你又怎麼知道你的團隊適合scrum? agile的核心精神就是不停的迭代，fail fast，並且自省。所以不停的迭代一定可以找到團隊最適合的運作流程。但是你還是需要一個起點"守"，在不斷迭代的"破"，等到有了更高的啟發後，此時就是無招勝有招，那就是"離"了。而Daniel就是那個"離人"，而我還是那個"小白"。

另外第一天的有一個觀點讓我印象深刻，公司最外層是process/tool，中間一點是組織/架構，核心的是文化。說文化太虛幻，而組織如果是傳統組織的話，要走敏捷轉型通常都很難轉得動。我們的組織都是在一個工廠模式的組織，也就是階層式的管理架構，基本上"管理者"就是一個工廠思維的產物。當然一定有好的管理者，但是這種從上到下的組織，就是扼殺創意的結果，個人都可能因為social loafing而讓產值大幅下降。而敏捷組織更是扁平，甚至可能沒有管理者，每個都像是阿米巴原蟲一樣可以自理，迭代，端對端。Odd-e他們公司就是這樣搞的，沒有support部門，每個人都是可以搞定所有一切。所以我一開始接觸到Scrum第一個問題就是那Manager在哪? 這就是一個從傳統組織思維過來的問題。有這個體悟我就下了一個結論，敏捷組織無法徹底地從傳統轉型的，有太多既得利益者或是僵化性。但是另一個體悟是，個人，團隊，公司本來就是各自迭代。如果你想要改變，要發於自我，不要埋怨資源少，不要覺得自己沒有權力做。show don't tell，做出成績了人家管你敏不敏捷，成績就是王道。當然同樣的，公司的目的就是$$$，所以真的公司好好的，不要想不開去搞敏捷轉型，敏捷只是一個方法，不要把它當作是目的。

在課程最後每個人發表自己的感想。我的感想是"原本是打算來開腦的，但是感覺是被砍腦的。想太多說太多無意，重點是要用身體學習，不斷的迭代試錯，然後多丟丟骰子，多發現新事物，也許有不錯的豔遇" 也分享給各位。

也感謝 Richard Hsiao的推坑及 TenMax AD Tech Lab 的補助，當然還有感謝 Daniel Teng 真的超多啟發的，真心感謝。

Pop

#成年人
#抱大腿
#不要臉
#SmallIsTheNewBig
#ShowDontTell