# Scrum敏捷產品管理：打造客戶喜愛的產品<br/>Agile Product Management with Scrum: Creating Products that Customers Love
## Chapter 01：了解Product Owner角色
### Product Owner角色
PO 引領開發工作，打造能產生預期效益的產品。
PO 職責通常包含:
* 發展產品願景
* 梳理產品待辦清單
* 規劃發布
* 與客戶、使用者、其他利害關係人互動
* 管理預算
* 準備產品上市
* 參加 Scrum 會議
* 與團隊協同合作

### Product Owner的理想特質
#### 遠見者與執行者
PO 是遠見者，能夠遇見最終產品的樣貌，並傳達產品願景。

PO 是執行者，能見證願景從開端至實現。
這包括:
* 描述需求
* 與團隊密切協作
* 驗收或否決工作成果
* 追蹤及預測進展以掌握專案方向

PO 是企業家，要促進創造力、鼓勵創新，並且要能適應變革、不確定性、爭論、衝突、玩笑、試驗，並在考慮周全後承擔風險。
#### 領導者與團隊成員
PO 是負責產品成敗的人
PO 會為參與開發工作的每一個人提供指導方針及方向，並確保能做出艱困的決策。
PO 是一位擅長與團隊合作的人，還需要在沒有正式職權的情況下與其他的 Scrum 團隊成員緊密協作。
PO 絕不應該影響決策，但也不該優柔寡斷，或採取放任型管理風格。
#### 溝通者與協商者
PO 是一個有力的溝通者與協商者。需與各方溝通與協調，
包括:
* 客戶
* 使用者
* 開發與工程人員
* 行銷人員
* 銷售人員
* 服務部門
* 營運部門
* 管理層

PO 是客戶的心聲，傳達客戶的需要與需求，並作為管理層與技術人員認知落差之間的溝通橋樑。
#### 獲得授權與承諾
PO 必須有足夠的職權與適當職級的管理層支持，以領導開發工作，並協調各方利害關係人。

PO 必須擁有適當的決策權，從物色合適的團隊成員到決定產品發布時會包含哪些功能。
PO 必須是一個能夠託管預算的人，也需要有能力營造一個促進創造力及革新的工作環境。
PO 必須開發工作作出承諾。
成功的 PO 是充滿自信、熱忱、活力，且值得信賴的。
#### 時間充裕且能勝任
PO 必須有充裕的時間，以及能勝任且完成出色的工作。
PO 有充裕的時間來持續地履行其責任是非常重要的。

### 與團隊合作
PO 是 Scrum 團隊的一份子，且仰賴與 ScrumMaster 及團隊的協同合作。必須是不分你我，只能是我們。

一小時規則: PO 每天應該至少花一小時在團隊辦公室中與團隊共處。
### 與ScrumMaster協同合作
Product Owner 主要負責該做什麼(What) 打造正確的產品。
Scrum Master 主要負責該怎麼做(How) 運用正確的方式實施 Scrum。
### 與客戶、使用者及其他利害關係人合作
要打造成功的產品，Product Owner、ScrumMaster 和團隊必須深入了解客戶及使用者的需求，以及如何充分滿足這些需求。

最好的方式就是在開發過程中及早持續地讓客戶與使用者參與其中。
請客戶對雛型提供回饋、邀請客戶代表參加 Sprint 審查會議，並及早且頻繁地發布軟體，都是了解客戶想的絕佳方式。

目標是協助客戶與產品開發公司獲得預期的效益，而產品僅僅是達成此目標的手段，並非最終目標，團隊應將此銘記於心。
### 擴展Product Owner角色
#### 首席 Product Owner
#### Product Owner 的層級結構

Product Owner 會從所在層級向下規劃、撰寫、分配及追蹤工作。
Product Owner 的層級越高，工作越困難。產品層級的工作通常需要由具備副總裁級或總監級職稱和職權的人負責。
#### 選擇適合的 Product Owner
對於開發產品增量(Product Increment)的團隊而言，有以下兩種組建方式:
* 功能特性團隊(Feature Team)
FT 會執行一連串的需求。
* 組件團隊(Component Team)
CT 會開發組建或子系統。
### 常見錯誤
#### 權力不足的 Product Owner
#### 超量負荷的 Product Owner
症狀包括:
* 忽略產品待辦清單梳理(Product Backlog Grooming)
* 錯過 Sprint 規劃
* 審查會議
* 無法接受提問
* 推延許久才給出答案

