Certified Scrum Product Owner 心得與摘要

Odd-e Certified Scrum Product Owner 心得

且戰且走的適應性(Adapt)是為了抵達目的地而存在。許多人認為敏捷開發不需要過度計畫，但這不代表不做計畫或不需計畫，相反的，對於每階段想檢驗(Inspect)的產品狀態，都應有一個可被測量的具體目標。

產品發想期

組織需求挖掘團隊，在產品早期，由產品負責人(Product owner)組織一個挖掘需求團隊(Discovery team)，邀請利益關係人(Stack-holder)，業務，積極使用者，商業分析師，工程師，設計師，開發團隊等人員一同發想/交流產品需求。

收集發散想法的工具，影響地圖(Impact mapping)或使用者故事對照(User story mapping)等工具，收集所有人想法，這時還不需收斂，主要專注在大量產出想法。如果是非常確定的需求，像是客製化訂單，也可以直接就商業價值排序。

Imapct mapping tool

持續更新的產品開發期：比較傳統與新的產品待辦清單工具

傳統產品待辦清單(Product backlog)的缺點是容易只關注優先權高的需求，需求的全貌與前後關係就呈現上不容易觀察與觀看。使用者故事對照(User story mapping)作為一個展現產品藍圖列表(Product Backlog)的新工具，帶來幾個好處：

• 視覺化檢視產品全貌，不單看排序最高的需求。功能在整體產品中，是為了解決哪類用戶的什麼問題而存在，因應商業目標策略而被放置在哪個階段，一目瞭然。可以隨時發散，適時收斂，若由團隊與產品擁有人(PO)共同創建，更能建立共識，促進協作。
• 幫助發佈計畫(Release planning)，各階段的發佈目標是什麼？與希望透過發佈後學習產品改善的部分是什麼，都可透過使用者故事對照(User story mapping)來規劃。
• 優先排序價值假設或客群，想學習或驗證哪些假設？針對這些假設指定需求角色，規劃這次產品發佈所需功能。故事對照(Story mapping)可以針對價值假設發散相對應的需求，然後逐步收斂，關注在這次發佈的功能，能否幫用戶解決痛點。
• 方便規劃最小可行性產品，如果只是為了驗證假設，可以選擇最快達成目標的產品發佈規劃(Release planning)，不需要做完所有用戶所需的全部功能再發佈。依不同的使用者類型區分，先針對某類使用者，規劃他們需要的功能，提供最小可解決方案。因為有多種類的用戶，優先排序最想解決他們問題的使用者類型。

User story mapping

產品待辦清單的內容

• 形式不拘，可以是需求分析，產品需求文檔(Product requirement documents)，或使用者故事(User story)等。
• 使用者故事是一個用來理解功能前後脈絡的工具，它的本質是拿來溝通交流用的，重點還是跟開發團隊, 利益關係人交流時方便理解前後脈絡，花大量的時間撰寫使用者故事，與直接溝通，可以評估一下哪個划算。
• 使用者故事有三要素，誰(Who)？為什麼(Why)？與要做什麼(What)？產品負責人應該專注在誰(Who)跟為什麼(Why)上，而做什麼(What)與怎麼做(How)可讓團隊一起發散想法。PO在定義使用者故事時，不用執著細節，相反，最好的方式是透過團隊發散，討論出多種解決方案(What)，再交由PO依照個人經驗判斷，決定哪個方案。產品待辦清單中的項目(PBI)優先等級越高，粒度越細，反之，粒度可以較粗。

一個決定產品發佈該包含哪些需求的實例

推薦餐廳美食的產品，願景在幫助人們找到最棒的餐廳。

經過情境(Scenario)分析，有多種情境需要被滿足：

• Amy出差在外，不熟悉環境，想找附近餐廳。
• David這週要去信義區和朋友聚餐，想找該區域最棒的餐廳。

