敏捷開發的看板不僅僅只是看板？在敏捷開發中為什麼要採用看板？如何設計好的看板？任務條是改進的關鍵？

在我的理解中，敏捷開發中最先需要實施的三項重要工作需求使用者故事化，溝通站會制以及進度看板化，這三個如果實施好了，不管你是否在實施真正敏捷還是對當前專案管理方式的一種改進，都能在研發管理過程中取得很大的進展。

前面兩篇文章講了使用者故事和站會，這章就重點講述專案進度看板化，本人會結合實際專案操作過程及對看板演進的過程進行講解。

什麼是看板？看板不僅僅是看板？

看板一詞來自日本（kanban），源於精益生產實踐（豐田生產），敏捷開發將其背後的視覺化管理理念借鑑過來。看板使得專案管理最大的視覺化，但是看板更可以將研發的過程進行管理，記錄下使用者故事研發過程中的細節和歷程。

敏捷開發為什麼要採用看板？

看板可以讓研發過程最大限度的視覺化，同時解決團隊溝通障礙（實踐中發現也可以作為和上級溝通專案進展的重要資訊）的主要方法之一。通過看板，專案團隊可以清楚瞭解已經完成的情況，正在做的以及後續將有可能需要做的使用者故事。

看板可以作為敏捷團隊每天站會的討論的核心，及時變更看板各個使用者故事的狀態，通過看板，敏捷團隊可以清楚的瞭解其它成員的工作狀況及和自己相關工作的進展。

在狀態牆上，除了使用者故事、 bug之外，還會有一些諸如重構、搭建測試環境這樣的不直接產生業務價值的任務，這三類任務用不同顏色的卡片，放到狀態牆上統一管理。

 圖1.實際專案看板

 看板狀態呈現可以很簡單，也可以很複雜，這都基於實際專案的需要，我結合我們在實踐敏捷研發過程中，對看板的幾次改進進行分享。在介紹之前需要對使用者故事的“完成”狀態下個定義，

第一階段：簡單的反映使用者故事目前處於的研發狀態

 圖2 簡單的講使用者故事的任務上牆

 剛開始實施敏捷的時候才用最簡單的看板，如上圖2所示，只是簡單的將使用者故事的研發上看板，基於此看板我們能清楚的指導目前使用者故事處於的狀態。但是這種簡單的看板存在一些明顯的問題，如研發人員和測試人員的溝通狀態無法在看板上進行體現。

 所以在第一階段我們又進行修改，增加研發和測試的銜接，如下圖3所示

圖3 細化“正在做”的狀態

 在改進後，我們“正在做”階段進行細分為開發中，待測試機測試驗證，

 這樣的看板流程可以有以下一些好處

1. 通過這個改進流程就可以通過看板呈現研發完成到測試階段，從測試階段到完成階段的展示。

2. 通過看板上使用者故事數量的狀況，可以預測目前研發資源和測試資源配比是否合理？根據狀況可以及時調整人員。

第二階段，通過泳道方式，讓實現使用者故事團隊成員間的協作得到反映

 我們開展的專案由於是端到端的系統，所以往往一個使用者故事的實現會涉及多個成員的共同參與，所以一個使用者故事的完成依賴於多個人員負責的Task完成。所以針對這種情況我們進化了圖4的方式，

 圖3 採用泳道方式進行管理

 具有泳道特性的看板，在移動狀態時需要參照以下流程

1. 當一個使用者從“將要做”移到“使用者故事”列時，需要將使用者故事涉及的多方成員的工作進行任務拆分，拆分成一個個的任務。

2. 成員針對任務進行工作，當所有成員的任務完成後，將完成的使用者移到測試驗證列中。

3. 如果測試發現問題，則將相關的bug報給對應任務的人。

泳道方式的看板具有以下一些優點

1. 在多個人協助的情況下，每個人可以獨立完成分配的Task，相互的影響和制約可以降低到最小。

2. 每個人完成的Task可以作為使用者故事的階段成果，可以儘早的引入測試進行功能測試。

3. 可以非常清楚的瞭解整個使用者故事的進展情況，瞭解使用者故事處於的障礙。

但泳道方式也存在以下不足之處

1. 由於使用者故事被拆分成分工明確的Task了，所以這個使用者故事內部進入了階段提交的過程。

2. 由於大家被拆分到了Task，所以需要指定特定的人來負責整個使用者故事，並需要在內部協調專案之間的工作

3. 使用者故事的工時預計又被模組拆分，在長期實踐中，導致工時的預計又進入負責任務的人進行預估的模式。

第三階段，通合理設計任務條，實現故事，進度，工時和各類銜接工作

 在實踐了一段泳道模式之後，我們重新思考了，如何讓各類工作更好的銜接。最終在任務條上進行改動是最合適的。所以我們根據實踐過程中發現的問題，形成了如下的任務條。

圖四 全面體現工作的任務條

此看板的任務條主要體現幾大方面

1. 使用者故事的描述，這個作為任務條核心部分，通過模組和ID和需求系統進行對應

2. 研發團隊先對使用者故事進行整體工時預估，得出這個使用者故事團隊的工作時間。

3. 涉及這個使用者故事的所有人員都列在使用者故事的下方，並且通過每天對當前使用者故事的總工作量的預估，以及填寫昨天的實際開發所耗工時

4. 使用者故事指定相關責任人及依賴關係，可以明確的找到相關人員進行協調和解決

5. 通過bug list列出發現的問題，開發人員可以及時修改

採用了這種任務條後，就取消了泳道的模式，而是採用需求，UI設計，開發，單元測試，待測試，測試中，完成幾個狀態來完成。在我們專案中UI設計進行獨立管理，是因為在整個UI設計是我們的瓶頸所在，需要及時檢視UI任務堆積狀況，及時調整UI的工作優先順序狀態，所以針對UI我們會獨立出任務。

 圖5完整看板狀況

在做好看板工作時需要注意以下幾點

1. 找到一種好的材料來製作任務條，以確保任務條容易被移動，不易掉落並且容易被收藏。一旦這個環節沒有做好，很可能會導致看板維護成本加大，甚至後期不維護看板。

我們在這個過程中嘗試了很多，如中便籤條+小便籤條， 大便籤條， 紙板+橡皮泥等等，最終結合我們的看板是基於玻璃的，最後選擇了列印紙+透明膠的方式，移動很方便，而且不容易掉。

2. 及時更新任務條中的各類狀態，任務條不僅僅只在看板上移動，更重要的是要記錄下研發的過程，這樣很容易製作燃盡圖，工時消耗圖等供全域性使用的報表。我們的做法是在站會錢5分鐘，大家先更新狀態，PO及時統計各類資料。