負擔過重的兩大原因:
* 沒有足夠的時間來履行該角色
* 沒有獲得團隊的足夠支援
#### 角色分割的 Product Owner
#### 遠距的 Product Owner
#### Product Owner 代理人
#### Product Owner 委員會
### 反思
---
## Chapter 02：規劃產品願景
### 產品願景
在各個 Sprint 審查(Sprint Review)會議中向客戶與使用者展示產品的各式增量(Increment)、及早發布軟體，並頻繁地評估與精練(Refine)願景。

一個有效的願景應該能夠回答以下問題:
* 誰會購買此產品?誰是目標客戶?誰將使用此產品?誰是目標使用者?
* 此產品可以滿足那些需求? 此產品能增加什麼價值?
* 哪一項產品屬性對於滿足特定需求及產品的成功是至關重要的?此產品的外型與功能大致為何?此產品在哪方面表現出色?
* 將此產品與競爭對手及公司內部的現有產品相比較，此產品在哪方面表現出色?
* 公司該如何從此產品的銷售中獲利?其收益來源與商業模是為何?
* 此產品的可行性如何?公司可以開發及銷售此產品嗎?
### 願景的理想特質
願景應以簡明扼要的方式傳達未來產品的特質，同時描述出一個共同的目標，此目標不僅能提供方向，且能夠廣泛到足以激發創造力。
#### 共享與整合
參與開發工作的每一個人都應該認同願景。
#### 廣泛且吸引人
產品願景應該描述一個廣泛且吸引人的目標:這個目標不僅能夠引領開發工作，也能為創造力保留足夠的空間，還能夠吸引及鼓舞人心。
#### 簡短且明確
談到產品願景，請謹記少即是多的原則。
願景應該簡明扼要，並且只包括對產品成功至關重要的資訊。
### 最小可銷售產品
為了發展願景，Scrum 團隊需要展望未來，並說明心目中未來產品大致的外型與功能。

由於我們對未來的預測能力有限，因此要獲得成功的最佳機會就是構想出最小可銷售產品(Minimal Marketable Product)，這類產品具備可滿足特定客戶需求的最少功能。
### 簡潔
簡潔(Simplicity)可促使打造出具備易於使用的最小功能產品。
#### 奧卡姆剃刀原理
假設在功能相當設計中進行選擇，應選擇最簡潔的設計。
#### 少即是多
#### 簡潔的使用者介面
### 客戶需求與產品屬性
客戶需求與產品屬性是願景的核心。
挑選出相對應的客戶需求可以讓我們知道將關注哪個市場或哪些客群。
產品屬性是就是產品為了滿足這些需求而需要的關鍵特性。

Cockburn 建議，針對產品屬性可以運用下列的優先排序要素:
* 為此事犧牲其他
* 盡量保留
* 為其他犧牲此事
### 願景的誕生
#### 運用個人偏好專案
#### 運用 Scrum
### 願景發展技術
一些有助於發展產品願景的技術。
提供足夠的資訊，讓判斷這些技術是否適用於專案，其包括:
* 雛形(Prototype)與試驗模型(Mock-up)
* 人物誌(Persona)與情境(Scenario)
* 使用者案例(Use Case)與使用者故事(User Story)
* 排序(Sequence)與故事板(Storyboard)
* 願景盒(Vison Box)與審查(Review)
* 狩野模型(Kano Model)

#### 雛形與試驗模型
將發展願景理解為一個需要透過實驗來獲取與學習經驗的探索過程。
##### 規劃、執行、檢查、以及行動
戴明循環(Demin Cycle)
* 制定假說(規劃)
* 驗證假說(執行)
* 審查結果(檢查)
* 如果實驗失敗，會視需求調整假說，然後進行另一輪實驗，可能是微調結果，或嘗試不同手法(行動)

