將故事點填入 Task 的 remaining work 欄位，反映出每個人實際的工作量。

在 Sprint Planning 時，根據團隊速率 (Team Velocity)，整個團隊會規劃當前迭代 (Current Sprint) 的合理工作量。然而，我們如何確定每個人的工作量是否合理呢？

Azure DevOps 提供了一個稱為 Work Detail 的功能，能夠有效解決這個問題。

在 Sprint Planning 階段，開發人員會共同討論實作細節，並在每個 User Story 下建立相應的多個 Task。根據分工合作的情況，每個人會負責認領其中的 Task。

此外，開發人員還需在 Task 的「original estimate」欄位填入「預計完成的工時」。隨著任務的進展，他們會在「remaining work」欄位更新「剩餘的工作時數」。

詳細的 Work Detail 介紹可以參考 Azure DevOps 的官方文件。https://learn.microsoft.com/en-us/azure/devops/boards/sprints/adjust-work?view=azure-devops

然而，這種計算工作時數的方法並不普遍受到歡迎，在我過去輔導的團隊中，只有少數團隊持續使用，並認為其帶來實質幫助。對於大多數團隊而言，這種方式並不切實際，我觀察到主要有三個缺點：

1. 精準的完成時數可能使產品負責人 (PO) 和開發主管產生錯誤的認知，認為每個人必須在預定的時程內完成。
2. Task 必須在 Sprint Planning 時全部列舉出來。如果沒有，則無法保證這樣的規劃方式能確保每個人都承擔合理的工作量。
3. 我們在 Story 的估算中使用故事點作為單位，但在 Task 的估算中則採用時數，這對團隊而言帶來額外的認知與學習成本。

因此，一些專家提出其實無需在 Task 上做時數的估算，相反，我們應確保 Task 的顆粒度足夠小，例如，一個 Task 應該能在一天內完成。若能採用此類細分方式，則在 Task 上進行估算似乎就不再那麼重要。

但是，上面的說法依舊無法完美的解決團隊遇到的兩個問題。第一個是開發主管希望了解每位團隊成員在當前迭代中的工作量是否合理；第二個是團隊成員不希望花費太多時間在估算上，尤其是填寫一些對於產品交付沒有太大幫助的資訊。

經過觀察多個團隊的運作方式後，我提出了以下這個機制，可以同時解決這兩個問題。

團隊仍然 Product Backlog Refinement 會議中，對於經過充分討論的 User Story，使用故事點做整體的估算。這個估算被視為初始的估算，提供給產品負責人關於待辦清單優先順序的參考。

然後，在Sprint Planning 會議中，團隊會根據團隊速率挑選合適的工作量，每位團隊成員根據認領到的 User Story 進行拆分，建立對應的 Task。此時，有兩種方式可以填入 Task 層級的估算。

第一種方法如上圖的上半部分所示，一個 User Story 由兩位團隊成員共同完成，Meredith有兩個 Task，Derek 有三個 Task。Meredith 根據她的兩個 Task，給出一個故事點作為整體的任務工作量；Derek 根據他的三個 Task，另外給出一個故事點作為整體的任務工作量。

第二種方法如上圖的下半部分所示，一個 User Story 被拆解為四個 Task，每位認領 Task 的團隊成員獨立給出估算。

上面兩種方式，我比較推薦第一種，比較簡單一些。當我們在 Task 層級估算完的總點數，如果有需要，也可以更新回 Story 層級的點數，當作第二次的估算值。

在 Azure DevOps 的設計中，我們可以通過設定 Column Option 來讓 remaining work欄 位在 Backlog 頁面顯示。在 User Story 的 remaining work 數值不需要手動填寫，系統會自動加總其下 Task 的 remaining work。

也許，對於一些熟悉 Azure DevOps 的人會認為，為什麼不利用 Task 的 effort欄位，在User Story 層級上通過 Sum of Effort 來加總 Task 的 effort 呢？主要是因為 Sum of Effort 欄位需要即時運算，其顯示速度較慢。

此外，這個方法也可以處理一個團隊經常面臨的問題，即當迭代結束時，未完成的 User Story 該如何處理。如果團隊傾向於將整個 User Story 移至下一個迭代以保持其完整性，例如，如果一個 User Story 的點數為 8，已完成 3 點，直接移到下一個迭代時，我們無法很容易地知道尚有多少點數的工作未完成。

在這種情況下，團隊成員可以調整 Task 中的 remaining work 來反映實際剩餘的工作量。

總結一下，如果想要利用故事點規劃團隊成員的合理工作量，可以以 Story 為單位，請一起合作的 Developer，各自挑選一張自己的 Task，在 remaining work 欄位中填入自己負責部分的整體任務工作量。

Scrum 系列：如何規劃團隊成員的合理工作量 was originally published in 德瑞克的敏捷咖啡 on Medium, where people are continuing the conversation by highlighting and responding to this story.

想要解決排序問題嗎？不妨試試 MoSCoW 排序法。

MoSCoW 優先級排序法是一種需求分析的方法，用於確定需求的優先級。該方法通常應用於軟體開發和專案管理領域，有助於確定在有限的資源和時間內應該實現的需求。

MoSCoW 是一個縮寫，代表以下四個級別的需求：

• Must Have (M) — 必須擁有： 這些需求是最重要的，沒有它們，專案將無法成功。如果無法滿足這些需求，則專案通常被認為是失敗的。
• Should Have (S) — 應該擁有： 這些需求不是致命的，但它們仍然相當重要。它們在可能情況下應該優先實現，但如果有限資源或時間，可以暫時推遲。
• Could Have © — 可以擁有： 這些需求是有價值的，但並不是關鍵的。它們通常是附加功能，可以在主要需求得到滿足後考慮實現。
• Won’t Have (W) — 不應擁有： 這些需求被明確排除在項目範圍之外，至少在當前版本中是如此。它們可能在未來版本中考慮。

我們可以直接使用 PBI 裡的 Priority 欄位，預設情況下為 1–4 的數值，可分別對應 MoSCoW 中的四個等級。

由於產品的需求會持續產生，因此，有兩種方式可以處理這些需求並進行優先級排序。

第一種方法是定期召開會議，將所有的需求統一進行優先級排序，這種方法能夠確保團隊對於所有需求的優先級都有清晰的了解。

第二種方式相對簡單，當收到需求時，直接將優先級設定為 ，如此，大部分的需求都會被標記為 2。如果新需求比大多數已標記為 2 的需求更為重要，則將其優先級設定為 1；反之，如果新需求比大多數已標記為 2 的需求不那麼重要，則將其優先級設定為 3。

下圖以 Azure DevOps 為範例，透過 Column Options 裡將 Priority 欄位顯示在 Order 欄位的右方。因此，我們可以用視覺化的方式，很快速地將產品待辦清單根據 MoSCoW 做排序。

MoSCoW 排序法有助於團隊清楚地了解各個需求的相對重要性，並協助在專案進行中做出適當的優先級和資源分配決策。這有助於確保在有限的時間和資源內實現最重要的功能，從而確保專案的成功。

如果你喜歡我的文章，歡迎「拍手」給我支持，或是「Follow」我，讓我提供更多的優質文章給你。

Scrum 系列：使用 MoSCoW 對產品待辦清單進行排序 was originally published in 德瑞克的敏捷咖啡 on Medium, where people are continuing the conversation by highlighting and responding to this story.

提高未來估算的精確性，使得團隊更可靠地預測交付時間。

在敏捷開發方法中，持續做估算是為了幫助團隊更好的規劃和管理工作，以確保專案能夠按時交付並符合品質要求。

