PingCode是如何管理看板（Kanban）项目的？
首次年度《看板状态报告》显示：大部分团队采用看板的首要原因是提高了可见性、持续改进和增加了吞吐量，而在这个过程中用正确的看板工具则会使看板更容易实施。下面就来为大家介绍看板工具软件PingCode，具备哪些看板功能。
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 将自动改变该需求的状态，类似的场景还有很多，就比如自动创建分支、自动配置页面权限等等；
2.4 持续改进
对于协调交付和服务交付的改进来说，反馈环都是必要的。一套适合给定环境的有效反馈环可以加强了组织的学习能力，并通过可控试验的方式进行进化。看板系统中一些常用的反馈环方式由可视板、度量和称为节奏的一组定期会议和回顾评审组成。
所以下面我们就来看看PingCode 看板在持续改进上的支持：
2.4.1可视板
在价值交付过程中，团队可以依据 PingCode 可视板观察与跟踪工作的状态以及流动（而不是工作的人），重点关注团队遇到的问题和阻碍，并配置资源协助解决。（可视板用于团队平时和每日站会）
2.4.2 度量
看板中有许多基本的度量，比如：
- 前置时间是单个工作项从开始(承诺点)通过系统到完成所需要的时间
- 交付率是每单位时间内完成工作项的数量，例如每周的特性、每月的培训课程或每月新招聘的员工
- 在制品(正在进行的工作)是在某一特定时刻系统中(或定义的部分系统)工作项的数量
这些核心度量在各种图表中展示，以理解系统的行为和识别改进的机会。为了满足以上需求 PingCode 提供了十多种度量报表，比如《看板指南》中提到的累积流图、在制品周期报告、交付率（需求属性分布）等等；
2.4.3 建立节奏
在早期的看板实施中，看板实践的反馈环几乎是完全缺失的，但随着成熟度的增长，反馈环会不断发展而进一步提高成熟度，每个团队也将逐步建立自己的节奏。比如每日站会和每两周的回顾会：
- 每日站会：观察与跟踪工作的状态以及流动（而不是工作的人），我们如何在系统中快速的交付工作项呢?是否有可用的产能？下一步我们该拉动什么？
- 每两周/每月回顾会：团队反思如何管理自己的工作，以及如何改进，比如流程规则（如工作流程、DoD等）可随着团队成长不断优化；
至此，一个完整的看板项目实践就基本结束。
我们通过一个完整的看板项目实践来检验了PingCode 这款工具对看板实践的支持，如果大家感兴趣可以通过以下方式体验。