在敏捷開發中，大家經常會提到看板（kanban）這個名詞，故名思義就是視覺化的板。看板作為乙個敏捷方法，與其他方法相比具有更強的可實施性，也更易讓團隊理解和執行。
下面將結合豬齒魚團隊的敏捷故事，給大家講述下如何來使用看板，以及choerodon豬齒魚敏捷管理又是怎麼輔助專案成員落地看板方法的。
choerodon豬齒魚還沒有發布第乙個版本時，豬齒魚的總設計師已經非常確定團隊一定要使用敏捷的方式，去做乙個敏捷開發工具來幫助企業提公升系統交付的價值。
在豬齒魚開發前期，團隊需要去整理需求、收集需求、排列哪個故事先做哪個故事後做。那時候整個豬齒魚開發團隊被分成不同的敏捷小組，在辦公室擺了4、5塊白板。大家對照著看板方法中的模樣，依葫蘆畫瓢地在看板上用線條進行分割，繪製出列和泳道，並買來各種顏色的便利貼和磁貼，豬齒魚各個敏捷開發小組就這樣用起來了看板。
首先需要讓任務在板上呈現出來。
團隊定好乙個開發周期時，產品負責人（po）會將這個週期內的所有需求都整理出並分別寫在一張張大號便利貼上，按照優先順序高低將卡片從上到下依次放在story這一列，剩下的故事卡片繼續留在backlog這列裡，直到有故事（卡片）做完再去backlog中將優先順序最高的移動到story這列進行開發。團隊根據故事的描述、物件和目的等資訊將其拆分成乙個個的開發任務，寫在小號卡片上貼在doing狀態列中。每個團隊成員通過磁力貼顏色或其他方式標記出自己，粘在自己所負責的任務卡片上。
在使用看板後的第乙個迭代中，團隊裡幾乎聽不到「a功能是誰做的？」「b任務做到什麼程度了？」「為什麼c功能還沒開始？」「張三李四王五你們在幹嘛？」等等這樣的聲音了，每個成員只要抬頭看看白板，就能大概知曉以上這些資訊，而且是即時的。這樣一來，看板視覺化在豬齒魚團隊算是做到了。
圖為豬齒魚團隊物理看板
既然已經將產品功能和開發任務都貼在了看板上，接下來就需要讓任務流動起來。管理流動的目的很明確，就是要將所有的卡片從backlog中運送到部署，並能讓這個過程在板子上體現出來。
每一天的工作從各個敏捷團隊成員站在白板前開始，在豬齒魚產品開發團隊現場，每天早上都會看到一副盛景——開站會。
在繪製成多列（分別是待辦、分析、開發、測試和待發布或者部署）的看板面前，開發人員依次陳述自己昨天做了什麼，並將對應工作的卡片進行狀態的更新，也就是將做完的任務卡片從doing狀態移動到完成的狀態。然後再接著說今天要做什麼，並將板上backlog中的任務移動到doing的狀態，貼上自己的名帖。接下來測試人員根據板上已完成開發的卡片來安排今日任務或對之前還沒進入測試列的卡片進行測試工作，將開發完成的卡片從開發完成這列中移動到測試doing。
在迭代的前1到2天，可能看不出明顯的變化，從第三天開始，你會發現卡片動起來了，白板上任何列中都有卡片，從開發doing到開發done，從測試doing到測試done，再到部署。所有到doing的卡片，都不是直接貼上來的，一定是從backlog中經過了分析、開發、測試的各個階段才挪到了這個位置。
這只是整個流程持續優化之旅的開始，在這個過程中，總是存在某個瓶頸會拖延你的工作，慶幸的是，這些問題在白板上很容易顯現出來，比如某個卡片在板上停留了2天了還沒有動靜，比如誰的名帖在板上最多，誰乙個名帖都沒有。往往越嚴重的問題越早暴露，一旦解決掉，工作的流動就會明顯改進。
當基於這一原則開展工作時，你能夠從精益思想中找到靈感來消除過程中的浪費以便工作能夠順暢流動起來。
限制在製品指的是對進行中的任務數進行最多數量的限制。首先限制在製品並不是乙個目的，它只是用來驅動改進的手段。
豬齒魚敏捷團隊在前期開發中，也無法理解如何去做到限制在製品。平台設計師張禮軍說，「我們就先按乙個人最多同時進行3個任務去執行吧」。
於是大家按人員數量去限制在製品，用磁貼來表示工作的分配。我們為團隊成員每個人製作3個代表他們自己的磁貼，上面寫上代號或者名字。然後將其貼在自己負責的任務卡片上，這樣也很容易看出每個人在做什麼，並且手頭有多少正在進行的工作項。
這樣的好處是每個人只有當看板上自己的頭像少於3個的時候，才可以去領取新的任務，避免多工並行而忽略了交付質量。這樣實踐下來，很容易發現團隊中某些人是不是工作項過多，任務一直停滯不前，導致整個團隊的在製品過多，影響了整體進度。
但這個原則的目的側重於確保每個人都有足夠多的工作可做，對工作流動的完成狀態沒有什麼大的幫助，因為客戶不關注團隊是否每個人都有事情做，他們只希望能交付成果。
隨著敏捷思想的不斷實踐，團隊嘗試不斷改善方式，比如在每列上方寫上數字標記在製品的數量，開始實施基於列的在製品限制原則。通過在瓶頸之前的步驟設定在製品限制，可以防止瓶頸處工作氾濫，並且促使團隊解決瓶頸，進而改善整個流程。
舉個例子，比如開發列中的卡片數已經到了在製品上限，可是測試列裡的任務也存在堆積，測試人員沒精力進行更多的測試。這個時候，開發的卡片無法流動進測試列，開發人員便不能進行新的開發任務，瓶頸就很明顯在測試列了，那麼團隊的開發人員可以去幫助測試人員進行測試，從而解除瓶頸，讓板子上的卡片重新流動起來。
豬齒魚團隊運用了人員限制、列限制幾個方案，而在敏捷方法裡也提供了許多的方法以便你了解如何設定在製品。
限制在製品就是通過條件限制把流程改進的機會呈現在表面，使團隊能直接觀察到流動遲滯（卡片在白板上的移動非常緩慢）、任務積壓（在某列中堆積了很多卡片）、專案停滯（工作項一直等待）的等些問題，以便及時作出調整。
這些看板實踐經驗後來也在choerodon豬齒魚平台的敏捷管理上有所體現，前兩個原則自不必說，在限制在製品方面，豬齒魚敏捷管理採用列限制的方案。支援使用者自行對列進行配置，設定該列任務最大數量和最小數量。
數量會在看板上直接顯示，當任務數量已經達到最大時，新的任務無法拖入該列。
說到底，敏捷管理是乙個方法也是一種心態，選擇哪條路改進你的系統完全取決於你，最重要的一點是當你的工作向你發出改進資訊時，你要響應並改善它。
豬齒魚敏捷團隊故事看板實踐就介紹到此，敬請期待下篇《電子與物理看板的差異化分析》。
choerodon豬齒魚作為開源多雲應用平台，是基於kubernetes的容器編排和管理能力，整合devops工具鏈、微服務和移動應用框架，來幫助企業實現敏捷化的應用交付和自動化的運營管理，同時提供iot、支付、資料、智慧型洞察、企業應用市場等業務元件，致力幫助企業聚焦於業務，加速數位化轉型。
歡迎加入choerodon豬齒魚社群，共同為企業數位化服務打造乙個開放的生態平台。
豬齒魚 02 微服務元件間聯絡
通過前面幾節，我們已經完成了豬齒魚微服務支撐元件的部署。這一節，我們來關注下以下兩點內容 序號元件 spring cloud描述1 服務治理 eureka consul 2配置管理 cofnig 3容錯管理 hystrix 4負載均衡 ribbon 5服務呼叫 feign 6api 閘道器 zuul...
如何使軟體技術團隊1 1 2
軟體工程自20世紀60年代末期誕生以來，逐漸形成了其系統的軟體開發理論 技術和方法，並在軟體開發實踐中發揮了重要作用。作為軟體設計 開發 實施工作的主體 軟體技術團隊，它的建設是開發生產高質量軟體產品的重要保障。實現1 1 1是軟體技術團隊建設的基本目標，而實現1 1 2則是其高階目標。軟體技術團隊...
如何使軟體技術團隊1 1 2
軟體工程自20世紀60年代末期誕生以來，逐漸形成了其系統的軟體開發理論 技術和方法，並在軟體開發實踐中發揮了重要作用。作為軟體設計 開發 實施工作的主體 軟體技術團隊，它的建設是開發生產高質量軟體產品的重要保障。實現1 1 1是軟體技術團隊建設的基本目標，而實現1 1 2則是其高階目標。軟體技術團隊...