有一天，團隊正在討論如何估算的更精準，對話如下：

同學Ａ：「我發現這個 PBI 原本估 5 點，但是做下去以後比較像 8 點。」

同學 B：「對啊，我覺得估算沒有用，反正都估不準，幹嘛要浪費時間做估算。」

同學 C：「先不管是不是很浪費時間，這個 PBI 到底需不需要改成 8 點呢？」

類似的對話是不是似曾相似，在回答問題之前，我們可能要先想想估算的本質。

我認為估算活動可以分成兩個階段，第一個是在 Sprint 開始前，第二個是在 Sprint 開始後，各自有不同的目的性。

在 Sprint 開始前做估算，提供 PO 關於尺寸的資訊

在 Sprint 開始之前，團隊通常會定期舉辦 Backlog Refinement 會議。在這個會議上，PO 會提出新的需求，並邀請團隊成員進行討論。當需求清晰度足夠時，團隊成員會在此時進行初步的估算。

或許有人會質疑，在尚未深入討論實作細節或分解子任務之前，進行這樣的估算是否有意義？實際上，是有其重要性的。

根據這部影片所示，PO 在排序決策上考慮了兩個主要因素，即價值（value）和尺寸（size），價值的資訊來自利益關係人，而尺寸的資訊則來自團隊內部。

因此，在 Backlog Refinement 會議上進行的估算僅是初步估算，屬於快速估算的一種方式。由於尚未深入討論實作細節，因此估算的準確性會受到一定程度的影響，這是正常的現象。

然而，在這個階段，估算的重點並不在於準確性，而是提供給 PO 有關尺寸的資訊。我們只需知道這個需求相對於其他需求的尺寸是否更大，以及大概有多大尺寸即可。這樣的資訊足以提供 PO 參考並調整需求的優先序。

例如，在下圖中間的區塊代表了最近幾個 Sprint 預計進行的 PBI，目前排在第 11 位的 PBI 估算尺寸為 20。對於 PO 來說，這個 PBI 的尺寸是否值得現在進行呢？或者是否可以晚點進行呢？又或者是該將這個大需求拆解成幾個小需求呢？

這些都是 PO 在評估優先順序時可能會思考的問題，這些資訊對於 PO 來說非常重要。

在 Sprint 開始後重新估算，提供 Team 關於統計的準確資訊

當 PBI 開始實作後，若發現其尺寸與原估計有所出入，是否需要重新估算以進行修正呢？

首先，讓我們思考一個問題：當團隊決定開始實作某個 PBI 時，其尺寸對於實作是否具有實際用途？在解決方案不變的情況下，PBI 的尺寸是否會影響所需的工作量？

我的答案是否定的。當團隊開始實作 PBI 時，尺寸的資訊就瞬間變得不重要，因為該 PBI 的工作量不會因尺寸估計偏大或偏小而改變。

因此，有些團隊選擇不重新估算，因為重新估算所帶來的價值有限。

然而，有些團隊認為還是需要重新估算。當 PBI 的估計尺寸和實際尺寸相差過大時，這可能導致統計上的不準確，例如團隊的速度（velocity）沒有反映出每個 Sprint 可以完成的實際點數，造成團隊高估或低估每個 Sprint 安排的工作量。

總的來說，重新估算 PBI 的尺寸可以使統計資料更加準確，但是否進行此舉仍然取決於團隊的需求和情況。

最後，實現準確的估算需要團隊不斷學習和改進。透過持續的估算，團隊能夠改進準確性，進而提高未來估算的精確性，使得團隊更可靠地預測交付時間。

如果你喜歡我的文章，歡迎「拍手」給我支持，或是「Follow」我，讓我提供更多的優質文章給你。

Scrum 系列：為什麼需要持續做估算？ was originally published in 德瑞克的敏捷咖啡 on Medium, where people are continuing the conversation by highlighting and responding to this story.

簡單步驟從複雜的 Team Velocity 圖表中提取關鍵信息

Scrum 中的 Team Velocity 是指團隊在一個 sprint 中完成的工作量，通常以完成 PBI 的總點數或數量來衡量。Team Velocity 可以幫助團隊預測未來 sprint 中能夠完成的工作量，這有助於規劃和預測發布日期，並促進持續改進。

有一天，一位朋友私訊我說：「我以前在使用 Jira 的 Team Velocity 時，只有 Commitment 和 Completed 兩個分類，非常清晰易懂。但現在在使用 Azure DevOps 的 Team Velocity 時，卻有四種分類，讓我感到很困惑，這到底是怎麼回事？」

我回答說：「第一次使用 Azure DevOps 的 Team Velocity 時，確實會讓你感到有些複雜。一旦你理解了圖表的設計原理，你就能更仔細地觀察團隊如何運用 sprint。」

因此，在本篇文章中，我們首先將一起了解圖表的四個主要分類；接著，透過進階的設定，幫助我們將 Team Velocity 圖表調整成更符合團隊 sprint 使用的方式；最後，我們將探討一些三個常見的壞味道。

圖表解讀

我們以 Azure DevOps 中的 Team Velocity 圖表為範例。如果沒有搭配相關的需求管理方法，這可能導致圖表失去意義。要使圖表具有解讀性，必須調整 sprint 的起始日期為 sprint planning 舉辦的日期，並將預計完成的 PBI 移至該 sprint 中。

從下圖中，可觀察到 sprint 1 到 sprint 7 的設置和管理並不恰當，導致圖表缺乏可解讀的數據。然而，在 sprint 8 之後，團隊正確使用 sprint 工具，使得圖表開始呈現出有意義的數據。

當數據呈現正確時，每個 PBI 會根據其所處的狀態被歸類為四種分類之一。下面對這四種分類進行解釋：

Planned（已規劃）

在 sprint 開始時，計算 sprint 中 PBI 的總點數，在 sprint 中以「淺藍色」呈現這些完成和未完成 PBI 的總點數。

Completed（已完成）

在 sprint 結束時，計算 sprint 中完成 PBI 的總點數，在 sprint 中以「深綠色」呈現這些完成 PBI 的總點數。

Completed Late（已完成但延遲）

在 sprint 中規劃要完成的 PBI，由於意外的原因造成這些 PBI 在未來的 sprint 中完成。如果這些 PBI在過程中沒有更新成未來的 sprint，在原來的 sprint 中會以「淺綠色」呈現這些完成 PBI 的總點數。

Incomplete（未完成）

在 sprint 中規劃要完成的 PBI，由於意外的原因造成這些 PBI 到目前為止都還沒完成。如果這些 PBI在過程中沒有更新成未來的 sprint，在原來的 sprint 中會以「深藍色」呈現這些未完成 PBI 的總點數。

進階設定

在 Team Velocity 圖表的進階設定中，可以做更多細膩的參數設定。

Velocity

當團隊有做估算時，我們會將點數記錄在 PBI 中的 Effort 欄位，因此，我們就可以設定成「Sum of Effort」；如果團隊沒有做估算，我們可以設定成「Count of work items」。

Number of iterations

為了要追蹤 Team Velocity 的長期趨勢與變化，可以將這個值設定成最大值。目前系統允許的最大值為 15，表示可以追蹤最近 15 個 sprint 的數據。

Display planned work for iterations

sprint planning 發生在 sprint 的第一天，但是偶爾會忘記把 PBI 放進 sprint，或是團隊成員臨時增加新的 PBI。