#### 人物誌與情境
人物誌有助於我們選擇目標客戶。情境讓我們了解產品如何改變客戶的生活。
打造情境的方式是製作兩個消費圖(Consumption Map):
一個是在沒有產品的情況下，實現特定目標所需要的活動。
一個是在有產品可以使用的未來情況下所需要的活動。
#### 願景盒與行業期刊評論
要決定產品的附加價值及賣點有兩個有效的技術，分別是
* 願景盒(Vision Box)
願景盒是產品出貨時可能使用的包裝試驗模型。
要打造願景盒，Scrum 團隊需要選出產品名稱、產品圖示，以及能夠成功推銷產品的三項說明。
* 行業期刊評論(Trade Journal Review)
為了撰寫行業期刊評論，Scrum 團隊成員需探索他們想在產品發表時讀到那些內容。
#### 狩野模型
狩野模型說明了當我們在實施某些特定產品時，客戶可能的滿意程度為何。
此模型區分成三種功能類別:
* 基本型(Basic)
* 性能型(Performance)
* 愉悅型(Delighters)
### 發展願景與產品路線圖
### 最小可行產品與產品變體
### 常見錯誤
#### 沒有願景
在沒有產品願景的情況下就開始打造產品。
#### 預言型願景
即使願景描繪出未來的產品樣貌，但所預想的未來可能永遠不會實現。
#### 分析癱瘓
不要過度進行事前的市場調查，也要避免落入分析癱瘓的陷阱。
#### 深信自己完全了解客戶需求
將自己隔絕於市場之外。公司僅仰賴管理層的直覺或開發人員的卓越技術，並深信自己完全了解什麼對客戶是最好的。
#### 大即是美
儘管爆炸式的大規模開發看來十分令人振奮，但也有缺點:他們耗費大量的時間與金錢，而且失敗的風險也非常高。
### 反思
確保 Scrum 團隊對於未來的產品有一個共同的願景。
* 產品是否遵循著共同的目標?
* 目標是如何產生的?由誰創造的?
* 為了發展出具備各項特質之願景，需要做什麼呢?
* 這樣的願景將如何改善創新的過程?

---
## Chapter 03：運用產品待辦清單
### 產品待辦清單的DEEP特性

產品待辦清單有4個特性:
* 適度詳細(Detailed Appropriately)
* 估算過的(Estimated)
* 湧現的(Emergent)
* 具優先順序的(Prioritized)
#### 過度詳細的

高優先項目比低優先項目具有更加詳細的描述。
#### 估算過的
估算是粗顆粒程度的，且通常是以故事點(Story Point)或理想天數(Ideal Day)來表達。
#### 湧現的
清單會不斷地演進，內容也經常發生變化。
#### 具優先順序的
先執行最重要且優先順序最高的項目。
### 梳理產品待辦清單
* 更新項目
* 重新排序優先項目
* 為 Spirnt 規劃會議準備好已分解、精煉過的 高優先級項目
* 確認項目的規模，重新估算符合所需要的規模。
### 探索與描述項目
探索與描述產品待辦清單項目是一個持續進行的過程。
Scrum 不會在初期就提出固定需求，而是會在整個專案中進行探索與描述細節。
隨著對於客戶的需求以及如何才能妥善滿足這些需求的理解程度不斷地提升，現有需求可能會發生變化或是顯得多餘。
#### 探索項目
探索產品待辦清單項目要從儲備產品待辦清單開始。
每當將需求記錄進待辦清單時，請確保團隊均已充分理解相關的客戶需求。
請了解為什麼這項需求是必要的，以及它將如何使客戶受益。
將需求視為負債，而不是資產。
#### 描述項目
使用者故事描述的是客戶或使用者運用產品的情況。
其中須包含適合的名稱、簡短的敘述，以及具體的驗收準則與條件，才能構成完整的故事。
#### 建立待辦清單
將產品待辦清單中的相關項目群組成主題(Theme)是有益的。
主題是產品功能的暫替內容，它們組成待辦清單、協助優先等級排序、讓存取資訊更容易。
### 安排產品待辦清單的優先順序
在排序產品待辦清單時會涉及到的因素:
* 價值
* 知識
* 不確定與風險
* 可發布性
* 相依關係
#### 價值
如何判斷產品待辦清單項目的價值?
該項目是讓產品上市的必要項目，那麼就十分有價值。
#### 知識、不確定性及風險
風險是軟體開發必然的一部份，沒有任何產品能夠在毫無風險的情況下問世。
與風險相關的是不確定性，專案的不確定性愈高，風險就愈高。
不確定性是由知識不足導致的，對開發的內容與方法所知愈少，不確定性就愈大。
由於風險與不確定性會影響產品成敗，因此不確定性與高風險的項目應該列為高優先等級。
這樣一來就可以加快產生新知識、屏除不確定性、以及降低風險。
#### 可發布性
及早且頻繁地發布軟體的好處:
* 讓軟體演進為客戶喜愛的產品
* 減輕風險
* 確定某個功能是否需要被實施
* 影響產品待辦清單的優先順序
* 取得預期回饋
#### 相依關係
在處理相依的使用者故事時，有兩種常見的技巧:
* 將數個相依項目結合成一個更大的項目
* 使用不同方式分割項目
### 為Sprint規劃做好準備
準備下個 Sprint 規劃會議中可能會處理的產品待辦清單項目。
先選擇 Sprint 目標，並依此開始準備工作。
#### 選擇 Sprint 目標
#### 及時準備正好足夠的項目
分解與細化產品
#### 分解項目
分解產品待辦清單事項是指讓項目變得越來越小，直到它們適合放入一個Sprint為止。這個過程又稱 漸進式需求分解(Progressive Requirements Decomposititon)。

