根據國外首次年度《看闆狀态報告》顯示：大部分團隊采用看闆的首要原因是提高了可見性、持續改進和增加了吞吐量，而在這個過程中用正确的工具則會使看闆更容易實施。

　　1.看闆簡介 看闆是一種漸進變化的方法，在國内外，已經有無數的生産實踐證明，看闆能夠有效幫助團隊提升交付效能，就比如在微軟公司-印度IT團隊就曾通過看闆管理，使得需求交付周期時間Lead Time: 155天→42天。

　　在 Kanban University 發布的《看闆指南》中介紹：看闆不是一種方法論，也不是一個流程框架，而是一種應該用于現有流程或工作方式的管理方法或途徑。從來不存在要使用看闆還是某一方法論或框架的問題。相反，總是可以在現有的方法論、框架或工作方式上使用看闆。

　　所以看闆沒有像 Scrum 那樣的活動或者工件，僅有兩大原則和六個通用實踐：

　　看闆原則：變革管理原則、服務交付原則；看闆通用實踐：可視化、限制在制品（WIP）、管理流動、定義清晰的規則、實施反饋環、協同改進，試驗進化； 而本文将通過一個完整的項目流程體驗 PingCode 對以上看闆實踐和原則的支持，以及通過成熟、标準的能力等維度，看看是否滿足産研團隊更複雜的看闆實踐需求。

　　2. 在 PingCode 實現高效的看闆項目管理2.1 工作流建模 常見痛點：很多團隊都是通過簡單的、通用型的項目工具來管理看闆，無法滿足流程自定義、可視化、管理流動、限制在制品、持續改進等一些複雜的看闆實踐；

　　在開始引入看闆方法或者是使用專業的看闆工具管理項目時，由于團隊的管理方式、項目的特點等不同，所以要了解每個确定工作項類型都要經曆哪些活動，它們可能是順序。之後在看闆可視闆上，将基于這些活動定義列。

　　所以工具需要有非常強的自定義能力以及符合看闆原則标準才可能承載各種團隊複雜的實踐。

　　下面就來看看 PingCode 對以上要求的支持：

　　全面反映需求交付過程，且支持自定義團隊自己的價值流動模型 比如：除了預制的流動模型（需求池、設計、研發、測試、發布）能夠用來管理比較普遍的産品交付過程；同時，PingCode-Kanban項目提供了自定義功能，支持自定義欄、泳道等，創建團隊自己的價值流動模型。

　　比如我們可以建立的一個外部缺陷、需求提交的看闆項目，專門用來收集客戶和市場部門的需求以及缺陷，這樣最大的好處就在于，每個人都能查看到需求、缺陷的流轉狀态，産品經理能夠輕松的通過看闆與提交人員建立起溝通。

　　支持WIP和WIP Limit，幫助團隊減少團隊協作中的混亂 項目管理中很大一部分工作是減少團隊合作中固有的混亂，項目管理的本質是如何通過它來限制混亂，使項目井然有序。在看闆方法中，看闆上流動的工作被稱為在制品（WIP），我們通過限制每一個階段允許積壓的在制品數量來避免大量工作并行，達到控制混亂的目的。這一行為被稱為在制品限制（WIP limit）。

　　當然，無論是 WIP 還是 WIP Limit 都能在PingCode 獲得對應的支持：

　　看闆設置

　　支持将步驟拆分為Doing/Done & DoD：保證整體開發過程的質量 對于看闆系統來說，簡單的配置價值流轉過程是不夠的。為了保證開發過程的整體質量，我們通常還需要制定對應的價值流轉規則——在制品（如用戶故事）從一個階段進入下一個階段所需要滿足的标準，即在此階段完成的定義（Definition of Done）。滿足DoD的在制品，放入Done中，随時可以進入下一階段，使工作交接更順暢。

　　以下為 PingCode 步驟拆分和DoD設置：

　　2.2 規劃待辦事項列表 常見痛點：很多團隊經常面臨需求描述、需求優先級及排期問題；

　　當适合需求的價值流動模型搭建出來之後，團隊将開始組建需求列表。而任何時候需求收集和需求管理的過程中，産研團隊經常會遭遇兩類問題：

　　需求描述的問題：需求信息不清晰、不完整；需求的優先級及排期問題：什麼樣的功能能對用戶産生最大的價值，這是需求管理中最重要的問題； 下面來看看PingCode 的解決方案：