實務上，我們通常會把在第二天以前移動到 sprint 的 PBI 都視為已規劃 PBI。所以，我們可以把這個參數設定成 1，避免低估已規劃的工作量。

Highlight work completed late

在預設的情況下，無論多久以後完成的 PBI，都會在原本的 sprint 中歸類成 Completed Late。但是這樣的使用方式是不合理的，等於我們沒有在 sprint 結束時，認真思考未完成的 PBI 應該放回 Backlog 中還是移動到下個 sprint。

因此，通常我會設定成一個不會太大的數字。當此參數設定成 3，表示在 sprint 結束的三天內，都可以歸類到這個 sprint 的 Completed Late；如果超過三天才完成的 PBI，就不會計算到 Completed Late 中。

壞味道

Planned PBI 和 Completed PBI 差距太大

一個優秀的團隊通常具備較佳的規劃能力，能夠在 sprint 開始時合理預測團隊大約可以完成多少工作量。根據上圖中的 sprint 8 到 sprint 14 可以觀察到，每個 sprint 的 Planned PBI 總點數和 Completed PBI 總點數是接近的。

然而，在一個初期導入 Scrum 的團隊中，常常會發現 sprint 的 Planned PBI 總點數遠高於Completed PBI 總點數。這意味著團隊目前暫時無法準確估計自身能夠完成的工作量，因此高估了團隊可以實際完成的總點數。

一般會建議 Planned PBI 總點數和 Completed PBI 總點數差距在 20% 內，主要是因為在軟體開發的過程中會遇到一些不預期的情況，有時候規劃的 PBI 比較多，完成的 PBI 比較少；有時候規劃的 PBI 比較少，完成的 PBI 比較多。只要兩者大致上差不多即可。

每個 sprint 的 Completed PBI 總點數不穩定

一個優秀的團隊通常具備較穩定的交付能力，因此每個 sprint 的 Completed PBI 總點數都差不多，有時稍高，有時稍低，但波動不會過大。

在上圖中可以仔細觀察 sprint 8 到 sprint 14，會發現 Completed PBI 總點數大約在 60 到 80 之間，近三個 sprint 甚至略有增加。若細究，會發現 sprint 11 稍微下降，此時可利用圖表檢視團隊在該 sprint 中是否有任何問題需進一步改進。

若發現團隊每個 sprint 的 Completed PBI 總點數不穩定，波動極大，這是一個壞味道，表示團隊的工作模式不穩定，有大量改進的空間。

充斥許多的 Completed Late PBI 和 Incomplete PBI

如果在 Team Velocity 圖表中觀察到大量的 Completed Late PBI 和 Incomplete PBI，這顯示團隊未充分善用 sprint 這個工具。

舉例來說，若某個 PBI 在 sprint 8 被安排，但直到 sprint 10 才完成，圖表上的 sprint 8 將顯示出淺綠色的 Completed Late。然而，這樣的情況並不合理。假設現在時間是 sprint 10，通常我們會專注於檢視 sprint 10 的 taskboard，而不會特意返回 sprint 8 的 taskboard。因此，這個 PBI 很容易在我們團隊的視野中消失，成為一個被忽略的 PBI。

在觀察到此現象後，團隊在 sprint 8 和 sprint 9 進行調整，改變 sprint planning 的方式。在每次 sprint planning 開始時，團隊首先檢視前一個 sprint 未完成的 PBI 應該如何處理：是移到回 backlog 還是移到下一個 sprint。隨著團隊採取這種做法，可以發現在 sprint 10 之後，淺綠色的 Completed Late PBI 不再出現。

如果你喜歡我的文章，歡迎「拍手」給我支持，或是「Follow」我，讓我提供更多的優質文章給你。

Scrum 系列：如何才能正確理解與應用 Team Velocity 圖表？ was originally published in 德瑞克的敏捷咖啡 on Medium, where people are continuing the conversation by highlighting and responding to this story.

點數小的 PBI 移動到下個 Sprint，點數大的 PBI 拆成兩個 PBI

在 Scrum 框架中，Product Backlog Item (PBI) 是待完成的工作項目。團隊在 Sprint 開始的時候舉辦 Sprint Planning 會議，選取合理數量的 PBI 放入 Sprint Backlog 中。團隊在 Sprint 結束的時候，會盡全力完成這些已選取的 PBI。

有一天，一位朋友私訊我：「Current Sprint 內未完成的 PBI，會挪到下一個 Sprint，對吧？」

我回答：「以結果來說，的確大部分的團隊選擇把未完成的 PBI，直接搬到下一個 Sprint。」

這個問題表面上看似簡單，背後其實有一個思考的脈絡。以下是兩個主要的處理方法：

1. 放回 Product Backlog

當未完成 PBI 的優先序降低，或是有依賴性需要等其他團隊時，可以將 PBI 放回 Product Backlog 中適當的位置，成為 Future Sprint 的候選項目。這樣，團隊在未來的 Sprint Planning 時，可以重新評估、安排和選取這些項目。

2. 移動到 Next Sprint

經過審慎評估後，判斷未完成的 PBI 應該在 Next Sprint 中繼續進行時，可以將 PBI 移動到 Next Sprint。

通常，大家就會接著問這一題：「那我們應該要把整個 PBI 移動到 Next Sprint，還是把 PBI 拆成兩個項目，已完成的項目保留在 Current Sprint，未完成的項目保留在 Next Sprint 呢？」

在回答這個問題之前，我們需要從價值的角度來思考。

假設有一張未完成的 PBI，它的點數為 8。如果 PBI 已經是最小的工作單元，無法繼續拆分帶給使用者價值，那這個 PBI 不應該被拆分。

如果此 PBI 完成的部分是可以獨立交付帶給使用者價值，那我們可以把 PBI 拆解成兩個 PBI，例如，第一個是完成的 PBI 點數為 3，第二個是未完成的 PBI，點數為 5。

實務上即使你這麼做，還是會遇到問題的，最常見的問題是未完成的 PBI 點數為 8，它也是最小的工作單元，繼續做拆解也無法帶給使用者價值。如果我們遵守規則把整個 PBI 移動到下個 Sprint，計算選取此 PBI 的團隊成員身上所有的 PBI 大小加總在一起，會發現些許澎風的成分。

另外，有些團隊會追蹤 Velocity Chart，如果把點數 8 的 PBI 完整認列到 Next Sprit 的完成點數，對於長期的 Average Velocity 是沒有影響的。但是當我們關注到每個 Sprint 的產出時，就會發現 Current Sprint 比較低，因為沒有計算到已完成部分的點數，Next Sprint 會比較高，因為一次認列了全部的點數。

綜合理論和實務以後，我自己的準則是這樣的：當 PBI 點數在 5 以下時，直接把 PBI 往 Next Sprint 移動，減少拆兩張單子的作業時間；當點數在 5 以上時，可以將 PBI 拆解成兩張，分配合適的點數給它們，完成的項目放在 Current Sprint，未完成的項目放在 Next Sprint。

在 Azure DevOps 上，可以在 Marketplace 安裝「Split!」，可以讓拆 PBI 的這件事情變得非常簡單。

在指定的 PBI 的編輯選單中選擇 Split，會彈出小視窗，預設會自動帶出此 PBI 下未完成的任務，當你點擊右下方的藍色 Split 按鈕後，會新增一張同樣內容的 PBI 在下一個 Sprint，並且將未完成的任務從舊 PBI 移動到新 PBI 中。

最後，在處理未完成的 PBI 時，持續的透明度、快速的反饋、以及從過程中學習的文化是非常重要的。這有助於團隊不斷改進，提高未來 Sprint 的成功機會。