這兩種情境所需提供的功能截然不同，前者需要列出距離最近的餐廳。後者可能需要以區域搜尋餐廳，並且優先考慮顧客評價。因應這兩種情境，產出三個需求，究竟要做哪個？可能大家爭得面紅耳赤也不會有結果。

沒有必做或絕對不能做的需求，上述三個需求沒有誰對誰錯，哪個必做，他們都是針對某一種情境與用戶提出的價值假設，此時需要的並不是爭論要做哪個？而是快速選擇一種情境/用戶，為其提供最小可行性產品，快速進行價值假設驗證，產品發佈的重點在於產品學習(Product learning)，也就是每次產品發佈後，驗證習得的回饋，調整前進目標的方向(Adapt)。對於發佈版本設定一個可測量的具體目標，像是增加10%的新客戶註冊量等，讓每個新作的功能得以被驗證是不是掰卡，才知道目前開發的功能是不是真有價值。

維護產品待辦清單(Product backlog)

在產品待辦清單精煉會議(Product backlog refinement meeting/PBR)上，PO與開發團隊會一起聽論較優先的產品需求，主要目的在於溝通與釐清需求，在Sprint內，Scrum team 挪出 5-10% 的時間來Refine Product Backlog Item。維護的過程包含：

• 發現與貢獻新想法，可以持續發散新需求 
• 收斂需求與拆分、細節化優先度較高的故事或需求，也可討論優先權較高項目的驗收標準(acceptance criteria)。分割需求(Splitting goals)，當一個使用者故事內要做的功能包山包海時，就是分割的好時機了。分割原則很簡單，所有故事與任務完成時，都是有價值且可用的，非半成品。 
• 收斂想法選擇一個想優先驗證的假設，選擇可以知道假設是否正確的功能開發，這些功能是為了優先解決哪類用戶的什麼痛點，大家發散的想法多少有主觀成分，最終收斂還是要靠PO的經驗判斷，這裡強調的是團隊與PO之間的溝通與產生共識，為何選擇某些功能優先開發，應溝通協調清楚背後的理由，把背後原因，與自己偏好哪類用戶類型指出。至於若有多項假設需要驗證，盡量針對一種用戶，解決他們的痛點，迅速迭代。

哪個需求最有價值？

哪個需求先做，端看這個需求與其他需求相對而言，誰價值較高。決定把人力投資在開發哪些需求，就跟價值投資一樣，重點在於選擇高報酬的項目。

高報酬的項目 = 相較於其他需求，商業價值高且風險低的功能項目

十個客戶提出需求，不可能這十個需求的價值都相同，舉例，可能十個需求中，有兩個的收益是相同的，但完成這兩個需求的成本卻不同。在這種情況下，我們可以說花費較低成本的，價值較高。有評估的準則後，透過比較價值，便可決定如何分配團隊開發資源。最好的選擇是優先選擇那些具有高價值的，但若高價值的風險太大，或代價過高，則可以考慮先降低風險。 考慮投資報酬率(Return of investing)，當選擇這個功能進行實作，能夠帶來的收益與價值高過選擇其他功能。

當然商業價值不僅只是評估收益與成本之間的關係，還包含下列幾項：

•  立即收益(Immediate revenue)
•  長期獲利(Long term profitability)
•  顧客重要性(Customer importance)
•  顧客成長(Customer growth)
•  競爭能力(Competition)
•  產品策略(Product strategy)

老師還有提到一個價值模型，考慮的是商業價值，成本，收益三者之間的平衡關係。

產品負責人(PO)、團隊(Team)、與衝刺週期(Sprint)

• 產能速度圖(Velocity chart)來評估團隊戰力，一個觀察開發團隊產能的工具，建議拉長時間觀察，比方說以Release週期或三個月半年，因為產能本身有許多變數，時間拉長，觀察較準。這讓我想到觀察一個人也要看長期表現，如果只觀察一次考試，考不好可能由於許多突發原因如前一天睡不飽，但一直都考不好，就很難找到藉口了。

