敏捷也需要估計?還是不需要浪費時間估計?

 

也許你會聽過『敏捷不需要估計』？也許你也聽過『敏捷也需要估計』？但是其實『估不估計』都是學問。

先下個結論

• 估計不是為了精準，估計也不是為了承諾。
• 估計是為了學習，估計是為了溝通，估計是為了理解，估計是為了共識。
• 估計不是結果導向，估計是過程導向。
• 估計不是一種目的，估計是一種手段。

估計的好與不好

先來說個小故事，某一天剛加入團隊的新人（New）問我『為什麼我們的開發團隊在 Sprint Planning 時都沒有進行估計呢？』

以下用 N 代表新人、V 代表 Vince

• V：『你過去的經驗，有估計嗎？用什麼方法估計呢？當時團隊的組成有誰呢？』
• N：『有啊！我們有在 Sprint Planning 時會估計，用 Scrum 的 Planning Poker 作估計，我們團隊組成有一位 Android, 一位 iOS, 兩位 Backend, 一位 PM，我們五位一起估計』
• V：『聽起來很不錯啊！當時估計的過程你有什麼發現嗎？』
• N：『我們希望估計能準確，但卻一直不準』
• V：『不準的原因是？』
• N：『Android, iOS, Backend, PM 專業不一樣，很難理解對方正在做的細節，當事人也不想學對方的專業，造成估計都只是亂估的。』
• V：『首先，估計比較合適的時機是衝刺精煉會議，團隊透過討論充分的了解需求的範圍，然後透過估計確認是否夠小、夠明確可以帶到下一個衝刺進行。』
• V：『其次估計的目的，不是為了準確，而是為了溝通理解、討論交流，讓不熟悉的夥伴了解還不知道的技術細節，幫助團隊產生共識，這是一種促進學習的手段。』
• V：『再者，估計準不準確不該成為團隊的壓力，而是一種對衝刺的自我期待，每日站會的訊息同步就該提早讓團隊了解有些工作項目可能無法在這次衝刺如期完成。』
• V：『因為我們團隊的組成包含了 Android, iOS, Web, Backend, Designer, PM，我期望大家對於需求本身有充分的討論與理解，至於估不估計就不是那麼重要。但是如果 Android 小組願意對技術細節進行估計，我也樂觀其成。我希望團隊對最優先的工作項目先討論，而不是一次將所有的工作項目都一次討論完，然後把所有的人花兩小時綁在同一個會議中。』
• V：『我個人的想法是 Story 層級可估可不估，但切成 Task 後可以刻意練習的估計預期工時一下，雖然下一次不一定會遇到相同的 task，但是估計的過程也是幫忙自己理解自己對 task 了解程度的一種方式。』

因此，我認爲

• 好的估計：充分理解需求的估計、自我期許的估計、團隊參與的估計、幫助跨職能的估計、允許模糊的估計、沒有外部壓力的估計。
• 不好的估計：沒意義的估計、造成壓力的估計、沒有參與感的估計、無法跨職能的估計、過度精準的估計、外部壓力強迫的估計。
• 有目的的估計：為了開發時程安排、為了幫助客戶了解風險、為了促進團隊溝通、為了充分理解需求達到共識、為了有效運用資源。

不估計的好與不好

• N：『所以你不喜歡估計，對吧？』
• V：『並不是，我不喜歡沒目的性的估計，也就是說估計只是一種形式上的作法，但是團隊彼此間對彼此的工作沒興趣，團隊間的功能也無法互相備援時，估計就是一種浪費。如果團隊成員願意透過估計來幫助了解，我就很贊成。』
• V：『我喜歡的方式是 #不估計，所謂的 #不估計，並不是完全不估計，而是盡可能將不清晰的需求釐清完整，把過大的需求切分到夠小，不僅僅讓工作項目能在一個衝刺內完成，如果可以讓工作項目小到可以在每天都能 Commit 到測試環境，就是夠小的工作項目。』
• V：『我相信團隊的成員對工作都是全力以赴的，如果估計後某一個工作項目需要開發五天，我相信就算不估計開發時程也是依然是五天。何必要浪費兩小時進行估計呢？除非不估計需要五天，但估計後可以減少到四天，但這問題並不是估計不估計啊？而是對需求沒有充分理解或者對本身的專業技能或技術細節的不熟悉啊！』
• V：『我也不建議一直有估計的團隊，聽到了 #NoEstimates 就啟動了不估計。如果估計是有價值的，就不該輕易放棄。反之，如果不估計對團隊也沒什麼不好，不仿嘗試一下吧！每個團隊的成熟度不盡相同，每個團隊對估計想獲得的價值也不一定相同，找到適合自己團隊的做法可能比較重要。』

因此，我認爲