如果你喜歡我的文章，歡迎「拍手」給我支持，或是「Follow」我，讓我提供更多的優質文章給你。

Scrum 系列：Sprint 結束後，還沒完成的 PBI 應該怎麼處理？ was originally published in 德瑞克的敏捷咖啡 on Medium, where people are continuing the conversation by highlighting and responding to this story.

在團隊的工作流程中內建程式碼審查

在大多數的情況下，在產品團隊的工作流程中加入程式碼審查（PR Review）的機制，可以提升產品的品質，，並且促進知識的分享與團隊的合作。

前幾天剛好有一位朋友詢問：「你覺得在 Taskboard 上加上 PR Review 這個欄位的想法怎麼樣？」

我回答：「我覺得滿好的，是一個可行的方法，讓團隊的工作流程中內建 PR Review 的文化。」

Taskboard 在預設的設計中，通常有三個基本的欄位，包括 Todo、In Progress、Done。在 Sprint Planning Part 2 時，團隊會將 PBI 拆解成任務並且放在 Todo 欄位中。隨著 Sprint 開始，正在進行的任務會移動到 In Progress 欄位，當任務完成時會移動到 Done 欄位。

如果產品團隊中想要在工作流程中加入 PR Review 的機制，主要有兩種做法：

第一種方法是把 PR Review 當成是一個任務，所以在 PBI 下面新增一個 PR Review 的任務，並且把 Assignee 設定成替整個 PBI 做程式碼審查的團隊成員。例如在上圖中，PBI 是由 Derek 主要實作，紅色方框是 PR Review 任務，由 Meredith 做程式碼審查。

這種方法的優點是在 Sprint Planning 時，預先幫每個 PBI 下面都新增對應的 PR Review 任務，並且事先分配給團隊成員。因此，團隊成員在評估整個 Sprint 的工作量時，也會把程式碼審查工作納入考慮，避免沒有時間幫其他人做程式碼審查。

當然，這種方法也有一些缺點，容易忘記幫每個 PBI 新增對應的 PR Review 任務。另外，每次都要新增相同標題的任務單，重複的動作有些擾人。

第二種方法是在 Taskboard 新增 PR Review 欄位。當任務不需要做程式碼審查時，任務從 In Progress 跳過 PR Review 直接移動到 Done；當任務需要做程式碼審查時，任務從 In Progrss 移動到 PR Review，並且將任務的 Assignee 設定成預計做程式碼審查的成員。

這種方法的優點在不需要事先幫每個 PBI 新增對應的 PR Review 任務。另外，在工作流程中可視化 PR Review 狀態，讓進行中的 PBI 除了 In Progress 狀態之外多了一個更細部的狀態，幫助團隊更能掌握 PBI 的現狀。

總結來說，兩種方法各有優缺點，是否在 Taskboard 新增 PR Review 欄位，應該根據團隊的具體需求和情況進行評估，確保任何更改都能夠有效支持和提高團隊的工作效率。

如果你喜歡我的文章，歡迎「拍手」給我支持，或是「Follow」我，讓我提供更多的優質文章給你。

Scrum 系列：該不該在 Taskboard 新增 PR Review 欄位呢？ was originally published in 德瑞克的敏捷咖啡 on Medium, where people are continuing the conversation by highlighting and responding to this story.

從 David、女兒和狗一起散步來理解 Drum-buffer-rope

David Anderson 在《A Brief History of Kanban for Knowledge Work》文章中，描述看板方法演進的歷史。最早起源於 2004 年，David 協助微軟的 XIT 維運團隊的過程中漸漸發展出來。文章中有一小段文字引起我的興趣

The system implemented was inspired by Theory of Constraints Drum-Buffer-Rope and worked on the assumption that Test was the bottleneck.

曾經閱讀過 Goldratt 寫的《目標》這本書，對於「Theory of Constraints」（限制理論）不是太陌生，但是什麼是「Drum-Buffer-Rope」呢？這引發我的好奇心。

剛好在閱讀《Agile Project Management with Kanban》這本書，裡頭提到了這個概念，利用這篇文章將資料做些整理。

在進入 Drum-buffer-rope 之前，我們先理解「限制步驟」這件事情。

「限制步驟」對於系統的影響

需求從開始到完成的過程中，我們可以將工作流程分成多個步驟。每個步驟所需要的處理時間都不同，花費時間最長的步驟會大幅決定整個系統的產出，所以又被稱為「限制步驟」。

無論你選擇什麼方式提高限制，你都不會希望限制步驟花費更長的時間。限制步驟的某些變化是你無法控制的，但你可以控制其中的一些變化。特別是，你可以盡量避免大家經常犯的兩個錯誤：

• 不要讓限制步驟等待：由於系統的吞吐量完全取決於限制步驟，因此其他步驟要盡可能配合限制步驟，不應該讓限制步驟等待。
• 不要強迫限制步驟更快：實際上，能夠讓限制步驟更快當然非常好，但是強迫大家更快的工作通常會導致走捷徑、品質下降、重工等問題。這些問題都會進一步降低吞吐量，並增加同時進行的工作數量，這樣的方式與我們的目標相違背。

「Drum-buffer-rope」如何幫助「限制步驟」

Drum-buffer-rope 是限制理論（TOC）的一種應用，它可以避免上述的兩個錯誤，並確保所有步驟的節奏一致，以實現最佳反應時間。它有三個關鍵的概念：

• Drum：系統中花費時間最長的步驟。其他的步驟都要和 Drum 的節奏一致，以確保 Drum 始終在敲擊，永遠不會被淹沒，並且所有步驟都得到充分利用。
• Buffer：Buffer 可在 Drum 改變速度時預留額外的工作項目。我們無法避免變化，尤其是在產品開發方面，但是當有 Buffer 時，可確保你的 Drum 隨時都在敲擊。
• Rope：Rope 確保在系統中花費時間最短的步驟，能夠以 Drum 的同個速度進行。當有一條 Rope 時，可以確保你的 Drum 不會被工作塞滿，並且所有的步驟都得到充分利用。

以 David、女兒和狗一起散步為例子

在《Agile Project Management with Kanban》這本書提到，David 在他的部落格中提供了一張令人印象深刻的圖片，可以用來理解 Drum-buffer-rope，不過目前我沒有找到出處。

這個故事描述當 David 在遛狗的時候，他的小女兒喜歡一起參加。David 的狗比他的女兒體型大很多，所以移動的速度很快。但是，無論 David 和狗的速度如何變化，整個隊伍的移動速度都由 David 的女兒決定，因為她是這個系統中的限制步驟。

當 David 需要蹲下來收集狗的糞便時，他用繩子來跟蹤他的女兒。繩子足夠寬鬆時，這樣他的女兒就不需要放慢速度，可以持續前進。David 用狗鍊把狗拴住時，可以確保 David 和狗都不會離他的女兒距離太遠。如果狗身上沒有狗鍊的話，可能會讓這個系統變得混亂，節奏無法一致。

在這個系統中，David 的女兒是 Drum，David 和女兒之間的繩子是 Buffer，狗身上的狗鍊是 Rope。只要 David 和狗可以跟上他女兒的步伐，並且設置有一些緩衝 (buffer) 來應對變化，散步就會很愉快。

Drum-buffer-rope 主要應用在工廠的生產排程中，看板方法受到它的啟發，用來確保工作流程中的限制步驟，可以得到最大的利用。

