敏捷开发的看板

敏捷开发的看板不仅仅只是看板？在敏捷开发中为什么要采用看板？如何设计好的看板？任务条是改进的关键？

在我的理解中，敏捷开发中最先需要实施的三项重要工作需求用户故事化，沟通站会制以及进度看板化，这三个如果实施好了，不管你是否在实施真正敏捷还是对当前项目管理方式的一种改进，都能在研发管理过程中取得很大的进展。

前面两篇文章讲了用户故事和站会，这章就重点讲述项目进度看板化，本人会结合实际项目操作过程及对看板演进的过程进行讲解。

什么是看板？看板不仅仅是看板？

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

敏捷开发为什么要采用看板？

看板可以让研发过程最大限度的可视化，同时解决团队沟通障碍（实践中发现也可以作为和上级沟通项目进展的重要信息）的主要方法之一。通过看板，项目团队可以清楚了解已经完成的情况，正在做的以及后续将有可能需要做的用户故事。

看板可以作为敏捷团队每天站会的讨论的核心，及时变更看板各个用户故事的状态，通过看板，敏捷团队可以清楚的了解其它成员的工作状况及和自己相关工作的进展。

在状态墙上，除了用户故事、 bug之外，还会有一些诸如重构、搭建测试环境这样的不直接产生业务价值的任务，这三类任务用不同颜色的卡片，放到状态墙上统一管理。

 图1. 实际项目看板

 看板状态呈现可以很简单，也可以很复杂，这都基于实际项目的需要，我结合我们在实践敏捷研发过程中，对看板的几次改进进行分享。在介绍之前需要对用户故事的“完成”状态下个定义， 用户故事的“完成”是指经过测试并可潜在发布给用户使用的状态。

第一阶段：简单的反映用户故事目前处于的研发状态

  图2 简单的讲用户故事的任务上墙

 刚开始实施敏捷的时候才用最简单的看板，如上图2所示，只是简单的将用户故事的研发上看板，基于此看板我们能清楚的指导目前用户故事处于的状态。但是这种简单的看板存在一些明显的问题，如研发人员和测试人员的沟通状态无法在看板上进行体现。

 所以在第一阶段我们又进行修改，增加研发和测试的衔接，如下图3所示

    

图3 细化“正在做”的状态

 在改进后，我们“正在做”阶段进行细分为开发中，待测试机测试验证，

 这样的看板流程可以有以下一些好处

1. 通过这个改进流程就可以通过看板呈现研发完成到测试阶段，从测试阶段到完成阶段的展示。

2. 通过看板上用户故事数量的状况，可以预测目前研发资源和测试资源配比是否合理？根据状况可以及时调整人员。

第二阶段，通过泳道方式，让实现用户故事团队成员间的协作得到反映

 我们开展的项目由于是端到端的系统，所以往往一个用户故事的实现会涉及多个成员的共同参与，所以一个用户故事的完成依赖于多个人员负责的Task完成。所以针对这种情况我们进化了图4的方式，

  图3 采用泳道方式进行管理

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

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

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

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

泳道方式的看板具有以下一些优点

1. 在多个人协助的情况下，每个人可以独立完成分配的Task，相互的影响和制约可以降低到最小。

2. 每个人完成的Task可以作为用户故事的阶段成果，可以尽早的引入测试进行功能测试。

3. 可以非常清楚的了解整个用户故事的进展情况，了解用户故事处于的障碍。

但泳道方式也存在以下不足之处

1. 由于用户故事被拆分成分工明确的Task了，所以这个用户故事内部进入了阶段提交的过程。

2. 由于大家被拆分到了Task，所以需要指定特定的人来负责整个用户故事，并需要在内部协调项目之间的工作

3. 用户故事的工时预计又被模块拆分，在长期实践中，导致工时的预计又进入负责任务的人进行预估的模式。

第三阶段，通合理设计任务条，实现故事，进度，工时和各类衔接工作

 在实践了一段泳道模式之后，我们重新思考了，如何让各类工作更好的衔接。最终在任务条上进行改动是最合适的。所以我们根据实践过程中发现的问题，形成了如下的任务条。

    

                           图四 全面体现工作的任务条

此看板的任务条主要体现几大方面

1. 用户故事的描述，这个作为任务条核心部分，通过模块和ID和需求系统进行对应

2. 研发团队先对用户故事进行整体工时预估，得出这个用户故事团队的工作时间。

3. 涉及这个用户故事的所有人员都列在用户故事的下方，并且通过每天对当前用户故事的总工作量的预估，以及填写昨天的实际开发所耗工时

4. 用户故事指定相关责任人及依赖关系，可以明确的找到相关人员进行协调和解决

5. 通过bug list列出发现的问题，开发人员可以及时修改

采用了这种任务条后，就取消了泳道的模式，而是采用需求，UI设计，开发，单元测试，待测试，测试中，完成几个状态来完成。在我们项目中UI设计进行独立管理，是因为在整个UI设计是我们的瓶颈所在，需要及时查看UI任务堆积状况，及时调整UI的工作优先级状态，所以针对UI我们会独立出任务。

  图5完整看板状况

在做好看板工作时需要注意以下几点

1. 找到一种好的材料来制作任务条，以确保任务条容易被移动，不易掉落并且容易被收藏。一旦这个环节没有做好，很可能会导致看板维护成本加大，甚至后期不维护看板。

我们在这个过程中尝试了很多，如中便签条+小便签条， 大便签条， 纸板+橡皮泥等等，最终结合我们的看板是基于玻璃的，最后选择了打印纸+透明胶的方式，移动很方便，而且不容易掉。

2. 及时更新任务条中的各类状态，任务条不仅仅只在看板上移动，更重要的是要记录下研发的过程，这样很容易制作燃尽图，工时消耗图等供全局使用的报表。我们的做法是在站会钱5分钟，大家先更新状态，PO及时统计各类数据。