• 好的不估計：信任團隊的產能、不為衝刺速度而計算產能、盡可能以產出價值優先，從來沒做過的工作，限時的技術調研。
• 不好的不估計：反正估不準就不估計、不想給壓力的不估計、跟風的不估計，相同的工作已經進行多次還是無法估計。
• 有目的的不估計：讓模糊變清晰，讓大事變小事，讓不理解變有共識。

估計與不估計怪味道的七八點

1. 估計了！就不該發生變化：雖然估計不一定準確，但是已經說出口的估計，就不該產生變化。
2. 估計了！就不該違反承諾： 雖然估計不是為了承諾，但是很多人卻認為有估計，不管如何就一定要遵守承諾，加班也要完成。
3. 估計了！就不該未知調研：雖然估計不是只估已知需求，就算是未知的需求也一定要進行估計。
4. 估計了！就不該團隊分工：由於團隊屬性不一定是跨職能，為了估計，要求設計團隊與開發團隊一起估計，後端團隊與行動裝置團隊一起估計。
5. 不估計！就不會有時程安排：因為不估計，不管期限的開發也可以？
6. 不估計！就不會有衝刺期限：因為不估計，就算經歷多次衝刺也可以？
7. 不估計！就不會有團隊承諾：因為不估計，不用完成團隊承諾也可以？
8. 不估計！就不會有定期回報：因為不估計，不用定期回報進度也可以？

 Scrum之時間限制

在 Scrum 的架構下，所有的活動都是有時間限制的（timeboxed），又稱為『時間盒』。所謂『時間盒』就是對某一特定事件或活動給定一段『固定長度』的時間片段。
以下是 Scrum 中長度為 1 週的衝刺（Sprint）所應對的『時間盒』設計

• 衝刺計畫會議（Sprint Planning）：所佔的部分不超過 2 小時／週。
• 每日站立會議（Daily Scrum）：無論 Sprint 長度皆不超過 15 分鐘／天。
• 衝刺精煉會議（Sprint Refinement）：所佔的部分不超過 1 小時／週。
• 衝刺檢視會議（Sprint Review）：所佔的部分不超過 1 小時／週。
• 衝刺回顧會議（Sprint Retrospective）：所佔的部分不超過 1 小時 / 週。

時間限制（Timebox）的好處

• 價值先決（Priority）：時間內進行的事項皆需要有『價值高低排序，優先級高價值高』。
• 強調聚焦（Focus）：讓在時間限制下聚焦在『最重要』的事。
• 預設停損（Stop Loss）：讓事情在時間原則下能有『停損點』。
• 練習節奏（Rhythm）：讓時間限制可以養成一定的『節奏感』。

時間限制（Timebox）的壞處

• 半成品：並不是所有的工作皆能在時間內完成。時間限制下會造成『半成品』。
• 未發言：討論不一定充分，有些人、有些事可能『無法發言』。
• 不精準：可能事情很快被討論完或討論不完，時間預估可能『不準』。

時間限制（Timebox）的彈性

• 『時間快到』該如何？我習慣是事先會說明『時間的限制』，讓大家有所準備，更能聚焦。另外如果大家說還沒討論完，我會再問『需要再花多少時間？』有共識才有下一步，沒共識還不如提早說再見。
• 『時間有剩』該如何？我習慣會再問問，是不是有需要再花時間討論的事。有則把時間花在值得討論的事項上，沒有其他事需要利用這個時間，則散會休息。
• 『時間重要』還是『事情重要』？你的答案呢？我的答案會是『價值優先』，某一件事需要花更多時間又能產出很高的價值的話，投資就值得。但大部分的 case 你會發現花再多時間還不如早點休息。
• 『要事先決』（Put the first thing first），千萬不要利用一堆零碎時間做一些鳥事，時間是用在『有價值』的事。如果是一堆鳥事，就保留體力去休息吧！

Scrum的驗收條件

 驗收條件

前兩篇聊到了『完成的定義』與『使用者故事』，其實只是為了講解『驗收條件』（Acceptance Criteria）打底。一個工作項目是否達到客戶對需求的期待？答案就是足『通過』所有驗收條件才算是真正的產生價值。

完成的定義關注的點是『衝刺』中對所有『工作項目』／『使用者故事』的基本要求，而『驗收條件』則是對『工作項目』／『使用者故事』的需求細節進行逐一驗證。一個工作項目是否能如質如期的完成，最重要的一部分就取決於開工前是否有明確的『驗收條件』。

驗收條件的目的