Kanban 系列：Drum-Buffer-Rope 對於看板方法的啟發 was originally published in 德瑞克的敏捷咖啡 on Medium, where people are continuing the conversation by highlighting and responding to this story.

透過與作者文字交流的方式，獲得關於問題的啟發

對於看板方法在實務的應用，我心中一直有幾個問題沒有獲得適當的解答。當我在閱讀這本書的過程中，不斷透過文字與作者對話。與作者的對話過程中，我有一些啟發與想法。這篇文章主要分享五個困惑我的問題，以及作者對於這些問題的想法與答案。

如何設計合理的 WIP Limit?

在工作流程中的每個步驟設定 WIP Limit 是看板方法中很重要的一個實踐，但是如何設計合理的 WIP Limit 是我一直感到困惑的地方，在《Agile Project Management with Kanban》中，我找到了一些答案。

我們以這個團隊的工作流程為例子，每個工作項目都會經過三個階段，分別是 Specify、Implement、Validate。Specify 主要在做需求討論、系統分析與設計、將需求拆解成多個尺寸差不多大小的工作項目，由系統分析師（analyst）負責；Implement 主要為開發的工作，由開發人員（developer）負責；Validate 主要為驗證工作，由測試人員（tester）負責。

那我們要怎麼知道每個步驟的 WIP Limit 設定成多少是合適的呢？

根據過去團隊成員的完成需求的紀錄，我們得知以下這些資訊：

• 系統分析師 1 個月可以完成 6 個工作項目。
• 開發人員 1 個月可以完成 2 個工作項目。
• 測試人員 1 個月可以完成 3 個工作項目。

另外，整個工作流程最慢的步驟是 Implement，所以它是我們的瓶頸。因此，這個步驟的 throughput 就是整個看板系統的 throughput，我們可以圍繞著 Implement 步驟設計出合理的 WIP Limit。

如果團隊中有 3 位開發人員，所以一個月在開發階段可以完成 6 個需求 （2 x 3 = 6）。從這個 throught 為 6 反推，可以得知我們需要 1 位系統分析師 (6 / 6 = 1) 和 2 位測試人員 (6 / 3 = 2)。在最佳的情況下，三個步驟的 WIP Limit 依序為 1、3、2。

但是在實際的運作中，需求的尺寸稍微有些不同，工作的效率也會有些不同，我們希望可以最佳化運用開發人員，避免他們的工作提早做完，導致沒有新工作可以做的狀況。考量到這個變異性，我們將 WIP Limit 加大 50%，當作 WIP Limit 初始值。

有了這個初始值以後，當我們實際使用看板後，根據實際的情況，可以繼續針對 WIP Limit 做微調，找到最適合團隊的設定值。

什麼時候要將步驟拆分成 Doing 和 Done 呢？

設計看板的過程中，我們會根據工作流程切分成多個步驟，例如 Specify、Implement 和 Validate。那麼，每一個步驟需不需要進一步切分成 Doing 和 Done 兩個子步驟呢？

乍看之下，每個步驟都分成 Doing 和 Done 子步驟很浪費空間，讓整個看板的版面變得很大。但是實際上，這個切分的動作背後是有很深層的意義的。

我們先假設 Specify 是由系統分析師負責；Implement 是由開發人員負責；Validate 是由驗收人員負責。

在這樣的分工下，如果沒有 Done 子步驟存在，每個人完成工作後，無論下一個步驟是否可以承接更多的工作，我們會把當前步驟中的工作項目往下一個步驟移動。這樣的行為模式是典型的 Push 模式，跟看板系統想達到的 Pull 模式相違背。所以，當步驟與步驟之間，如果是由不同的人交接工作的話，可以在交接處設置一個緩衝區，避免變成 Push 模式。

下一個面對的問題是：如果 Implement 步驟中，Doing 子步驟中有 2 個工作項目，Done 子步驟中有 1 個工作項目。那麼，在 Implement 步驟中有幾個工作項目是需要計算到 WIP 呢？

因為 Done 子步驟屬於 Implement 步驟中，如果不計算在 WIP 中，那意味著我們可以堆積大量的工作項目在 Done 子步驟，等於破壞了看板系統的運作機制。因此，無論需求是停留在 Doing 或 Done 子步驟，一率都需要計算到 WIP 中。

最後，分成 Doing 和 Done 子步驟的好處是，可以在步驟的下方加入 Done Rule，也就是這個工作項目從 Doing 進入到 Done 需要滿足的完成條件。當我們明確設置 Done 子步驟，自然地提醒大家確認是否滿足 Done Rule。

所以，設置 Doing 和 Done 子步驟可以確保我們的系統是一種拉式系統。工作項目在拉動的過程中，唯有下游步驟有能力時，才能將工作項目往後移動。

什麼時候將需求拆解成工作項目呢？

團隊會從各種來源收集到許多不同的需求，有些需求的顆粒度比較大，那麼，看板可以怎麼設計，幫助我們有個明確的步驟把需求做切分呢？

步驟 Specify，有些團隊習慣稱為 Breakdown。在這個步驟中，系統分析師會針對這個需求做分析與設計，並且將顆粒度比較大的需求進行拆分，變成許多小的工作項目。

在第一張圖中，Specify 的 Doing 下面有一個需求，在 Done 下面有排成一列的四個工作項目。在第二張圖中，Specify 的 Doing 下面的需求被拆分了，變成在 Done 下面第二列的 3 個工作項目。

所以，我們很巧妙的把拆分這件事情融入到看板的 Specify 步驟中。

另外，可以注意 WIP 的設計，在 Specify 步驟中是計算「需求」的數量，在其他的步驟，例如 Implemet 和 Validate 步驟中是計算「工作項目」的數量。因此 WIP 的設計其實是可以很彈性的，根據實際的工作流程做調整。

在 Specify 步驟中將需求做拆分的概念在實體看板是很容易實現的，但是在數位看板中，例如 Jira、Azure DevOps，同一個看板中，都是要用同樣層級的工作項目表示。因此，要套用這個概念，可能需要搭配兩個上層和下層看板才能實現。

每個需求都要拆解成一樣大小的工作項目嗎？

在看板上流動的工作項目，是否大小都要一致呢？

我們先看反方陣營怎麼說，從使用者收集到的需求通常會有自然顆粒度，可以交付給使用者價值。如果為了追求把需求都拆解成一樣大小的工作項目，這些獨立的工作項目未必對使用者有價值。

接著我們看正方陣營怎麼說，從使用者收集到的需求通常顆粒度有大有小，如果這些需求不經過適當的切分，我們其實很難設計看板步驟上的 WIP，因為顆粒度大的也算一個，顆粒度小的也算一個。

那我自己怎麼想的呢？我認為需求都應該做適度的切分，讓每個需求都能夠在 1–2 個月內完成。

當我們將需求做初步拆解後，進入到看板的需求，依舊需要做進一步拆分，我們沒有強調每一個工作項目都要一樣的大小，只要他們的大小接近即可，例如每一個工作項目都可以在 1–5 天內完成。

拆解成同樣級距的工作項目時，對於看板的設計會更加簡單，比較容易可以推測每個步驟合理的 WIP Limit。

如果工作項目有依賴性必須要等待，該怎麼處理？

想像一個場景，工作項目正在實作中，但是因為依賴性，需要等待其他團隊的協助。那麼，這個工作項目是否要計算進 WIP 呢？

這個工作項目實際上是處於等待的狀態，如果為了符合 WIP Limit 的原則，會導致開發人員可能手上沒更多工作，也無法承接更多的新工作，導致看板在 Implement 步驟呈現阻塞的狀態。

