Kanban 面板
概述
與 Scrum 面板類似，Kanban提供了一種為團隊跟蹤工作的視圖，主要功能包括為工作優先級排序，可視化工作流，通過識別瓶頸的方式來縮短製品交付時間，提升團隊效率。與Scrum強調指定時間衝刺不同，kanban 強調持續交付，即把任務從kanban 最左拖到右邊，更為靈活。
場景
不管 Scrum 還是 Kanban， 選哪個不重要，甚至於一個專案開兩個面板 走混合模式都行，主要是看團隊是否用得順手，Jira Admin 隨時協助調優。
軟件研發：創業小團隊因為具有較強靈活性，大公司需要強調準時定期交付，更常使用 scrum；
工廠製造：使用 Kanban 來代替線下 Excel ，識別瓶頸。
操作
創建
和Scrum 基本一致，由於 kanban追求靈活，默認情況下 epic 和 backlog 不打開，如有需要，打開即可。
由於 kanban 沒有 sprint 概念，為使界面進一步精確切分，可以在 過濾器基礎上 多家一道 子過濾器（即多一個 JQL 條件）
配置子過濾器，自動隱藏指定時間內的 issue
設定 WIP 可同時進行的最多事務/ 開啟 backlog/epic
開啟後左上角就會出現 backlog
使用
敏捷教練：會前提醒更新，每天開著 kanban 站會，定期使用報表開回顧會
用戶操作：
issue 從左往右拖動
issue 排序
估算故事點
界面上創建 issue / sub-issue
發佈 issue （發佈後，將會從 done 欄位消失）
推薦使用快速過濾器的 我的問題，最近更新，防止界面上問題過多找不到重點
Project Admin：協助敏捷教練調整參數，保證kanban拖動正常，報表數據準確
報表
累計流量圖
從中發現突然波動的處於某狀態 issue，進而分析產生異動的原因。
預測團隊未來潛在的瓶頸
控制圖
搭配kanban使用，推薦控制圖，用於分析團隊在指定時間段的內的交付效率。
是否有特定問題類型完成速度較慢
是否在一個指定狀態流轉較慢
過去交付速率是否穩定以預測未來的交付效率
經驗
數據結合主觀判斷
報表作為客觀數據，固然非常好。但注意
不要本末倒置，過度解讀。客觀數據也要結合管理者的主觀判斷
很多公司喜歡小腳穿大鞋，上來就要使用 最標準的管理方式，最終導致結果員工變成面向數字，績效，而不是實際客戶/商業價值工作。
跨專案
看板並不僅限單個專案。如果在過濾器引用了多個專案，那就都會在當前 kanban 中展現。
這對在開張會時，需要多次切換 頁面的 敏捷教練來說是一個節省時間，聚合展示的好方法。
調整工作流測試
跨專案的面板最好僅用於展示，不要去拖動狀態
如果是更新工作流，建議測試各類型的問題類型在kanban中的拖動，有時一些校驗以及轉換的錯誤，會讓某個問題卡在某一欄位，此時如果用戶不反饋，就會讓問題更新不及時，出現長時間滯留。