• 描述明確的需求範圍：透過驗收條件的討論，讓團隊了解產品負責人與利益關係人對這個需求的期待，也能讓團隊更明確的了解這個需求的範圍，也方便估計時程與測試涵蓋範圍。
• 描述錯誤的案例處理：透過驗收條件條例出現有需求可以會遇到的限制與錯誤處理方式，開發過程完成期待中的需求比較沒問題，大多數遺漏的部分都是『錯誤／例外處理』。
• 增加共識的討論模式：透過驗收條件的討論，產品負責人與開發團隊，一次又一次的理解需求的目的，確保對需求有相同的了解，才能在最後的展示階段完整的呈現結果。
• 提早列舉出測試案例：驗收條件也是讓測試人員、產品負責人對開發團隊說明之後將進行的測試案例的過程，才不會發生開發團隊做的東西都沒被測試到，需要測試的部分都沒被完整開發。
• 時程工期的有效估計：透過驗收條件討論之後才能更明確的瞭解需求與測試範圍，開發團隊才能對這個需求有更有信心的估計，無論是時間、人力的絕對估計或是點數、大小的相對估計。

驗收條件的寫法

常見驗收條件的寫法有下列幾種

情境式寫法（Scenario-based）

『情境式寫法』的結構包含了五個元素：

1. 情境（Scenario）：描述這個驗收條件的情境
2. 假定（Given）：描述這個驗收條件的預先設定的條件
3. 當（When）：描述這個驗收條件在什麼情況下
4. 然後（Then）：描述這個驗收條件預期會發生的結果
5. 而且（And）：描述這個驗收條件預期會發生的更多結果

舉例來說：

• 『情境』是使用者帳號登入
• 『假定』使用者開啟帳號登入頁面
• 『當』使用者存在的帳號、錯誤的密碼時
• 『然後』登入頁面會秀出提示訊息『密碼錯誤』
• 『而且』登入頁面也會呈現『忘記密碼』的連結

規則式寫法（Rule-based）

所謂的『規則式寫法』是用條列式的方式列出所以需要驗證的測試案例
『測試案例』是使用者帳號登入，驗證規則如下：

1. 使用者輸入正確的帳號、密碼時，可以登入帳號頁面查看帳號資訊。
2. 使用者輸入存在的帳號、但錯誤密碼時，需要秀出提示訊息『密碼錯誤』
3. 使用者輸入不存在的帳號時，需要秀出提示訊息『不存在的帳號』
4. 使用者輸入錯誤的密碼超過三次時，需要秀出提示訊息『密碼已錯誤三次，需要重設密碼（附連結）』

客戶習慣的寫法（Customer-based）

有些客戶可能會用流程圖的方式、心智圖、檢核表的方式寫完成驗收條件，但寫法不是重點，能清楚呈現『驗收條件』的就是好方法。

驗收條件怪味道的七八點

1. 完成後才寫驗收條件：工作項目完成後才進行驗收條件的討論。
2. 鉅細靡遺的驗收條件：驗收條件太過仔細，單一功能就有不同組合的測試。
3. 超出範圍的驗收條件：驗收條件太廣已經超過本次要進行的範圍。
4. 技術細節的驗收條件：驗收條件的不是使用者看到的情境，而是底層的技術細節。
5. 沒有共識的驗收條件：團隊對驗收條件還沒有共識就開工。
6. 無法獨立的驗收條件：這個驗收條件需要其他驗收條件的配合才能進行測試。
7. 充滿變數的驗收條件：測試的條件是充滿變數的，無法模擬的。
8. 單向定義的驗收條件：只由測試人員或產品負責人設計出的驗收條件，開發團隊都事前不知情。

Scrum 完成的定義

 

Scrum 完成的定義

完成的定義

『完成的定義』是開發團隊與產品負責人的一種共識，對產品的品質與完成程度的一種檢核標準（Checklist），在每個『衝刺週期』中對『衝刺內的故事』，除了『驗收條件』外的最低要求，我認為完成定義是對產品上線最低門檻，如果產品無法通過『完成的定義』的檢核就不應該上線。

在 Scrum Guide 中的定義

當一個產品待辦工作事項或者產品增量被描述為「完成」時，每個人都必須了解什麼是「完成」之定義。 雖然這會隨著 Scrum 團隊的不同而有很大的差異，但成員們必須對什麼叫做工作完 成有共識，如此才能確保透明性。 這就是 Scrum 團隊對「完成」之定義，並且用它來評估產品增量上的工作是否完成。
同樣的定義用來指導開發團隊，讓團隊知道在衝刺計劃會議中可以選擇多少產品待辦事 項。 每一個短衝的目的是交付潛在可發佈的功能增量，而這些功能符合 Scrum 團隊目前對 「完成」之定義。
開發團隊在每個衝刺交付產品功能的增量。 這個增量是可用的，因此產品負責人可以選擇立即發佈它。 如果「完成」之定義對增量來說是開發組織的慣例、標準或指導方針的一部分，那麼所有的 Scrum 團隊都必須要遵守。
如果增量的「完成」不是開發組織的慣例，那麼開發團隊就必須對這個產品訂下一個合適 的「完成」之定義。。如果有多個 Scrum 團隊在同一個系統或產品發佈上工作，那麼所有 的開發團隊就必須一起訂下一致的「完成」之定義。
每個增量都是遞加於先前的增量，並經過徹底地測試以確保所有增量都能一起運作。 隨著 Scrum 團隊的成熟，可以被預期的是，他們對「完成」之定義將擴大到包含更多更嚴 謹的標準以達到更高的品質。當使用了新的定義，可能會發現一些之前已「完成」的增量 需要更多的工作。 任何一個產品或系統都應該有一個「完成」之定義，作為工作的標準。