在這個例子中，我們在 Implement 步驟下設置了 Track，當在 Doing 下的工作項目進入了等待狀態，通常是只要等待個三天五天，我們會主動把這個工作項目移動到 Track 下面。只要是在 Track 中面的工作項目不需要計算進 WIP。

放在 Track 下的另一個目的是，這些工作項目依舊在我們的追蹤雷達中，每天 daily standup 時可以拿出來關心一下狀況，看看是否有變化。如果依賴性消除以後，記得移動回 Doing 下面。

有時候，如果發現這個工作項目即使放到 Track 下面，短期內也不會有進展，我們可以設計一個區域稱為「Parking Lot」(停車場)，把這些會等待很久的工作項目放進停車場中，每幾個禮拜回頭檢視這些項目的狀態。

簡單來說，暫時進入等待的工作項目放進 Track 中，密切關注；較長時間會等待的項目放進 Parking Lot 中。

Agile Project Management with Kanban (Developer Best Practices)

如果你喜歡我的文章，歡迎「拍手」給我支持，或是「Follow」我，讓我提供更多的優質文章給你。

《Agile Project Management with Kanban》心得：關於五個看板常見問題的想法 was originally published in 德瑞克的敏捷咖啡 on Medium, where people are continuing the conversation by highlighting and responding to this story.

可視化價值流，實現端到端的流程改善

《Real-World Kanban》這本書收錄了四個使用看板的真實案例。我對於第二章的企業看板（Enterprise Kanban）案例特別有共鳴，因此將此章節的內容做了濃縮與整理。

公司背景

這間公司已經有 100 年的歷史，作為計算領域的早期先驅之一，該公司擁有沈重的技術包袱，超過 300 個在運作中的系統。這是一個很大的挑戰，因為該公司必須跟許多不具備技術包袱的新公司競爭。這些競爭的公司積極有效率，該公司必須提供效率並且讓產品現代化才能競爭。

如下圖所示，該公司的行銷部門有三個單位，每個團隊負責特定的細分市場。IT 部門也分成三個單位：開發、變更管理和維運。

該公司有員工 650 人，其中約 100 人參與新產品開發，所有員工都以某種方式直接或間接地受到 Kanban 影響。

那麼，該公司主要面臨的挑戰是什麼呢？它們需要更快的交付吸引顧客的現代化產品，以保持市場競爭力。

為什麼改變是必要的

該公司在初期採用敏捷取得了初步的成功，但是大型專案還是拖延了太長的時間。該公司剛剛中止一個早期的專案，該專案是為了更新產品平台，該專案已經逾期超過 18 個月，而且離完成還很遙遠。即時團隊敏捷也不代表公司也敏捷。

似乎沒有人知道正在開發的產品想法的確切狀態。這些想法存在於幾個 Scrum 團隊的產品待辦清單中。在某些情況下，這些想法處於不同的開發測試階段。

新增 Enterprise Kanban 來查看產品想法的真正進展就成了一個自然的步驟，這將使我們能夠了解產品想法目前處於哪個階段。讓我們來看看如何使用看板解決這個問題。

我們是如何開始

我們邀請相關的人員和團隊，並介紹了我們的發現和原因以及我們想要嘗試的四到五個改變。然後我們徵求回饋，看看他們可能會考慮嘗試哪些。

我們透過 thumb voting (拇指投票) 來收集大家的想法，thumb voting 是一種非常簡單的決策技術，可以幫助團隊立即採取行動。

• Thumb up 表示「我們來試試看。」
• Thumb to the side 表示「我不確定，但是我願意試試看。」
• Thumb down 表示「不可能，這太瘋狂了。」

經過大家的投票以後，我們提出的五項變更中有四項獲得了同意，我們就先從大家都認同的改變開始做嘗試。

建立 Kanban Board

我們必須先決定在看板上放什麼。因為每個部門都有自己習慣的做事方法，因此，我們決定僅在看板上包含產品想法和功能。產品想法代表具有客戶價值的事情，功能代表產品裡的功能改變。

當決定好看板上呈現的資訊後，我們將各團隊正在進行的產品想法，映射到看板上。至此，我們已經看到了看板的好處。我們可以更輕鬆的了解進行中的產品創意的數量和真實的開發狀態。

將看板放在哪裡是另一個重要的決定。這個看板將四個部門連結在一起：行銷、開發、變更管理和維運。最後決定將實體看板放在開發團隊所在的走廊位置，因為開發團隊會最常與這個看板互動。我們每週有兩次的站立會議，也可以確保其他部門的代表每週會看到兩次。

聚焦在 Flow，而不是 Sprint

看板就位以後，我們要求開發人員考慮「flow」，而不是不斷的運行「sprint」。這個措施會減少等待的時間，將會允許開發人員致力於完成產品想法，直到想法完成並達到正確的質量，而不是僅僅因為 sprint 已經到了最後一天。這意味著從「date-driven」轉換成「quality-driven」。

流程是如何運作的

為了讓流程有用，使用該流程的人員必須擁有所有權。因此，流程必須簡單。下圖顯示 Enterprise Kanban 的工作流程：

關於協同設計（Collaborative Design）

這個活動有三個主要目的：

1. 減少等待時間：通過多樣的思維方式來獲取多種觀點，有助於加速設計和決策過程。
2. 消除團隊成員中「小齒輪」的感覺：每個團隊都有一名成員參與，他會將對解決問題的過程與資訊帶回給團隊。
3. 獲得高度創意：我們避免將問題分解成將產品想法融入到現有架構的蹩腳練習，我們的目標是為任何問題提供兩種解決方案。

引導者通常由開發團隊裡的 SM 召開與主持會議。每個團隊都有一名開發人員參加會議，必要時還會有專家參與。會議期間，會針對產品想法做深入的發想與討論。

這個活動是希望有各種不同角度的意見，並鼓勵參與者學習彼此的想法。必要時，也可以嘗試讓各團隊的開發人員論流參加。

看板的設計

在這個案例裡 concept 是一個特殊的用語，我們暫時可以把 concept 當成是一個產品想法，這個想法會在看板上流動。

• Product Ideas：每個行銷單位負責在這裡準備兩個產品想法。
• Next：團隊接下來會進行的三個產品想法，這也是我們開始測量 lead time 的地方。行銷部門和開發部門的主管每 14 天會在看板前開會一次，審查接下來的優先產品想法。
• Ready for Dev：評估不同的解決方案，並瞭解哪些團隊將受到影響。正如同前面提到的協作設計會議中看到的那樣，每個團隊至少有一名成員參加了會議。
• Dev：產品想法在多個團隊中進入開發階段。在產品想法進入 System Test 之前，團隊和產品想法所有者必須驗證可用性與用途。
• System Test：從系統角度檢視產品想法是否能通過基本的驗證，例如可維護性、穩定性等等。
• Production：該 release 部署到生產環境。如果有必要，會設定對應的配置（configuration）。
• Acc. Test：產品想法所有者對最終的體驗做驗收。
• Ready to Use：準備好讓顧客使用。
• Customer Usage：這階段代表客戶的回饋。如果他們喜歡它並使用它，那麼它就被認為是 Popular； 如果沒有成功，就被認為是 Oh Crap！

確保每個行銷單位都得到公平的資源

每個行銷單位都專注於找到下一個最有可能在市場上取得成功的產品創意。單位負責人每 14 天看板前開會一次，審查優先事項。 這保證了透明度。

每個行銷單位都獲得同樣的開發資源 (各 1/3)。如果每個單位的負責人都認為某個產品想法或改進對公司更有價值，可以調整該規則。