分解使用者故事

#### 確保明確性、可測試性及可行性
根據團隊的完成的定義(Definition of Done)
### 設定項目大小
#### 故事點
#### 規劃撲克牌
##### 估算非功能性需求
##### 快速估算
### 考量非功能性需求
非功能性需求又稱營運需求、系統品質、限制，即便這些需求描述著績效、穩健程度、可擴展性、可用性，以及技術與合規性需求等重要屬性，卻常被忽略。
#### 描述非功能性需求
可以用限制來表達非功能性需求
#### 管理非功能性需求
將它們區分成整體的非功能性需求與局部的非功能性需求將會很有幫助。
### 擴展產品待辦清單的規模
#### 僅用一份產品待辦清單
進行大型 Scrum 專案時，確保僅有一份產品待辦清單，且其中涵蓋能讓產品上市的必要工作。
避免使用那些將產品需求轉換為子系統或組件需求的團隊或組件待辦清單。
這類待辦清單會衍生高額營運費用，因為其內容源自於產品待辦清單，而且需要進行梳理，並保持同步。
#### 擴展梳理範圍
對大型 Scrum 專案來說，產品待辦清單項目仍需要及時分解與精煉，但梳理範圍會有所變化。
#### 提供不同的待辦清單觀點
具備多個功能特性團隊的大型敏捷式專案，在產品待辦清單中會因為使用不同的觀點而受益。每個觀點均可視為待辦清單的子集合。
### 常見錯誤
#### 偽裝的需求規格說明書
若遇到 偽裝的需求規格說明書 的待辦清單，請檢查是否有產品願景。
* 若有產品願景，請依據該願景建立新的產品待辦清單，並捨棄該需求規格說明書。
* 若沒有產品願景，請停下手邊的工作，並執行所需的發展願景工作。
#### 不切實際的願望清單
建議使用產品構想或願景來確定哪些項目是開發與發表成功產品的關鍵。其餘的都可通通捨棄。
#### 強行提出需求
有時候，Product Owner 會自行寫下待辦清單項目，然後在 Sprint 規劃會議中逕行交給團隊。這樣的手法加深了項是傳統敵對式陣營的分裂。
這不僅浪費團隊的知識、經驗、創造力，也讓 Sprint 規劃更加困難。
所以，務必確保 Product Owner 始終讓 Scrum 團隊成員參與梳理工作。
#### 忽略梳理
如果在開會之前都未能預先梳理待辦清單，Product Owner 與團隊就會在會議中進行梳理，這麼做不僅耗費寶貴的規劃時間，也會導致所得到的需求品質低落，或是所得到的承諾效力不足。
#### 相互競爭的待辦清單
多位 Product Owner 在同一個團隊工作，所以團隊被要求在每個 Sprint 期間都需要處理多份待辦清單。
* 不過因為任何事情都需要花很長時間才能完成而感到不滿。
* 同時處理多個產品看似很不錯，但卻沒有一件事情進展快速。
* 團隊從沒有一致且連慣性的 Sprint 目的，每一次的任務切換都會浪費許多寶貴的時間。
### 反思
* 如何在工作環境中探索及描述需求?
* 產品待辦清單是否具備 DEEP 特性?
* 如何梳理產品待辦清單?
* 可以採取哪些方法，才能在每個 Sprint 中以協作的方式探索與描述需求?
* 如何處理非功能性需求?會在什麼時機及使用哪些方法記錄它們?
---
## Chapter 04：規劃發布
### 時間、成本及功能
哪一個要素對於發表成功的產品是不能妥協的?
固定時間，讓功能保持彈性。