完成的定義的程度

每個團隊（產品負責人及開發團隊）在不同的時期，對『完成的定義』會有不同的詮釋，也因此『完成的定義』是『因時制宜』，而不是『一成不變』。
任何事情在不同人的心中或許有不同的『完成的定義』，但對於團隊來說有一致的『完成的定義』是非常重要的。

有做、做完、做對、做好、做極致

其實每一件事，我們都可以在開始前評估一下，這件事我們想像中的『完成』的程度，舉例來說：老師指派了十道數學題給學生練習。
『有做』的同學只是把答案隨便填上，不管懂不懂題目或有沒有做完。
『做完』的同學會把題目看完也確認過，但不保證計算過程是否正確。
『做對』的同學的想法是把題目看懂也對過答案，確認答案是否正確。
『做好』的同學的想法是把練習做完後，也努力去理解相似的題型，並把錯誤的題目訂正。
『做極致』的同學的想法是除了把老師給的題目練習完，還會找一些新的題目練習，再次的確認是否真正理解，下次遇到類似的題型是否都能計算正確。甚至花時間去教不會的同學。
因為團隊的成熟程度不同，初期對『完成的定義』可以求有『做完』或『最對』，但隨著一次又一次的迭代，團隊越來越精進，就可以調整『完成的定義』到『做好』，最後達到『做極致』的地步。

Scrum的產物 User Story使用者故事

 

Scrum 使用者故事

使用者故事（User Story）是敏捷方法中用來描述需求的一個方式，而確認一個使用者故事是否『完成』（Done）則是需要『驗收條件』（Acceptance Criteria）來輔助。

使用者故事（User Story）

在敏捷方法中常用的『使用者故事』（User Story），包含了幾個元素

• 使用這個服務的人，稱之為『角色』（Role），使用的語句為『身為一位⋯⋯』（As a ⋯⋯）。這一部分描述的重點是『誰』（Who）。
• 這個人要用這個服務完成什麼事，稱之為『描述』（Description）或『行動』（Action），使用的語句為『我想要⋯⋯』（I want to ⋯⋯）。這一部分描述的重點是『做什麼事』（What）。
• 為什麼這個使用者需要這個服務，稱之為『目標』（Goal）或『商業價值』（Business Value），使用的語句為『因此我可以得到⋯⋯』（So that ⋯⋯）。這一部分描述的重點是『為什麼做』（Why）。

好故事的條件

一個好的故事具備了幾個條件，分別是 V.I.N.C.E。

• 有價值（Valuable）：故事最重要的一個部分是故事描述的『商業價值』，可以很清楚地讓團隊知道正在進行的工作是對『用戶』是有價值的，了解為何而戰，才能更有動力。
• 可獨立（Independable）：所謂的『可獨立』是指使用者故事和使用者故事間應該儘量避免相互依賴。傳統需求描述方式由於描述的事件較大，彼此間的依賴過多，導致在開發階段時互相牽制，造成開發時程的延宕。獨立性較高的使用者故事比較容易能夠獨立交付。
• 可協調（Negotiable）：使用者故事的「可協調」是指團隊對這個使用者故事的理解是透過不斷的對話、協商後慢慢達成一致的共識，進而開始開發階段，而不是產品負責人說了算的。曾經在奧美廣告的會議室看到了『對話、對話、不斷對話；優化、優化、不斷優化』，這句話的深層涵義是『持續的對話才能讓產品持續的優化』。
• 可驗證（Checkable）：所有的需求都是需要可以被驗證的，因此一個使用者故事，不只是故事的句子，還需要有相關的驗收條件可以驗證核對。
• 可估計（Estimable）：如果一個需求是不可被估計的，一則表示這個使用者故事太大，一則表示這個使用者故事太過模糊。太大的故事需要被切小，簡單來說就是分階段完成，太模糊的故事需要時間釐清需求。

 Scrum之開發團隊Develop Team

開發團隊的定義