開發團隊如何決定做什麼工作

關於開發團隊工作類型的比例，我們制定了簡單的規則：

• 50% 的工作以產品想法為導向，也就是來自於企業看板。
• 20% 的工作是關於改進（improvement）。
• 20% 的工作用於修復錯誤（bug fixing）。
• 10% 的工作用於快速修復、回答問題等。

如果以上這些資訊都呈現在「企業看板」上，會讓看板的資訊量超載，失去原本跨部門溝通的用途。因此，我們鼓勵團隊建立各自的「團隊看板」，視覺化工作項目，更直覺得觀察團隊目前的進展。

因此，「企業看板」呈現的是產品想法的進展，「團隊看板」則是呈現在開發細節上的進展，例如我們經常會將一個比較大的產品想法，垂直切割成數個比較小的工作項目，這會使得團隊能夠更輕鬆地取得進展，並且帶來靈活性。

每週兩次的站立會議

每週我們會舉辦兩次的站立會議，每次的會議時間為 15 分鐘。

首先，我們希望每個單位都有代表人參加。因此至少有三位行銷人員（因為有三個行銷單位）、六名開發人員（每個團隊一名加上工程主管）、一名變更管理人員和一名維運人員，根據實際需要邀請專家參與會議。

一段時間以後，維運人員表示，這個企業看板上很少需要他們的意見，因此我們將出席規則簡化為：如果企業看板上有一些感興趣的內容，你就來參加站立會議。我們發現這樣的效果更好。

這個會議主要在找出是否存在阻礙進展的障礙，為了確保會議的順利進行，我們從看板的後面往前走。如果發現障礙，我們會問誰來解決這個問題。我們將分配一個負責人處理該障礙，我們會避免在會議中深入討論該問題，因為那應該在之後進行。

在結束會議之前，我們回顧重點，例如誰負責追蹤某個障礙。我們以「謝謝大家，今天就到此為止」正式結束了會議。

使用 Company Demo 取代 Sprint Demo

當開發團隊使用 Scrum 時，他們會進行 Sprint Demo。但是這種演示方式帶有開發偏見，而不是著重在用戶價值。

因此，我們將 Sprint Demo 替換成 Company Demo。發布間隔為四週，我們會在發布前一天進行一整天的演示。在這個活動中，團隊展示了新產品想法，讓整個公司的人員都能看正在發生的事情。

另外，我們在演示的議程中加入一個步驟。基於上一個版本，行銷部門將演示產品是怎麼被使用者使用的，以及分享使用者回饋和評論。這個方式受到開發團隊的高度讚賞，並讓開發人員有機會了解使用者如何使用產品。

更有效地使用指標

測量不是為了測量完美程度，它們是關於獲得基於事實的回饋來判斷你是否有所進步。

我們追蹤了兩個指標：「Lead Time」、「Popular 階段和 Oh Crap 階段的比例」，這些指標顯示團隊在交付價值方面的表現。

Lead Time 的計算從產品想法進入 Next 階段開始，直到 Ready to Use 結束。之所以選擇這兩個邊界的原因是因為在我們的控制之下。

每月一次，開發部門主管會從每一個開發單位召集一名代表，在看板前進行「改進脈動」（improvement pulse）或「快速回顧」（quick retrospective）。

這個會議非常簡單，主管審查指標（Lead Time 和使用者回饋）、審查看板（是否清晰、易於查看且有用？），並對看板進行必要的更改。 會議通常非常快，大約 15 分鐘，有需要的話立即針對看板使用方式做修改。

開發團隊在各種工作類型花費的比例

我們估算了每個團隊花費多少精力在各種工作類型上，並將這些資訊顯示在實體看板頂部的區域中。

統計結果顯示，前端團隊和後端團隊在各類型工作所花費的精力，大致符合下圖左邊的目標規則，例如 50% 的工作用於產品想法上、20% 的工作在於工程的改進項目等。

如何知道產品想法上市的時間

我們要怎麼回答「我什麼時候可以拿到我的東西？』針對這個經典的問題，我們將過去完成的產品想法進行採樣，並找出 95% 的位置，我們稱它為 upper control limit (UCL)。

下圖顯示產品創意交付時間的一個樣本，每個直條圖代表一個以交付的產品想法，垂直刻度顯示該產品想法所需的天數（lead time）。UCL 為 105 意味著 95% 的產品想法將在 105 天內交付。

這有助於管理客戶的期望，並知道如果他們想要達到特定的時間範圍或季節，何時開始準備新產品。

過去我們也嘗試使用以下的估算方式：small (兩到三天)、medium (一到三週)、large (超過一個月)。然後，我們將估算與交付時間做關聯。

猜猜看，估算是否可以很好的預測你何時可以收到你的東西呢？

在這個案例中，令人驚訝的是估算與交付時間沒有什麼關係。Small 的項目不見得花費比較少天，large 的項目也不見得花費比較多天。

如果估算不是影響交付時間的主要因素，那什麼才是呢？在這個案例中，有兩個因素：等待發布的時間、獲得專業技能協助的時間。

後來，在我們成功減少等待時間後，我們發現估算和交付時間之間存在某種相關性。 但在我們先解決等待時間問題之前，我們無法看到這一點。

如果您團隊的工作僅佔總價值流的一小部分，那麼你的估算可能無法準確地表明何時可以獲得產品。

我們如何找到第一個可以改進的機會

看板讓辨識瓶頸變得非常容易。在我們的看板系統中，因為有 WIP 的限制機制，所以不會發生某個階段有一大堆的工作在排隊。

所以，我們更近一步分析交付時間（lead time）的關鍵組成部分，看看是否可以找到改進的機會。我們來看看下圖能告訴我們什麼資訊。

從這張圖所示，我們傾向於「Test to Production」作為改善的起點，但是數據很少，感覺不是太有說服力。我們走到變更管理團隊（負責系統測試和生產更新的團隊），詢問他們對情況的看法。

變更管理團隊是一個由 9 人組成的團隊，負責在 70 多個系統中實施變更，他們有很多事情要做。

經過與他們的討論之後，他們決定從三個方面解決這個問題：

1. 在變更管理團隊中引入團隊看板，以幫助他們確定工作負載的優先順序、贏得時間來確保品質、減輕壓力並促進團隊合作。
2. 們停止對版本進行後期更改（late changes）。 我們在開發、變更管理和行銷之間就版本變更的截止時間達成了協議，並確保每個人都遵守協議。
3. 我們邀請開發人員將自動化測試場景新增到我們的系統測試環境中。 這簡化了測試，更重要的是，測試獲得了回饋。

經過這些改善之後，我們的成果如何？

我們有進步嗎？這是最重要的問題。 如果我們沒有可以指出的改進，那麼所有這些變化都毫無意義。我們從已發布產品想法的交付時間開始。

正如你在圖表中看到的那樣，交付時間隨著時間的推移呈下降趨勢，因此縮短上市時間的努力似乎得到了回報。 我們可以從下圖中感受出這一點。

2013 年第一季發布的產品想法的交付速度大約是 2012 年第三季的兩倍。

正如我們希望確保我們確實在改進一樣，我們希望確保我們運送的東西對客戶有價值 — — 實際上可以出售的東西。 圓餅圖顯示了我們在這方面的表現。

我們透過在發布後詢問客戶和最終用戶是否對交付感到滿意來了解價值。你或許還記得，我們在看板末端的兩個部分來記錄結果：「Popular」和「Oh Crap」。實際上有兩種不同的方式讓某些東西變成「Oh Crap」。