固定功能是個餿主意。即使有產品願景，仍然無法提前掌握產品的具體屬性、功能(Functionality)與功能特性(Features)。而且還是需要根據客戶和使用者的回饋才能進一步地探索。
#### 如何處理固定價格合約?
盡量避免固定價格與固定範疇的專案。
### 固定品質
### 及早且頻繁地發布
* 帶來無價的回饋。
* 可以快速找出考慮不周的願景，讓團隊有機會修正願景，或乾脆在早期就取消專案。
* 避免 Scrum 團隊開發出錯誤的功能特性、過多功能或過少功能的產品。
### 季度週期
Scrum 並沒有強制規定專案的時間長短，但是，敏捷式專案通常不超過三到六個月。如果需要過三、四個月才能讓產品上市，則應該使用季度週期，在每個季度至少推出一個可正常運作、經過測試及記錄的軟體版本。
### 速度
速度(Velocity)顯示團隊在一個 Sprint 中可完成多少工作，我們能透過它來追蹤並預測專案進度。
速度是 Product Owner 在一個 Sprint 中所能接受的工作成果總合。

### 發布燃盡圖
#### 發布燃盡圖
發布燃盡圖可讓我們追蹤與預測專案進度。

#### 發布燃盡長條圖
具備發布燃盡圖所有的屬性，但多了
* 可以重新估算項目與燃盡工作
* 新增與移除產品待辦清單項目

### 發布計畫書

#### 預測速度

#### 建立發布計畫
### 大型專案的發布規劃
#### 常用的估算基準
估算產品待辦清單中的各個項目時，這些團隊需要一份共同的基準，好讓對於估算值、故事點的範圍及每個數字的意思都有共識。
#### 前瞻性規畫
展望未來二到三個Sprint，以便了解可能需要處理那些產品待辦清單項目。
此事需要及早分解與精煉產品待辦清單項目，這可讓你在產品待辦清單項目的頂端找到更詳細的項目。
#### 管線化
管線化是最後手段。只能在所有其他選項都失敗後，才運用此技巧。
管線化將原本是一體的項目分開，它把一項產品待辦清單項目分散到不同的 Sprint 來交付。
### 常見錯誤
#### 沒有發布燃盡圖或計畫書
完全不執行任何發布規劃活動。只針對單一Sprint進行思考是很危險的。因為這樣做，會讓我們很難評估專案進度，也無法以正確的方式調整產品與專案。
#### 袖手旁觀的 Product Owner
Product Owner 應該積極參與發布規劃活動，不應該將這些活動委派給 ScrumMaster 或團隊。
#### 大爆炸式的一次性發布
大爆炸式的一次性發布，只有當所有功能都完成後才交付產品。要想納入客戶與使用者的回饋就難如登天，也很難打造人們喜歡的產品。
大爆炸式的一次性發布，意味著團隊在即將發布時才開始部屬軟體，這往往給團隊成員帶來壓力，且可能導致錯過發布良機。
#### 向品質妥協
Product Owner 可能會受到發布更多功能得誘惑，而犧牲了品質。
團隊必須備妥完成的定義，它可用來說明必須完成的產品增量準則，
且 Product Owner 必須在每個 Sprint 審查時都使用該準則；
不應該接受僅部分完成或有缺陷的工作。
### 反思
* 固定時間與品質，讓功能保有彈性會有哪些後果?
* 及早且頻繁地發布有何益處?而這需要我們怎麼做呢?
* 我們需要做什麼才能以季度週期來安排專案?
* 團隊的速度如何?
* 是否會採用發布燃盡圖或計劃書?由誰建立與更新呢?
---
## Chapter 05：在Sprint會議中協同合作
Scrum 提供的就是增量式工作方法，它可讓產品逐步地上市，每一個Sprint 都建立於前一個 Sprint 的成果上。
Sprint 是由各式會議構成的
* Sprint 規劃(Sprint Planning)
* 每日 Scrum (Daily Scrum)
* Sprint 審查(Sprint Review)
* Sprint 回顧(Sprint Retropective)
### Sprint規劃會議
Sprint 規劃會議讓團隊能夠規劃他們的工作，並對 Sprint 目標做出承諾，且可藉此奠定自組織(Self-organization)的基礎。