在 Scrum Guide 中的定義：『開發團隊』（Development Team）是由一群據有專業技能的人所組成，他們的工作在於在每個『衝刺』（Sprint）結束時需要完成『潛在可發佈的產品增量』（Potential Releasable Product Incremental）。『完成』的產品是指能在『衝刺檢視會議』中完成呈現的工作項目。在 Scrum 唯一能為產品產生『增量』價值的只有『開發團隊』。

開發團隊做些什麼呢？

1. 自組織的團隊，不需要任何人（包含 Scrum Master）就可以拆分『產品待辦清單』中故事為『潛在可發佈功能的功能增量』（Increments of potentially releasable functionality）。
2. 能達到『產品增量』（product increment）中所要所有專業技能的『跨職能團隊』（Cross-Functional Team）。
3. 開發團隊中的所有成員，不管負責的工作是什麼，都沒有職稱或只稱為開發者（Developer）。
4. 開發團隊中不會依照特殊專長而成立小團體，例如：測試、架構、營運、商業分析。
5. 開發團隊中的成員或許有特殊專長或專精領域，但責任是全體開發團隊共同承擔。
6. 最佳開發團隊人數是 5~9 人（7±2 or 6±3），我個人最喜歡的團隊大小是 6 位（5~7）。

開發團隊怪味道的七八點

1. 開發團隊中每個人各自有各自的任務，彼此無法支援。
2. 開發團隊中維持一棒接一棒的『迷你瀑布開發流程』。
3. 開發團隊中是單一功能型團隊（Component Team），需要等待外部工作完成才能進行。
4. 開發團隊中人員是『任務導向』，每次衝刺都不一定一樣。
5. 開發團隊沒有人願意測試或只依靠某些人測試。
6. 開發團隊對『當次衝刺』的工作項目範圍不理解。
7. 開發團隊對『當次衝刺』的『衝刺目標』（Sprint Goal）不清楚。
8. 開發團隊對『當次衝刺』的工作項目無法給承諾（Commitment）、給過高或過低的承諾。

Scrum之Scrum主持人Scrum Master

 Scrum Master

Scrum Master 的定義

在 Scrum Guide 中的定義：Scrum Master 按照 Scrum Guide 中的說明，指導團隊，讓團隊中每個人了解 Scrum 的理論、實務、規則及價值觀，並推廣及支援 Scrum。如果用一個貼切的職稱來說明 Scrum Master，Scrum Master 比較像是部隊中的輔導長或是學校內的輔導老師，也有一說是『僕人式領導』（servant-leader），協助產品負責人及團隊產出最大價值。

Scrum Master 做些什麼呢？

協助 Product Owner

1. 確保 Scrum Team 每位成員都盡可能的理解目標、範圍與產品方向（Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible）
2. 找出有效管理產品待辦清單的方法（Finding techniques for effective Product Backlog management）
3. 協助團隊了解為什麼需要清楚簡潔的產品待辦清單工作項目（Helping the Scrum Team understand the need for clear and concise Product Backlog items）
4. 從過去的經驗中學習了解產品規劃（Understanding product planning in an empirical environment）
5. 確保產品負責人知道如何讓產品待辦清單產生最大價值（Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value）
6. 理解與實踐敏捷（Understanding and practicing agility）
7. 在被要求或需要的時候，引導團隊 Scrum 活動

協助開發團隊

1. 教練開發團隊如何形成自組織及跨職能團隊（Coaching the Development Team in self-organization and cross-functionality）
2. 協助開發團隊創造高價值產品（Helping the Development Team to create high-value products）
3. 協助移除開發團隊在過程遇到的阻礙（Removing impediments to the Development Team’s progress）
4. 在被要求或需要的時候，引導團隊 Scrum 活動（Facilitating Scrum events as requested or needed）
5. 在組織還未能完全採用及理解 Scrum 時教練開發團隊（Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood）

協助組織

1. 帶領及教練組織如何導入 Scrum（Leading and coaching the organization in its Scrum adoption）
2. 規劃 Scrum 在組織內的實踐流程（Planning Scrum implementations within the organization）
3. 幫忙員工及利害關係人了解及制定 Scrum 及經驗主義的產品開發流程（Helping employees and stakeholders understand and enact Scrum and empirical product development）
4. 促進改變來增加 Scrum 團隊的產能（Causing change that increases the productivity of the Scrum Team）
5. 與其他 Scrum Master 來增加組織內 Scrum 應用的有效性（Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization）

Scrum Master 怪味道的七八點