第一種類別是客戶拒絕了我們的交付（customer rework）；另一種類別是我們自己因為不滿意而中止交付程序（dev rework）。

無論是哪一種類別，佔整體的比例都非常的低，這意味著我們做得還不錯。

改善前後溝通方式的差異

下圖顯示該公司在引入企業看板之前，溝通方式被拆解成好幾個獨立的片段，強調的是個部門之間所需的流程工件。

整體的回饋很晚才會獲得，sprint 的承諾是針對局部的變更，對於最終產品想法的進度很難掌握。

下圖顯示這些改善導致截然不同的成果。 今天，在與開發人員分享產品想法之前，我們獲得了關於客戶價值的第一個回饋（如果我們理解並能夠溝通的話）。 產品適合性的驗證（了解解決方案是否滿足最優先的期望）持續發生。

在 18 個月的時間內，我們成功地將交付時間縮短了 2 倍。看板幫助我們做的是讓事情的實際運作方式變得可見，以便我們的流程可以即時調整。

注意到我們沒有做的事情也很有趣。 我們並沒有根據某種流程方法（例如，「你有多敏捷？」）或組織模型來決定改進的方向。

我們檢視流程中端到端的觀察結果，以決定下一步需要改進的內容，我們堅持下去直到完成。

你也可以做出自己的改進

你可能會發現自己處於類似的情況，你希望可以端到端改進工作流程。這裡有一些建議可以幫助你克服這些挑戰：

1. 可視化整個價值流： 讓管理階層參與端到端的改進，而不僅僅是一小部分。 只有當我們看到整個客戶旅程時，我們才能釋放最大的潛力。
2. 嘗試透過小實驗來做出改變：一切都是第一次。 如果你的第一個想法失敗了，可以嘗試一些更小的想法，但不要推遲旅程。 進行一些小實驗來了解它們是否有效。
3. 談論改變： 聆聽並且交談。 將人們視為有思想的人並提出更好的選擇。 如果你堅持談論足夠長的時間，即使跨越組織邊界，也有可能改變舊的慣例和習慣。

Real-World Kanban: Do Less, Accomplish More with Lean Thinking

如果你喜歡我的文章，歡迎「拍手」給我支持，或是「Follow」我，讓我提供更多的優質文章給你。

《Real-World Kanban》企業看板的實務運用案例 was originally published in 德瑞克的敏捷咖啡 on Medium, where people are continuing the conversation by highlighting and responding to this story.

適合剛開始或正計劃要學習敏捷的朋友

2023 年 5 月底，公司內的通訊軟體傳來一封陌生的訊息：

「Derek 你好，我是安晏，經由 Agile Summit 的頁面介紹，得知公司內有敏捷教練的角色。」

「想向你請教有關公司導入敏捷的經驗，以及如何將敏捷角色結合在目前的組織中？想問你是否願意分享你的經驗呢？」

當下，我迅速撥打了電話給安晏。我們立刻在線上進行了深入的經驗分享和討論。在談話結束時，我邀請她參加我即將舉辦的兩天 Scrum 訓練課程，給予課程一些建議與回饋。她樂意接受了我的邀請。

從那一天起，我們偶爾地交流意見和想法，我也逐漸變得更加熟悉這位只見過一次面的同事。

2023 年 10 月初，我的座位上多了一份包裹，心中還納悶這裡頭是什麼東西。拆開一看，竟然是一本書《Agile一本通! 敏捷新手入門導引》，作者竟然是安晏，這讓我又驚又喜。

放下手邊正在吃的飯糰，認真地從頭開始仔細閱讀，才讀到前面幾頁，在「致謝」頁看見了一段話。

「感謝只有一面之緣仍願意與我討論，適時點醒我的 Derek，每次與你的討論都讓我獲益良多。」

看到這段文字，讓我又更意外了，我沒有預期自己的名字有一天會出現在某本書中的致謝頁中。

如果我對於安晏有任何一絲絲的幫助，我深信這完全歸功於她自己的不懈努力，我僅是在一旁提供了些微的協助與幫忙。

利用週末的時間，仔細閱讀了這本書，想跟大家分享這本書我喜歡的三個地方，包含：書本結構、軟體開發、學習資源。

書本結構

整本書依照專案的階段為基礎，依序說明在各個階段中所需要知道的事情，前後章節之間的連貫性很好。

在「專案準備」中直接破題，告訴我們敏捷是什麼，以及我們到底該不該敏捷；在「專案開始」中，我們如何有效的的收集客戶的需求；在「專案啟動」中，我們如何將需求轉化成不同顆粒度的工作項目，放進產品待辦清單和衝刺待辦清單中做管理。

在「專案進行」中，分成會議、文件、團隊、開發這幾個小主題，各自做了精彩深入淺出的介紹。在「專案結尾」中，就如何敏捷裡的回顧會議，帶著我們回顧團隊真得敏捷了嗎？以及常見的敏捷失敗原因。

軟體開發

我很喜歡在談論敏捷的時候，也能夠提到軟體開發中好用的工程實踐。根據我的過去的經驗，有兩個工程實踐特別的重要，分別是自動化測試和 CI/CD Pipeline。

這本書當然也沒有漏掉，甚至提得更完整。像是書本上提到三種開發模式：BDD、ATDD、TDD，三種設計原則：DRY、YAGNI、KISS，最後也介紹了 CI/CD。

作者礙於篇幅，以及書本的主題圍繞著敏捷，無法針對這些工程實踐做深入的展開與探討，但是對於新手讀者來說，還是增加了許多廣度上的學習。

學習資源

過去我自己在學習敏捷的時候，主要從閱讀書籍、通過認證課程、參加社群活動，以及自己在工作上累積的經驗為主。

我比較少在 Coursera、Udemy 和其他知名的課程平台上做學習，主要的原因是這些平台上的課程實在太多了，當資訊過多的時候，我就不知道要怎麼選出優質的課程。畢竟購買一堂課以後，通常學習時間都是 4–20 小時起跳。

作者在書本的最後面，非常的貼心，詳細列舉數個優質的課程，例如在 Coursera 上的「Agile Project Management」、「Managing an Agile Team」、「Applied Scrum for Agile Project Management」等。除了上述的英文課程以後，也提供一些中文的學習資源。

這些優質的學習資源，都能協助我們在追求敏捷學習的道路上，更輕鬆地前進。

結語

當初作者設定這本書的內容時，她明確地將目標設為一本敏捷入門書籍。他希望這本書能夠讓路人皆能理解，容易消化，以便各領域的讀者都能從中受益良多。

根據這本書的內容，我深信作者已經成功實現了當初設定的目標。這本書能夠讓敏捷的初學者在短時間內，獲得廣泛且深刻的敏捷理解。

作者參加鐵人賽，並投入了大量時間，將她所收集到的資料與個人經驗相結合，以極簡單易懂的文字解釋複雜的概念，實在難能可貴。

我誠摯地推薦這本書給那些剛開始學習敏捷或正計劃著要學習敏捷的朋友。

Agile一本通！敏捷新手入門導引：你需要的敏捷觀念、工具、好用資源，看這本就夠！（iThome鐵人賽系列書）【軟精裝】

如果你喜歡我的文章，歡迎「拍手」給我支持，或是「Follow」我，讓我提供更多的優質文章給你。

《Agile一本通! 敏捷新手入門導引》推薦文 was originally published in 德瑞克的敏捷咖啡 on Medium, where people are continuing the conversation by highlighting and responding to this story.