Product Owner 的責任是確保產品待辦清單可以得到妥善的梳理，排定項目的優先順序，且詳細描述高優先等級的項目。

在 Sprint 規劃期間，Product Owner 的角色是協助團隊理解那些工作必須完成。
### 完成的定義
完成的準則通常會要求產品待辦清單項目(Product Backlog Item)需要轉換成已被充分測試與記錄的可正常運作的軟體。

### 每日Scrum會議
每日 Scrum 會議可讓團隊每天都可管理其工作，並發現障礙。
身為 Product Owner ，應該盡可能地餐與會議。此會議是用來了解進度與確認團隊是否需要協助的絕佳時機。
#### 障礙
問題未經處理會不斷地增長。
這也是 Scrum 注重障礙管理的原因，找出阻礙進展及危害專案的問題，並著手處理。

### Sprint待辦清單與Sprint燃盡圖
Sprint 待辦清單包括達成 Sprint 目標所需進行的所有活動。
身為 Product Owner，這些工件確實有助於判斷團隊是否能實現承諾，並交付成果，但都不是用來向利害關係人報告的機制。
### Sprint審查會議
Product Owner 的任務是啟動 Sprint 審查回憶，並將產品的增量與 Sprint 目標、實際情況及理想目標進行比對，並藉次判斷專案進度。
確保你已充分審查產品增量(Product Increment)，且準備接受或拒絕團隊所承諾達成的產品待辦清單項目。
#### 及時審查
Product Owner 不需要等到 Sprint 審查會議時才對工作結果提出回饋。
### Sprint回顧會議
Sprint 回顧會議讓 Scrum 團隊能檢驗工作執行的方式、找出問題與其原因，以及探索能讓工作變得更愉快且更有效的改善措施。
Product Owner，需定期參與 Sprint 回顧會議，參與會議讓你可以提出改善措施，並強化與 Scrum 團隊成員之間的關係。
### 大型專案的Sprint會議
#### 聯合 Sprint 規劃會議
與多個團隊進行 Sprint 規劃會議需要額外的準備工作，包括:擴展梳理範圍、提前規劃。
各個團隊一起探討與了解所有團隊需要共同努力的總體 Sprint 目標為何，讓大家都可以了解整個專案在 Sprint 中的預期結果。
#### Scrum of Scrums 會議
Scrum of Scrums 會議可讓多個團隊在 Sprint 期間每日皆可進行協調。
團隊代表人員會在各自團隊的每日 Scrum 完成後開會討論當下現況、已規劃的工作，以及各個團隊之間的相依關係。
#### 聯合 Sprint 審查會議
#### 聯合 Sprint 回顧會議
各個團隊還需要找出共同的改善措施，並分享彼此的見解。
### 常見錯誤
#### 快閃型 Product Owner
快閃型 Product Owner 在 Sprint 期間與團隊的協作相當有限，或根本就無法合作，想透過電話或電子郵件他也都困難重重。
Product Owner 是產品成敗的關鍵角色。因此 Product Owner 的責任是你的第一要務。應該花上足夠的時間與團隊相處，以便可以為他們解惑、審查工作或排除障礙。
#### 消極型 Product Owner
消極型的 Product Owner 常常在 Sprint 審查會議中消極地冷眼旁觀。這個會議並不是要 Product Owner 露臉及旁觀而已，其目的是大家一起找出需要完成的項目為何，藉此大幅提高打造出成功產品的機會。身為 Product Owner 必須積極地為會議做出貢獻，並確保產品朝著正確的方向前進。
#### 不穩定的步調
開發產品猶如跑馬拉松。要想到達終點，就必須選擇穩定的步調。
許多 Product Owner 都會犯下向團隊施壓以接下更多工作的錯誤。短期來說，這樣的確可以提高速度，但卻無法持久。
如果每一個 Sprint 都像是踏上了死亡之路，人們會快速地失去幹勁、生病、或退出。
身為 Product Owner ，必須尊重團隊的權力，無論發布燃盡圖的內容如何。若是進度太慢，可召集所有人一起找出有創業且健康的解決方案，而不是逼迫人們花更長的時間工作。
#### 迷霧幻境
打造透明性，請鼓勵團隊保持 Sprint 審查會議的真實性。
允許團隊只展示他們認為符合完成的定義之工作結果。
#### 向上呈報 Sprint 燃盡圖
Sprint 燃盡圖的目的是協助團隊每天檢驗其進度，並據此調整其工作。
燃盡圖並不是狀態報告，將燃盡圖作為報告工具，會讓其轉變為一種控制機制。
管理層若要求定期檢視 Sprint 燃盡圖，則是缺乏信任的跡象。
Product Owner 可以邀請利害關係人參與 Sprint 審查會議與每日 Scrum，藉此解決此情況所衍生的問題。
### 反思
* 如何在 Sprint 規劃會議中協助團隊，且不違反團隊的自組織?
* 如何為 每日 Scrum 會議帶來有效貢獻?
* 如何與團隊緊密協作，針對工作結果及早地提供回饋?
* 如何讓 Sprint 審查會議更有成效且更有趣?
* 參加 Sprint 回顧會議嗎?若答案是沒有，要如何做你才會參加?有哪些效益?