1. 專職簿記（A Scribe）：在 Scrum 的所有會議中負責記錄？
2. 團隊秘書（A Secretary）：安排團隊 Scrum 活動的所有行程時間？
3. 敏捷警察（The Scrum Police）：嚴格執行 Scrum Guide 中描述的所有規則，團隊一違反就開出罰單？
4. 團隊老闆（The Team Boss）：負責評量考績、人事權、薪資調整？
5. 行政管理（The Admin）：負責將團隊的紀錄一一填寫到系統上？
6. 會議主席（The Chairman）：每日站立會議時，會議主席會站在前方聽團隊的報告？
7. 超級英雄（A Super Hero）：萬事通，有了超級英雄所有的疑難雜症都可以解決？
8. 咖啡櫃檯（The Coffee Clerk）：每天請團隊喝咖啡？

   Scrum Master 六個 DOs
   
   

   

   
   

   
   

   
   

 Scrum的產品負責人Product Owner

產品負責人的定義

在 Scrum Guide 中的定義：產品負責人（Product Owner）擔負起產品價值最佳化的任務，然而這個產品的產出過程中大都來自開發團隊（Development team）的執行。因此，產品負責人就像是一條戰艦的指揮官，決定方向，團隊協調出戰艦動力的最佳效能全速前進。

產品負責人做些什麼呢？

1. 清楚解釋『產品待辦清單』的工作項目（Clearly expressing Product Backlog items）
2. 針對產品的目標及使命，進行『產品待辦清單』的排序以取得最大價值（Ordering the items in the Product Backlog to best achieve goals and missions）
3. 協助開發團隊產出最佳產品價值（Optimizing the value of the work the Development Team performs）
4. 確保所有人能透過『產品待辦清單』即時了解產品的狀態、資訊透明度及清楚瞭解團隊接下來要做的事（Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next）
5. 確保開發團隊能充分了解『產品待辦清單工作項目』的需求。（Ensuring the Development Team understands items in the Product Backlog to the level needed.）

產品負責人怪味道的七八點

1. 常常找不到產品負責人：如果你們的產品負責人很忙常常找不到，團隊也無法即時同步資訊，所有的事都卡在產品負責人等他拍板決定。這感覺就怪怪的！！！
2. 產品負責人無法做決定：如果你們的產品負責人事情都無法決定，可能需要去找他老闆，或者對外部需求也無法解釋清楚。這感覺也是怪怪的！！！
3. 很多產品負責人大亂鬥：如果你們的產品負責人有很多位，多頭馬車，產品負責人 A 決定的方向產品負責人 B 過兩天就翻案。這感覺也是怪怪的！！！
4. 很多產品待辦清單組合：如果你們的產品負責人同時對同一個開發團隊有不同的產品待辦清單，常常需要切換不同產品或專案進行。這感覺也是怪怪的！！！
5. 沒有提供產品待辦清單：如果你們的產品負責人只能告訴團隊接下來的『衝刺』（Sprint）要做什麼？但無法給團隊短期、中期、長期的『產品路線圖』或『商業目標』。這感覺也是怪怪的！！！
6. 身兼多職 PO, SM 與開發：如果你們的產品負責人可能身兼 Scrum Master、可能身兼開發人員。這感覺也是怪怪的！！！
7. 衝刺計畫會議沒衝刺目標：如果你們的產品負責人對於每次的『衝刺計畫會議』都提不出『衝刺目標』或『為何而戰』。這感覺也是怪怪的！！！
8. 沒產品待辦清單精煉會議：如果你們的產品負責人沒參加『產品待辦清單精煉會議』，而是團隊在『衝刺計畫會議』當下才知道目標。這感覺也是怪怪的！！！

 敏捷管理Scrum 產出物

        在 Scrum Guide 中提到了 Scrum 有三種產出物（Artifacts），分別為『產品待辦清單』（Product Backlog）、『衝刺待辦清單』（Sprint Backlog）、『產品增量』（Increment）。這三種產出物出現的時間分別在『衝刺前』需要從『產品待辦清單』挑出優先級高的工作項目、『衝刺中』需要透過『衝刺待辦清單』來完成『衝刺目標』（Sprint Goal）、『衝刺後』需要在『衝刺檢視會議』（Sprint Review Meeting）確認『產品增量』（Increment）是否完成。

產品待辦清單（Product Backlog）

決策總有目的性，不管終極目標是『商業價值』、『組織成長』還是『個人利益』，圍繞這個目標的相關做法就可以形成『產品路線圖』，在 Scrum 中稱之為『產品待辦清單』，這可能是三個月、半年，還是一年的計畫。

衝刺待辦清單（Sprint Backlog）

在『產品待辦清單』中具較高優先級的工作項目經過『產品精煉會議』對工作項目細節、流程、限制、範圍的討論後，就會進到該次『衝刺』要進行的『衝刺待辦清單』（Sprint Backlog）。

