Bas Vodde 在 LeSS conference 上講了一場以 product backlog 為主題的演講。他過去幾年的演講偏概念層次:LeSS 的歷史、組織政治、把技術實踐改名為社會性團隊實踐。這次他刻意降到 experiment 層級,回到前兩本 LeSS 書的 try / avoid 格式,把 Wärtsilä(他長期參與 LeSS 導入的芬蘭引擎公司)實際在用的 backlog、roadmap 和指標攤開來給大家看。
這篇整理演講的重點,並補上幾個我認為對台灣團隊特別有感的地方。
LeSS 從一個決定開始
2005 年,Bas 和 Craig Larman 在思考多團隊怎麼跑敏捷時,做的第一個決定是:一個產品只有一份 product backlog。多個團隊、一個產品,所以只需要一份 backlog。
Bas 說,LeSS 後來的大部分規則,其實都在處理這個決定帶來的後續效應。一旦只有一份顧客中心的 backlog,團隊就必須顧客中心,也沒辦法預先把項目綁給特定團隊。
這個決定最直接的效果是透明。他舉早期的例子:某個組織原本用 project、program、portfolio 的結構管理工作,一團混亂。把所有東西塞進一份 backlog 之後,馬上發現有 50 個人花了三年在做優先序極低的項目。這件事在原本的結構裡完全看不見。
所以有兩條連實驗都算不上的鐵律:一個產品一份 backlog,永遠;不要預先指派項目給團隊,永遠。
Backlog 的三個身分,和一個它沒有的身分
Product backlog 看起來簡單,實際上把多重目的混在同一個 artifact 裡。一般來說這是壞設計,但 backlog 是少數的例外。
第一個身分:產品管理工具。它描述產品的未來和價值排序。檢驗標準很具體——把 backlog 拿給終端顧客看,每一條他都要看得懂。所以 backlog 上沒有 task,也沒有元件名稱。
第二個身分:透明度工具。開發組織的所有工作都要出現在 backlog 上。有些工作很難寫成顧客中心的句子,例如加速 build pipeline,硬套「身為顧客,我想要更快的 build pipeline」只是自欺。這類項目照樣放進 backlog,寫法不用勉強,重點是工作要看得見。
第三個身分:進度量測的來源。從 backlog 可以產出一些對組織有洞察的指標(velocity 除外,那個沒什麼用),文章後面會看到 Wärtsilä 實際在看的幾個。
它沒有的身分:專案管理工具。Product Owner 是產品管理角色,sprint 裡團隊進度做到哪,尤其在 LeSS 裡,PO 應該不太需要關心。很多組織把 PO 扭曲成專案經理,Bas 對此的評語是 very sad。
避免獨立的技術 backlog
這是他花最多時間講的一個 avoid,因為場景太常見:PO 是業務背景的人,團隊在組織上隸屬技術主管。技術主管想做技術改善,又不相信業務背景的 PO 會排技術項目,於是另開一份 architecture backlog 或 technical backlog,由架構師或部門主管排序。
接下來的發展幾乎每次都一樣。兩邊每個 sprint 為了功能和技術項目的比例吵架,關係越吵越僵,最後為了止血,協議出一個固定配額:每個 sprint 30% 做技術項目,70% 做功能。
Bas 說這個協議是雙輸。Backlog 存在的意義就是讓你能隨情境調整優先序——有緊急商業需求時全做功能,平穩期多還一點技術債。固定配額等於把這個彈性直接丟掉。
解法是合併,然後告訴 PO:你負責的是產品的整個生命週期,包含技術改善的排序,而非只負責這次 release。
他在一家銀行看過合併後的結果。原本開發主管和 PO 天天為優先序吵架,backlog 合併後,下一次討論優先序時,兩個人的立場對調了——PO 覺得自己要對產品的長期健康負責,排了一堆技術改善;開發主管反而主張多做顧客功能,要求把技術項目往後移。Bas 在旁邊看得很樂。發生的事情是,兩個人都從整個產品的視角思考,原本各自守地盤的動態消失了。
避免 backlog 前面的流程
另一個常見模式:需求進 backlog 之前,要先寫 business case、評估要不要投資、過某種 stage gate。
不要這樣做。任何請求進來,不管多模糊多大,直接放進 backlog,依你對機會大小的判斷先給個排序,後面靠 refinement 處理。
Bas 澄清他反對的是前置流程,而非 business case 本身。某些項目確實值得寫 business case,但那應該盡量和團隊一起、在 refinement 這類活動裡做。前置流程降低了緊急項目的處理彈性,也降低了這些請求的能見度。
團隊做大部分的 backlog 變更
一個健康訊號:backlog 上大部分的項目由團隊建立和更新。反過來,如果 backlog 幾乎都是 PO 在動,值得警覺。
想想項目的來源就知道為什麼。PO 加一個大項目進 backlog,進 refinement,團隊討論、拆解,拆出來的小項目由團隊更新回 backlog——這時大部分項目已經出自團隊之手。使用者直接向團隊提需求時,Bas 鼓勵的行為是團隊直接加進 backlog,然後告知 PO「使用者要求這個功能,我們加進去了」,省去先向 PO 報告、等 PO 處理的來回。Production issue 和缺陷也直通團隊,由團隊判斷急迫性:夠急就馬上修,還好就加進 backlog。
相對的警訊是 PO 預選。有些 PO 在 refinement 或 planning 前先挑好項目,到了現場只秀預選清單,說今天的議程是 refine 這幾項。這樣做的代價是團隊對 backlog 的 ownership 大幅下降。Bas 遇過導入 LeSS 一年的團隊,問他們知道 backlog 長什麼樣子嗎,答案是不知道,秀給他們看,反應是「喔,原來長這樣」。
PO 該做的準備只有排序。帶著整份排好序的 backlog 出現,跟團隊一起談要 refine 哪些、要拿哪些進 sprint。Bas 建議 refinement 照優先序走,這會自然稀釋導入初期常見的單一專精問題。
還有一個實務觀察。團隊想讓 PO 排高某個項目時,如果 50 個人各自去找 PO,PO 只會全部降級,然後團隊集體洩氣。正確做法是團隊之間先談,20 個人一起去找 PO 提同一個項目——Bas 說他沒看過 PO 拒絕這種請求,因為團隊已經幫 PO 省掉了大量的判斷工作。
User story 格式:try avoid
「身為某某,我想要某某,以便某某」這個格式,Bas 直說他不喜歡。問題出在強迫套模板:「身為買家,我想買一本書,以便我擁有一本書」,直接寫「買書」資訊量一樣。他看過最慘的 backlog,每一行開頭都是 AAU——因為每一項都以 as a user 開頭,乾脆縮寫成 AAU。到這個地步,模板的價值是零。
但這是 try avoid,兩種結果他都看過。模板的價值在於逼你思考誰會用這個功能、為什麼要做。在模板列為建議選項而非強制規定的組織裡,團隊只在有幫助時使用,效果反而不錯。同一個做法,在某個情境慘不忍睹,在另一個情境有價值,差別往往就在強制與否。
Ancestor 改名為 Roadmap Item
這段對讀過 LeSS 書的人最有價值,因為是書上術語的演化。
書裡談 backlog 的拆解管理有兩種方式。Cell-like splitting 最簡單:大項目要拆的時候,移除大項目,放進小項目,backlog 維持一維,完全不追溯來源。四、五個團隊的導入,這樣就夠了,追溯只會帶來沒用的複雜度。
Ancestor splitting 多記一層資訊:每個項目可以記得一個來源。規則是 ancestor 本身沒有 ancestor,所以結構永遠只有兩層。這個限制刻意擋掉傳統需求管理那種拆了又拆、層層堆疊的需求階層——那種階層對開發沒有價值。
Bas 承認 ancestor 這個詞太學術,他從來沒聽過任何人在 LeSS 書以外的場合用它。所以他改口叫 roadmap item:roadmap 上的項目,通常對應較大的預算或較高層的計畫,backlog 上的每個項目可以標記它來自哪個 roadmap item。換個詞,概念直接接上組織既有的語言。
規則不變:roadmap item 太大要拆的時候,用 cell-like 的方式,移除舊的、加兩個新的,階層永遠長不出來。
順帶一提,Wärtsilä 用 Jira 管 product backlog,他們發現 epic 這個型別名稱寫死在程式碼裡改不掉,所以 roadmap item 在工具裡只好繼續叫 epic。
有意義的分類:一次立場修正
早期 LeSS 的建議是 backlog 越簡單越好,不要用 story、task、bug 這些分類——Bas 說他從來沒搞懂 Jira 預設那套分類能拿來幹嘛,全部用 item 就好。
近年的探索修正了這個立場:如果你想從 backlog 產出有意義的回顧性指標,有意義的分類就有價值。Wärtsilä 用的分類長這樣,命名刻意借自引擎業的維護語言:
- Reactive maintenance:現在不做,產品的行為就和預期不符。多半是 bug。
- Preventive maintenance:現在不做,產品未來某個時間點會停止運作。相依套件升級、安全修補、憑證更新都在這裡。Bas 認為這是產品開發裡最被低估的類別——現在沒人從零打造所有東西,大量使用開源元件的代價就是大量的 preventive maintenance。憑證常常拖到過期前一週才有人急著處理,就是這類工作長期被忽視的症狀。
- Proactive maintenance:做了之後,其他維護類別應該下降。也就是改善工作。
- Operational:不做的話,你不知道產品是否正常運作。讀取和回應顧客的訊息回饋,以及還沒自動化的發布例行工作。
- Investigation & research:調查與研究。
- Product enhancement:真正為顧客打造新功能。
為什麼用引擎業的詞?因為 Wärtsilä 是引擎公司,軟體部門相對小、相對新。與其教全公司軟體術語,把自己的語言調整成組織聽得懂的話,連結建立得更自然。這個選擇本身就值得學。
Misuse priority for refinement
這個做法是 Wärtsilä 的 area product owner 發明的,Bas 說聽起來很糟,實際上很聰明。
照理說 backlog 的排序依據是價值。但 Wärtsilä 的 PO 還會把「希望進 refinement 的項目」排到最上面——即使還不知道它的價值,甚至可能價值不高。PO 想讓某個項目被拆解、被討論、長出更多資訊,就直接用排序表達。
Backlog 本來就是多重目的混在一起的 artifact,再混一個進去,實務上運作得很好。
PO 實際上怎麼排序:比較桶子,而非比較項目
Bas 觀察大部分 PO 的實際行為,歸納出一個他稱為 prioritizing buckets 的模式。
理論上 PO 應該拿所有項目互相比較價值。實際上,這個功能 vs 團隊提的那個改善 vs 這個 bug,根本比不出來,硬比會把 PO 的腦袋燒掉。所以 PO 真正做的事情是:sprint 前幾天整理 backlog 頂部時,先決定各個桶子的量,再在桶子內比較。
這個 sprint 修幾個 bug?Backlog 上 bug 多就多修幾個,少就四個左右,然後 bug 跟 bug 比,挑最重要的放上去。
顧客回饋要回應多少?這裡有個乍看矛盾的判斷:有些回饋本身沒什麼價值,例如「能不能把這個按鈕移過去,每週幫我省一微秒」,但你照做,使用者發現你真的在聽,下一次他給你的回饋可能幫公司省一百萬。回應回饋的價值在建立參與感,而非那個功能本身。所以 PO 會看是誰提的:成天亂槍打鳥的人,降級;第一次認真給回饋的人,升級。
團隊的請求也一樣。一直降級團隊提的項目,團隊的主動性就會被磨掉。判斷方式與其說是估價值,更接近看這個項目有多少團隊成員想做。
最後才是 roadmap item 拆出來的項目,也就是長期計畫裡的 product enhancement。
牆才是 Sprint Backlog
Bas 罵了 Jira 十年,自稱說過它是這個行業的疾病。這場演講他難得稱讚了 Jira,但先講清楚界線。
Product backlog 用 Jira,可以。Sprint backlog 用 Jira,絕對不要。他說這件事他可以講一個小時,因為看過的傷害太多了。
理由一句話講完:Jira 是追蹤工具,sprint backlog 是協作 artifact。協作 artifact 需要協作工具,追蹤工具放在這個位置甚至是反協作的——團隊開始在 Jira 的 comment 裡對話,而人就坐在彼此旁邊。工具的類別就錯了,所以 Azure DevOps 同樣不行,同一類東西。(Bas 說他沒用過 Azure DevOps,但聽過用的人說開發者想搬回 Jira,他的反應是:什麼?)
他用一個畫面解釋這個社群哪裡走錯了。實體時代的 sprint backlog 是一面牆,上面貼滿便利貼。數位化的時候,我們誤以為便利貼是 sprint backlog,做了一堆管理便利貼的追蹤工具。其實牆才是 sprint backlog——牆上除了便利貼,還有這個 sprint 誰休假、working agreement、Definition of Done、團隊自選的 WIP limit、retrospective 的產出、sprint planning 時白板討論的照片,以及一隻表示項目完成的派對貓。
Wärtsilä 的團隊用 Miro 當這面牆。Miro 的 Jira plugin 讓團隊整個 sprint 不需要碰 Jira,直接在 Miro 板上編輯 Jira 項目;拆出來的 task 不進 Jira,因為放進去沒有任何好處。每個團隊的板長得都不一樣,這正是協作 artifact 該有的樣子。
至於 Jira 值得稱讚的地方:filter。Wärtsilä 有兩個 requirement area,在 Jira 裡切 area backlog 只是切換 filter,兩個 area backlog 是同一份 product backlog 的兩個視圖,而非兩份獨立的 artifact。Filter 開著的時候重新排序依然正常運作,這件事 Excel 做不到,Jira 做得很好。Bas 說出這段話的表情看起來很痛苦。
其他建議:把 Jira 預設的型別全部移除,只留 epic(反正也改不了名),並且盡可能簡化 Jira 的一切。
五年 Roadmap 存在的理由是預算
Wärtsilä 有一份五年 roadmap。Bas 先打預防針:大部分軟體產品用不著五年 roadmap,五年對軟體開發長到荒謬。但 Wärtsilä 的引擎壽命 20 到 40 年,引擎的開發週期也很長,artifact 的需求由組織脈絡決定。
這份 roadmap 有幾個重要性質。它沒有承諾或 deadline 的成分——上面寫某個項目 Q2 完成,意思只是從現在到 Q2 我們大概會做這件事,可能提早、可能延後、可能整個被換掉。更進一步,五年 roadmap 上的某些項目,他們現在根本不預期會做。
那做這份 roadmap 幹嘛?預算。你去跟管理層說「我們要做一個很棒的產品,投資報酬率會很高,但我們還不知道要做什麼,總之先給我 40 個人的預算」——Bas 說他沒看過哪個組織吃這一套。要拿到預算,就要具體展示可能做的事。Wärtsilä 的 PO 還會做不同投資情境:這個投資額大概對應這些功能,那個投資額對應那些。
Roadmap 和彈性怎麼共存?規則很簡單:新請求進來,只有在價值高於 roadmap 上既有項目時,才會替換上去。所以這份 roadmap 代表的是這筆投資預期產出的價值下限,內容可以全換,但每次替換都讓價值變高。
往下一層是一年期的 area roadmap,由 area product owner 維護。每次 refinement,團隊進會議室,area roadmap 就投影在螢幕上;roadmap 有變動時,APO 當場解釋發生了什麼事、為什麼改。目的之一是讓所有團隊持續掌握組織、顧客和長期計畫的動態。PO 們還在 roadmap 頂端明確標注不確定性的範圍,就是為了防止它被解讀成 deadline。
從 Backlog 長出來的指標
有了 roadmap item 的標記和維護分類,幾個指標就能直接從 backlog 產出。
Emergent vs roadmap。 不在 roadmap 上的工作——臨時的缺陷、顧客的小回饋——稱為 emergent item。Wärtsilä 的比例大約 60% roadmap、40% emergent。這個指標對管理層溝通特別重要:預算是照 roadmap 核的,這張圖等於告訴管理層,40% 的工作花在你們核預算時沒同意的事情上。這很不舒服,但你需要讓它可見,並解釋原因——使用者的請求和 bug 沒辦法事先計畫,能計畫的話一開始就沒有 bug 了。
類別分布。 Product enhancement 佔 35%,reactive maintenance(修 bug)19%,preventive maintenance 16%。Bas 認為這個分布在產品開發裡算典型,甚至算好,但對多數組織來說依然難以下嚥:只有三分之一的時間在做顧客看得到的新價值,16% 花在升級和安全修補這種不做系統就會死、做了也沒新價值的事情上。
接下來的訊息是整場演講我認為最該轉述給管理層的一段。所有人都希望 35% 變大,這點沒有分歧。但把它變大的路徑,和衝 velocity 無關——路徑是壓低其他維護類別,而壓低它們需要先增加 proactive maintenance 的投入。短期內,新功能的比例會因此更低。Wärtsilä 也在做這類投資,例如從多個 repository 改成 monorepo,期望(Bas 特別更正自己:是期望,說預期太樂觀)降低 preventive maintenance 的成本。這個先蹲後跳的邏輯,組織不談清楚,改善永遠排不進去。演講裡的數字也誠實反映了現狀:他們花在改善上的時間,比花在「因為沒改善所以不得不做」的維護上還少。
Spillover。 定義要抓準。Spillover 指的是團隊開始做某個項目後,既沒在 sprint 內完成,也沒負起責任在 sprint 內把它拆開讓狀態可見。至於團隊把 sprint 選的項目整包丟掉,完全沒有問題,拿「是否完成 sprint 承諾」當指標反而有害。Wärtsilä 目前的平均是每團隊每 sprint 約 0.8 個,Bas 說以他看過的組織,這個數字很低,值得稱讚。這個指標不適合往上報——管理層看不出它的用途——它的價值在給團隊自己的改善討論提供素材,因為 spillover 直接衝擊團隊動態和 PO 的規劃彈性。
來源: The Product Backlog – Bas Vodde https://www.youtube.com/watch?v=G2gq0stySvs
發表迴響