---
## Chapter 06：轉變至Product Owner角色
### 成為優秀的Product Owner
#### 認識自我
要成為優秀的Product Owner，首先要先了解自己所擔任的角色，希望如何發站自己的專業技能。反思自身的技巧與能力，並與 Product Owner 的職責進行比對，並找出自己覺得很難勝任或可能會遭受挫折的職責。

Product Owner 應該與不應該做的事

#### 發展與成長
參加 Scrum Product Owner 培訓
實踐 Scrum 價值觀
#### 找為教練
#### 確保能得到適當層級的支持
#### 尚未爐火純青
### 培養優秀的Product Owner
#### 認識角色的重要性
#### 選擇合適的 Product Owner
#### 授權並支持 Product Owner
#### 支持 Product Owner 角色的應用
### 反思
正在轉變成 Product Owner 角色的人員
* 認為這角色可能會遇到的什麼困難是什麼?
* 該如何取得所需知識，才能順利開始新角色?
* 誰能協助你發展一位 Product Owner?
* 公司內部是否有其他可聯繫的 Product Owner?
為了在組織中建立 Product Owner 角色
* Product Owner 角色對組織有何影響?
* 對於成功的 Product Owner 而言，哪些是最重要的事?
* 你能如何幫 Product Owner 將工作做好?
* 公司該如何支持Product Owner 角色的有效應用?

## 專業術語
* 產品路線圖(Product Road Map)
* 消費圖(Consumption Map)
* 雛形(Prototype)與試驗模型(Mock-up)
* 人物誌(Persona)與情境(Scenario)
* 使用者案例(Use Case)與使用者故事(User Story)
* 排序(Sequence)與故事板(Storyboard)
* 願景盒(Vison Box)與審查(Review)
* 狩野模型(Kano Model)
* 願景盒(Vision Box)
* 行業期刊評論(Trade Journal Review)
* 漸進式需求分解(Progressive Requirements Decomposititon)
* 將需求視為負債，而不是資產
* 完成的定義(Definition of Done)
* [INVEST 準則](https://en.wikipedia.org/wiki/INVEST_(mnemonic))
* 布魯克斯法則(Brooks's Law)
* 不確定性圓錐(Cone of Uncertainty)
* Schwaber and Beedle Scrum 五大價值:尊重、承諾、專注、開放、勇氣。
## 待瞭解
* User story 工具
* CSM
* CSPO
* 開放空間會議技術(Open Space Technology)

## 相關書籍
* 商業分析
* PMBOK Guide
* Agile Practice Guide
* Scrum - Agiles Projektmanagement erfolgreich einsetzen
* Scrum - Applying Agile Project Managerment Successfully
* Agile Project Management with Scrum
* Ten Principles that contribute to a googley user experience
* Agile Estimating and Planning
* Coaching Agile Teams

###### tags: `Golden Notes`