舉例說明，在『產品待辦清單』有一個工作項目是『提供會員集點』，首先會確認『會員集點』這需求明確了嗎？經過討論後，發現『會員集點』這工作項目太大了，需要拆分為『集點規則』、『查詢集點』、『兌換集點』三個工作項目。重新排定優先後，確認這次『衝刺』要先進行『集點規則』實作，哪些行為可以集點，哪些身份可以集點，後端需要實作資料庫與 API，前端需要在會員頁面呈現，進行相關行為時會跳出提示訊息，每天最多可以集點上限。

討論完成後，在『衝刺計畫會議』（Sprint Planning Meeting）中團隊也確認這個工作項目會在當下的『衝刺』（Sprint）進行。可進行的標準包含了細節是否夠明確、開發時間是否足夠、相關資源是否完整，也就是『準備就緒』（Definition of Ready），然後才會進到『產品待辦清單』中。

產品增量（Increment）

簡單來說『產品增量』（Product Increment）就是在『衝刺』（Sprint）中完成的『衝刺待辦清單工作項目』（Sprint Backlog Items），這些工作項目可能在『衝刺檢視會議』（Sprint Review Meeting）中發現有些『已經完成』（Done）、有些『還在進行中』（In-Progress）、有些『尚未開始』（To Do）。而『產品增量』的定義是指這些工作項目中『產品負責人』與『開發團隊』一起驗證滿足『驗收條件』（Acceptance Criteria）與『完成的定義』（Definition of Done）的『已完成』可以產生產品價值的部分。

 敏捷管理Scrum 產品待辦清單

Scrum 活動中，第一個先產出的東西是什麼呢？就我的看法，那應該是『產品待辦清單』（Product Backlog），一般來說又稱為是『產品路線
圖』 （Product Roadmap）。

不管組織中是『專案經理』（Project Manager）、『產品經理』（Product Manager）、『產品負責人』（Product Owner）或者是『河馬決策（HIPPO; Highest Paid Person’s Opinion, Highest Paid Person in the Office）。決策總有目的性，不管終極目標是『商業價值』、『組織成長』還是『個人利益』，圍繞這個目標的相關做法就可以形成『產品路線圖』，在 Scrum 中稱之為『產品待辦清單』，這可能是三個月、半年，還是一年的計畫。

產品待辦清單的組成

很多人認為『產品待辦清單』就是一堆『使用者故事』（User Story），其實不然，『使用者故事』只是一種呈現的方式。產品待辦清單上的工作項目，只要能清楚傳遞出想要交付給利益關係人（Stakeholder）的價值，也能讓團隊進行溝通討論就是一個清楚的產品工作待辦項目（Product Backlog Item; PBI）。

產生『產品待辦清單』或『產品路線圖』有很多種，但這不在本篇要討論的範圍，下次有機會再聊，這裡想談的是如何才是好的『產品待辦清單』。根據 Scrum Primer 的說明，我覺得會比較容易理解。

合適的細節 (Detailed Appropriately)

在『產品待辦清單』上方的工作項目，也是優先級比較高的的工作項目。因為優先級比較高，所以對工作項目的描述會需要更為精確與詳細。同樣的，因為『產品待辦清單』上方的工作項目優先級比較高，通常也表示需要先被開發。

實際上的做法是

1. 『近光燈』：最近一兩個『衝刺』（Sprint）就會進行的工作項目，需要多一點細節，比如說：設計原型、流程規劃、驗收條件、測試案例、錯誤處理、使用限制⋯等。在『近光燈』的工作項目，通常是經過『產品待辦清單精煉會議』（Product Backlog Refinement）的討論，也是之後可以排入 Sprint 進行的工作項目。
2. 『遠光燈』：可能是近一兩個月才會進行的項目，細節稍微少一點，比如說：客戶需求簡單的描述、一個初步的設計。在『遠光燈』的工作項目，通常也是還未經過『產品待辦清單精煉會議』（Product Backlog Refinement）討論的工作項目。
3. 『里程碑』：可能是半年後才會進行的項目，不需要細節，而是簡單的說明，比如說：『整合 IAB/IAP』、『提供會員集點』、『首頁個人化改版』、『收藏分類』⋯等。在『里程碑』的工作項目，通常也表示變數很大，可能只是個長期的目標。

可不可以只要『近光燈』不要『遠光燈』與『里程碑』呢？可以，只是會死很快。連未來想達到什麼目標的團隊，就是沒有方向的團隊，你覺得做出來的東西會有持續性嗎？專注在遠方的目標，聚焦在當下，持續調整才能走得遠走得久！

討論與評估 (Estimated)

所有要進入當前『衝刺』（Sprint）的『產品待辦工作項目』（Product Backlog Item），都是經過討論與估算的。團隊在『產品待辦清單精煉會議』中，對『產品負責人』拿出的高優先級『產品待辦工作項目』進行細節討論、時程估算（點數或時數）與風險評估。產品負責人在拿出『產品待辦工作項目』時，需要跟團隊說明這個工作項目的商業價值與相關利害關係人所提供的資訊，讓團隊充分了解『優先級與價值』的關連性。

