看板模型在敏捷软件开发流程中的应用

蒋梦云

看板（Kanban）一词来自日本，源于精益生产实践。看板使得项目管理最大的可视化，但是看板更可以将研发的过程进行管理，记录下用户故事研发过程中的细节和历程。

1.软件开发中看板的用途

（1）最大限度的可视化，同时解决团队沟通障碍。通过Kanban，项目团队可以清楚了解已经完成的情况，正在做的以及后续将有可能需要做的用户故事。

（2）对于项目经理而言，最担心的就是项目进度不可控，不知道每位开发人员具体的工作进度；有了Kanban，所有工作进度都能清晰的展示在看板墙上。

（3）对于开发经理而言，最担心的就是资源分配不合理，忙的人忙死，闲的人闲死，有了Kanban，可以合理的分配开发资源和任务。

（4）对于开發人员而言，最担心的就是绩效考核不公平；在开发工程中的绩效，不能清晰地反应在考核中，每个开发人员对其他人的工作也不了解。有了Kanban，可以明白地知道项目组各个人员的任务量，对开发的内容，也能清晰地沟通。

2.看板模型流程

2.1划分阶段

①待开发：还没做的，一般称为Backlog，这部分由产品经理（PM）协同开发经理来定义，主要的来源是客户的新需求或者市场线上反馈的bug；

②开发中：正在进行的任务，一般这个部分都是详细编码的过程；如果存在架构设计、前端UI、具体编码的分工，也可以再具体的划分；

③待测试：已经完成的开发功能，这部分由开发人员移动，下面一步就交由测试人员；

④测试中：测试部分，表明当前测试人员正在进行的工作；

⑤已完成：已完成，等待上线。

每个项目可以根据自己的需求建立自己Kanban。上面这个并不是唯一的。

2.2定义卡片模型

在待开发中放置了许多小卡片，它们在Kanban中被称为在制品（Work In Process，WIP）。对于产品经理而言，WIP是需求，而对于开发人员与部署人员而言，WIP却是任务。对于卡片模型来说，我们可以定义如下内容：

Task类型：用户故事（User story）bug分为一类；重构、搭建测试环境这样的不直接产生业务价值的任务分为一类，还有一些项目运营中的一般事务分为另一类；这3类任务用不同颜色的卡片，放到状态墙上统一管理。

Task ID：是某个Task的唯一标识；

Task描述：就是这个Task要做什么；

Task预估时间：一般根据项目组的平均开发时间来预估每一个Task的开发时间，根据这个时间，可以评估出在一个迭代周期中所有Task需要完成的时间。通常据此时间来排列Task中的优先级；

Task优先级：由产品拥有者来决定，或者由开发经理决定；

Task所有者：完成这个Task的负责人。

2.3利用泳道来优化流程

具有泳道特性的看板，在移动状态时需要参照以下流程：

①当一个用户从“Backlog”移到“用户故事”列时，需要将用户故事涉及的多方成员的工作进行任务拆分，拆分成一个个的任务。

②成员针对任务进行工作，当所有成员的任务完成后，将完成的用户移到测试验证列中。

③如果测试发现问题，则将相关的bug报给对应任务的人。

④看板实践核心实践的重要性和原则。

通过看板建立团队稳定的任务节奏，实现始终如一的可靠交付，这能够帮助团队与客户、依赖的相关部门、供应商、价值流下游合作伙伴建立信任关系。而信任关系对每一方都是非常重要的。

可视化工作流程，所有的Task的进度会全部显示Kanban上，每一个人都可以一目了然了解进度和流程。

限制WIP中的Tasks数量，一般情况下，这个数量是等于Team中的developer数量。

缩短开发周期，这个其实可以理解为发现问题，解决问题，从而找到更科学的方法提高开发效率。

拉动生产，看板很好地展示下游环节的当前状态，根据已完成工作确定前一环节可以投入多少资源，而不是前面环节使劲投入，不管后面环节是否能应对。

3.结束语

减少浪费是敏捷软件项目的核心之一，利用Kanban，项目开发中的各个关系人可以很方便地了解项目进行的状态，在使用中可以增加沟通的效率，提高对项目价值的认知度，进一步的减少不必要的浪费。