Velocity chart

• 衝刺計畫會議(Sprint planning meeting)，會議包含兩階段，第一階段時，產品負責人(Product Owner)應關注要做什麼(What) 並與團隊建立共識，如驗收標準，PO看待使用者故事的角度是從顧客觀點出發，至於拆分的任務細節留待團隊內協調即可。
•  衝刺中的例行會議(Sprint)，PO可參與幾次的站立會議，了解開發有無遇到困難。即時檢討(Just in time review)，不要等到衝刺週期快結束才確認檢討(Review)，可如果在Sprint review那天沒做完，表示這個在Sprint中並沒有和Team緊密協作。
• 衝刺檢視會議(Sprint review)，檢視的目標在於學習，並檢視離產品目標還有多遠，要怎麼調整，才能在下個衝刺(Sprint)做得更好，會議由PO主導，確認驗收標準只是其中的一小部分，在Sprint過程中，對於驗收標準如果有什麼問題，應該都已經協調過了。並且有共識。檢視會議完可考慮做訪談或調研，甚至加入使用者進行分析，這些研究工作不一定只能PO做，可讓整個團隊一起做。               
• 調整發佈燃盡圖(Released burn-down)，適用於範圍穩定，或發佈週期長的產品。
• 更新使用者地圖對照，哪些Scenario完成了，下一個Scenario在哪個上面，如果有沒完成的，哪幾個story應該接著完成掉。
• 更新影響地圖(Impact map)，如果能夠結合數據看能夠有用，看離目標還有多遠。
• 資訊雙向透明化，像是這些功能發佈後，產品有無達成目標等，或者它們的影響如何，產品負責人可適時的和團隊分享關於產品面的資訊。
• 避免被半成品綁架，完全沒做的不一定下個衝刺週期會繼續做，但通常如果完成一半的功能，很容易得接著做，所以盡量避免被半成品綁架。
• 衝刺反省會議(Sprint retrospective)，也須同時檢視與反省產品負責人與團隊的有效協作？或者彼此的期待為何？建立信任關係。可用老師介紹的Trust game來溝通與換位思考對彼此的期待為何。

開發典範轉移(Paradigm shift)

傳統：先決定範圍再決定資源與時間
敏捷：先決定時間與資源，再決定範圍

先確定時間與資源，再決定要發佈多少功能，盡量避免浪費。

實務問題指南

團隊需要時間還技術債時，該怎麼抉擇？
盡量將這些技術債再拆的更小一點，如一次重構一個組件等，將重構排進每個衝刺最後的一個故事內，因為團隊的產能會變動，若提早完成該衝刺期間較優先的故事時，便可順利接續逐步還清技術債。

風險大的故事，何時做恰當？
要看這個故事的價值，如果價值高，那還是要得做，可陸續排Spike的Task，提早研究。如果價值低，那當然就不需要投資啦。

有時沒辦法馬上開發，需要時間研究相關技術時，怎麼辦？
若需要研究，便可安排Spike的故事，而Spike是得做出東西來，不能只是寫寫文件。當風險有效降低時，便可決定下一步何時做。

一個計畫一百，完成率一百的團隊是好團隊嗎？ 
不是，因為表示有人抓Buffer，才能百分之百無意外。重點還是在，產品負責人跟團隊有共識，追求的不是百分之百做完，而是產品的成功。

感想

Scrum只是落實Agile的其中一種框架，重點還是在人，與如何促進協作，盡快抵達目標。利用二二八連假，上了這堂Odd-e的Certified Scrum Product Owner課程，講師是吕毅，非常充實，實戰的練習也很多。上面的筆記我大概整理了快四天，累累Der，有些敏捷工具像是使用者故事對照或影響地圖，之後有空再介紹，不過上面的不是完全照本宣科，有些加上我自己個人的想法，有些則是多收集其他工具的資訊，一併整理的心得。

輸入：9h

輸出：10h