看板管理系統使用測評:一個好的看板工具應該具備哪些能力

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

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 這款工具對看板實踐的支持,如果大家感興趣可以通過以下方式體驗。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章