敏捷看板怎么做（浅谈“敏捷看板”的演进）

敏捷看板是什么

“看板”一词源于丰田制造，是用“一块板”来传递和控制生产环节，其核心理念就是杜绝浪费，提高效率。之后，看板被改进并应用于软件研发领域，软件领域的敏捷理念与制造业的精益思想开始相互借鉴和融合，于是衍生出“敏捷看板”的概念。“敏捷看板”就是采用敏捷和精益开发方法的工具，能够提升团队的价值交付能力。

看板在日常研发应用的过程中，根据产品或敏捷团队的痛点和实际需要，经历了数轮演进。如下示例，是个人在实际项目管理过程中已应用过或觉得较好的看板模型，供各位看官参考。

第一代敏捷看板

初代看板模型，也是其他看板模型的“鼻祖”。它将用户故事的状态分为未开始、进行中、已完成。通过改变UserStory的状态来直观地管理迭代的进度。

第二代敏捷看板

在项目管理过程中，状态为未开始、或已完成的UserStory没有什么争议，不过进行中的阶段太大，包含的内容较多，尤其是产品研发要经历调研、分析、开发、测试、上线投产等一系列过程，简单的通过“进行中”一个状态管理，无法直观地发现UserStory的阻塞点发生在哪个阶段。因此，为了更加直观地管理迭代进度，将进行中的各阶段进行更加细化的拆分。

第三代敏捷看板

产品迭代一段时间后，有人提出来：虽然UserStory在研发的某个阶段，但是通过看板我无法知道这个用户故事是没开始做呢，还是正在做？没开始做的有多少个，正在做的又有多少个？除了跟相关人员沟通外，无从得知，这样无形中增加了管理的沟通成本。为了解决这个问题，在研发过程中的每个阶段拆成未开始、进行中。已完成的用户故事直接移动至下一阶段的未开始中。

第四代敏捷看板

在第一代至第三代的敏捷看板，重点关注的是用户故事。不过，在当前降本增效的大趋势下，企业希望研发、测试等团队成员把每个任务项都记录并管理起来，如某个用户故事的研发，不仅涉及编码，可能还涉及数据库表的设计、联调接口的网络策略开通、甚至是虚机部署模式下的服务器申请等。因此，为了更加精细化的管理，将用户故事进一步拆分，形成一个个任务项。如果在使用过程中，看板的元素较多影响展现，可以通过角色、任务类型进行筛选，形成不同维度的视图看板。

第五代敏捷看板

根据PMP项目管理理论，团队发展的五个阶段是：组建期（Frming）、激荡期（Strming）、规范期（Nrming）、执行期（Perfrming）和休整期（Adjurning）。项目初期，团队处于磨合阶段，产品经过一段时间阶段后，团队的技能以及协作状态会进入到相对稳定的状态。此时，在看板信息中可以考虑加入在制品数量（WIP）。在制品数量（WIP），即并行的工作量。简单来说，就是为了避免团队或个人同时做太多工作，避免让下游流程负载过重，限制每个泳道的并行工作量过多。不过，在制品限制数量设置完成后并非一成不变，团队可以根据实际情况，按照团队的节奏来更改在制品限制数。

不管看板的版本如何演进，最终的目的都是希望通过某种工具管理好项目或产品研发的进度，工具没有好坏对错之分，关键看研发团队如何使用，是否可以解决实际的问题。