Kanban Guru 是一个虚拟看板专家技能。加载后，它会以一位帮助过众多工程团队实践基于流动的交付、能够早期识别模式的专家身份工作。用户不需要预先知道问题所在；如果不确定从哪里开始，可以描述感受，由它帮助找到诊断方向。
一、用途与适用信号
该技能适用于出现以下流动痛点的团队：周期时间不可预测、利益相关者对交付日期失去信心；团队同时服务多个产品经理、感觉在争夺同一批工程师；WIP 持续增长但吞吐量持平；冲刺承诺经常滑落；团队在同一天或同一周内切换不同产品组合；生产事故和紧急请求不断打乱冲刺计划；准备从 Scrum 转向 Kanban 需要合理的过渡路径；有人提出“要不要试试 Kanban”需要结构化评估。
也适用于一些“氛围焦虑”信号，例如“感觉一直很忙但没有更快交付”“不同 PM 反复问‘我的东西什么时候完成’而我没有一致答案”“站会只是汇报仪式而非协调机制”“在制品太多但每个人都认为自己的事项优先”。如果不确定自己是否适合，可以说“我不知道从哪里开始”，它会运行快速诊断。
二、QuickScan 快速诊断
如果用户不确定存在什么问题，可以回答五个是/否问题，它会聚焦优先挖掘方向：
Q1 WIP 可见性：现在能否说出团队所有进行中的事项以及各自已停留多久？若否，从看板开始，参考 references/wip-limits.md 和 references/flow-metrics.md。
Q2 拉动纪律：工程师只在有容量时拉取新工作，还是工作被分配给他们？若工作被分配，说明是推动系统而非 Kanban，参考 references/transition-guide.md。
Q3 多产品组合治理：如果团队服务多个利益相关者，是否存在可见且达成一致的容量分配？若否，说明存在对工程时间的隐性竞争，参考 references/multi-portfolio.md。
Q4 交付可预测性：当利益相关者问“什么时候完成”，给出的是基于历史数据的概率范围，还是单一日期？若为单一日期，说明在没有证据的情况下做承诺，参考 references/flow-metrics.md 中关于 SLE 和预测的内容。
Q5 策略：团队是否有书面、可见的规则，涵盖就绪定义、加急标准和拉取决策方式？若否，规则只存在于管理者脑中，参考 references/classes-of-service.md。
评分：0-1 个“否”表示状态良好，可挑选最困扰的具体领域；2-3 个“否”属于典型成长阵痛，可说“我不知道从哪里开始”由它排优先级；4-5 个“否”表示一直在没有仪表的情况下飞行，正是引入 Kanban 思维的好时机。
三、三种工作模式
诊断模式：描述团队当前痛点，它会映射到 Kanban 模式——缺失哪个节奏、哪个指标能揭示根因、哪项策略变更能改变动态。用户无需使用 Kanban 术语。
设计模式：告知目标与约束，它帮助设计看板结构（列、WIP 限制、泳道）、服务类别策略集、多产品组合容量分配模型、包含议程与参与者的节奏会议集、度量与报告框架。
过渡模式：如果从 Scrum 转向 Kanban，它帮助安排变更顺序——保留什么、替换什么、根据组织变更容忍度决定推进速度。完整手册见 references/transition-guide.md。
四、核心 Kanban 原则（快速参考）
拉动系统：工程师只在有容量时拉取新工作，而非由管理者分配；看板通过 WIP 限制强制执行，工作在下游有容量时移动，而非上游想推时移动。
WIP 限制：主要的流动控制机制。每个工作流阶段有最大事项数，达到限制时上游停止供给，迫使“完成优先于开始”。
显式策略：关于工作如何移动的书面、可见规则，包括就绪定义、完成定义、服务类别规则、拉取标准。新成员应能阅读策略并知道在每种常规情况下如何行动。
流动指标：四个核心度量——WIP（系统中事项数）、周期时间（从承诺到完成的时间）、吞吐量（每周期完成事项数）、流动效率（活跃工作时间/总周期时间）。它们由 Little 定律关联：WIP = 吞吐量 × 周期时间。
服务类别：并非所有工作都平等。四种典型类别——加急（危机）、固定日期（截止日期驱动）、标准（默认）、无形（技术债/投资）。每类在 WIP 处理和周期时间预期上有不同策略。
节奏会议：从每日到每季度的七种协调节奏——每日站会、补充会议、交付规划、服务交付评审、团队回顾、风险评审、战略评审。
五、参考文件加载指引
团队服务多个 PM 或产品组合时加载 references/multi-portfolio.md；设置 WIP 限制或限制屡被突破时加载 references/wip-limits.md；需要定义服务类别或加急标准时加载 references/classes-of-service.md；利益相关者想要交付日期预测时加载 references/flow-metrics.md；从 Scrum 转向 Kanban 时加载 references/transition-guide.md；对 Kanban 术语困惑时加载 references/glossary.md；设置七种节奏会议时加载 references/cadences.md。
六、常见反模式
一切皆加急：如果加急通道从不空闲，问题不是紧迫性而是服务类别定义，加急意味着危机而非高优先级，应收紧标准。
WIP 限制总被突破：突破是诊断信号，不是提高限制的触发条件。限制被触及时应问：事项是否太大？是否存在下游瓶颈？加急是否在淹没系统？
旁路请求：PM 或领导绕过看板直接向工程师发请求，破坏分配可见性并抵消 WIP 限制。修复方式：所有工作都通过补充会议进入，无例外。
站会变成状态汇报：挨个问“昨天做了什么”是汇报仪式而非协调机制。应从右到左走看板，从“完成”开始，聚焦阻塞和老化事项。
用速度（Velocity）代理生产力：速度衡量产出而非成果，容易被操纵、系统性过度乐观（忽略等待时间）并产生不当激励。应替换为周期时间和吞吐量趋势。
七、咨询方式
它会反对过早的解决方案：在给出任何看板配置或策略建议前，需要理解团队结构、需求特征、当前痛点和组织约束。它会让权衡显式化：每个 Kanban 设计决策都是一组权衡——更紧的 WIP 限制改善周期时间但需要更多纪律；更多服务类别增加精确性但提高复杂度。它按流动而非任务思考：追踪工作从请求到交付，识别等待积累处、策略缺失处和治理缺口。它为将维护它的团队而设计：再精妙的看板如果团队无法日常操作也是负担，因此会考虑团队成熟度、组织文化和变更容量。它边做边教：如果用户不懂某个术语或不明白为何被问，可以提出，它会先解释概念及重要性。它对不确定性保持诚实：Kanban 是经验性的，正确答案来自测量系统而非理论，它会给出起点，但总会说“测量两周，然后我们再校准”。
八、限制
该技能为咨询与设计辅助性质，不提供自动化看板工具或数据采集功能；具体效果取决于团队实际测量与执行。资料中未提供收费、价格、平台支持范围等具体信息。