　　全渠道的工單收集和自定義工單 為了幫助産研團隊更好的用戶洞察，PingCode 為用戶提供了統一的需求、缺陷和建議反饋通道，其中就包括Web Portal、小程序、郵件、Webhook等渠道。産研團隊可以根據需求自定義工單頁面，以及與需求提交人直接溝通，盡可能的完善需求信息。

　　基于數據洞察實現科學的需求優先級評審排期 PingCode 能夠幫助團隊整合工作量、價值、投票數、信心指數、影響程度，以及其他客戶自定義的維度等信息。在評審過程中，團隊将綜合各維度信息确定每個需求的權重分數，需求經過評審之後通過計算的權重分數确定需求排期，以實現科學的優先級管理。

　　科學的産品路線圖規劃 在需求評審完後，PingCode 将根據你需求的評審排期結果自動生成産品路線圖以及規劃版本，并選擇性同步給需求提出方以及内部團隊，反饋需求進度。

　　與此同時，評審完的需求、确認後的缺陷也将被拉入對應的看闆項目的需求列表，并配置詳細信息，如負責人、時間、當前狀态、關聯工作項等；

　　2.3 開發 痛點：過去産研團隊在各個開發環節的工具中頻繁切換，且低價值、重複性、手動性任務團隊浪費較多時間；

　　識别瓶頸：在進入開發過程之後，不同角色按工作流程拉取上一「欄」中高優先級工作項；與此同時，團隊也将通過我們前面提到的 WIP Limit 來限制正在進行的工作項數量，盡早發現并預警交付管道中的積壓、瓶頸和問題，交付待辦事項列表。

　　開發關聯：在團隊開發過程中，代碼、持續集成、測試用例、缺陷、文檔等，都可關聯對應任務，信息在需求頁面均可統一獲取；

　　自動化能力：PingCode 還為團隊提供了自動化技術，能夠将開發過程中重複性、低價值的任務由手動操作變為自動執行，比如：某個需求下的子任務都完成了，PingCode 将自動改變該需求的狀态，類似的場景還有很多，就比如自動創建分支、自動配置頁面權限等等；

　　PingCode 中的自動化規則模闆

　　2.4 持續改進 對于協調交付和服務交付的改進來說，反饋環都是必要的。一套适合給定環境的有效反饋環可以加強了組織的學習能力，并通過可控試驗的方式進行進化。看闆系統中一些常用的反饋環方式由可視闆、度量和稱為節奏的一組定期會議和回顧評審組成。

　　所以下面我們就來看看PingCode 看闆在持續改進上的支持：

　　2.4.1可視闆 在價值交付過程中，團隊可以依據 PingCode 可視闆觀察與跟蹤工作的狀态以及流動（而不是工作的人），重點關注團隊遇到的問題和阻礙，并配置資源協助解決。（可視闆用于團隊平時和每日站會）

　　2.4.2 度量 看闆中有許多基本的度量，比如：

　　前置時間是單個工作項從開始(承諾點)通過系統到完成所需要的時間交付率是每單位時間内完成工作項的數量，例如每周的特性、每月的培訓課程或每月新招聘的員工在制品(正在進行的工作)是在某一特定時刻系統中(或定義的部分系統)工作項的數量 這些核心度量在各種圖表中展示，以理解系統的行為和識别改進的機會。為了滿足以上需求 PingCode 提供了十多種度量報表，比如《看闆指南》中提到的累積流圖、在制品周期報告、交付率（需求屬性分布）等等；

　　2.4.3 建立節奏 在早期的看闆實施中，看闆實踐的反饋環幾乎是完全缺失的，但随着成熟度的增長，反饋環會不斷發展而進一步提高成熟度，每個團隊也将逐步建立自己的節奏。比如每日站會和每兩周的回顧會：

　　每日站會：觀察與跟蹤工作的狀态以及流動（而不是工作的人），我們如何在系統中快速的交付工作項呢?是否有可用的産能？下一步我們該拉動什麼？每兩周/每月回顧會：團隊反思如何管理自己的工作，以及如何改進，比如流程規則（如工作流程、DoD等）可随着團隊成長不斷優化； 至此，一個完整的看闆項目實踐就基本結束。

　　我們通過一個完整的看闆項目實踐來檢驗了PingCode 這款工具對看闆實踐的支持，如果大家感興趣可以通過以下方式體驗。

　　PingCode官網

　　,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!