不斷的生成 (Emergent)

『產品待辦清單』並不是第一天決定好就不會改變，過程中需要定期的梳理。每個『衝刺』（Sprint），除了拿出可以進入到該『衝刺』（Sprint）可能進行實作的工作項目外，還可能會加入、刪除、修改、分解或者調整『產品待辦清單』中工作事項的優先級別，以反應客戶需求與市場的變化。

有可能過程中有了新的想法或見解，有可能發現競爭對手的策略而導致的變化、有可能出現一些的技術的限制等。

優先級排序 (Prioritized)

在『產品待辦清單』最上方的工作項目表示具有最高優先級。一般來說，具有最高優先級的工作事項表示，它會產生最高的商業價值或重要性高於其他工作項目。因此，如果發現某在『產品待辦清單』上的工作事項，其商業價值比較高，或急迫性比較高，就得提高其優先級，並且盡早完成它，以取得產品的最佳利益。

 Scrum 五大價值

Scrum Guide 在 2016 的修訂版中加入了 Scrum 價值這個段落。有些時候，我覺得這五大價值能帶給團隊的改變甚至可能大於 Scrum 五大會議（計畫會議、產品精煉會議、每日站會、檢視會議與回顧會議）。

Scrum Values
When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone. The Scrum Team members learn and explore those values as they work with the Scrum events, roles and artifacts.

在『Updates to the Scrum Guide: The 5 Scrum values take center stage』中提到了這個五個價值的誤區，可以讓大家反思一下。

開放（Openness）
Scrum 團隊與利害關係人同意在所有工作中與工作上的挑戰保持開放的心態（The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work）。

所謂的『開放』是『告訴所有人你在做什麼？』還是『主動跟團隊提出你現在遭遇的挑戰與面臨到阻礙你成功的問題！』『There’s value in the Scrum Values』一文中提到了，開放不該是將所有事情讓說給所有人都知道，而是『對工作、流程、學習、問題與阻礙保持開放的態度，運用 Scrum 的經驗主義檢視現狀，做出最適當的調整』。

尊重（Respect）
Scrum 團隊成員互相尊重對方是有能力、獨立的人（Scrum Team members respect each other to be capable, independent people）。

所謂的『尊重』是『因為你幫忙了團隊被尊重為英雄？』還是『幫助團隊學習你在行的事，而且不評斷其他人不在行的事！』『There’s value in the Scrum Values』一文中提到了，尊重不該是尊重贊助商打造一個無人使用的產品，而是『尊重每個人個經驗、背景、技能、專業與意見讓團隊打造出產品的最終價值』。

勇氣（Courage）
Scrum 團隊成員具備勇氣做對的事情及處理艱難的問題（The Scrum Team members have courage to do the right thing and work on tough problems.）。

所謂的『勇氣』是『即使已經做決定後能有勇氣持續推遲？』還是『保持透明，既使發現自己的錯誤或自己的意見與團隊的方向不一致時能有勇氣改變！』『There’s value in the Scrum Values』一文中提到了，勇氣不該於讓未完成的功能上線或打造一個無人使用的產品，而是『有勇氣分享能幫助團隊與產品的資訊，有勇氣承認沒有人是完美的，有勇氣為團隊價值做出改變』。

專注（Focus）
每個人專注在衝刺（Sprint）的工作和 Scrum團隊的目標上（Everyone focuses on the work of the Sprint and the goals of the Scrum Team.）。

所謂的『專注』是『專注讓客戶滿意？』還是『專注在衝刺與衝刺的目標！』『There’s value in the Scrum Values』一文中提到了，專注不該是一直看未來可能會變重要的事，如：YAGNI（You Ain’t Gonna Need It），而是『專注在現階段最重要的事，專注在現階段的學習，並讓事情完成』。產品開發過程中存在了很多不確定性，也許有些事，未來可能很重要，但也可能變得不重要，如果無法做出準確的預測，何不先專注於現況呢？

承諾（Commitment）
成員個人承諾會達成 Scrum 團隊的目標（People personally commit to achieving the goals of the Scrum Team.）。

所謂的『承諾』是『承諾一些老闆要你做但你不了解的事？』還是『承諾在團隊學習與衝刺目標上！』『There’s value in the Scrum Values』一文中提到了，承諾不該是一種硬性的合約規範，而是『承諾是一種奉獻，是一種行動，是一種努力，而不是一種最終的結果』（commitment is about dedication and applies to the actions, the effort, not the final result.）。產品開發過程中存在了很多不確定性，過程的透明度能幫助團隊了解狀態，因此團隊該承諾的是會盡全力維持品質、協作與價值，而非承諾加班完成所有工作。