前言

上回书，我们简单地入门了敏捷开发中的scrum模式,在实施的过程中，其实也是出现了不少问题需要解决。
那么这种模式有无弊端呢？--有！临时加入的需求排不过来怎么搞？开发时间延时交付不了需求被喷怎么办！一天站会这么多？！
那有什么解决方法呢？--尝试另一种敏捷模型，kanban管理。为了解决敏捷模式中遇到的瓶颈，考拉技术开发小分队实践了kanban管理，由此对敏捷有了新的认识。

一、scrum的痛

scrum作为敏捷的落地方法之一，用不断迭代的框架方法来管理复杂产品的开发。通过其独特并固定的管理方式，从角色、工件、和会议出发，保证项目的不断优化。
在落地过程中，需要与团队的具体情况结合，不然，就可能会衍生很多问题:

项目估时不清晰：由于scrum没有具体交付日期，需求方会不间断增加新的需求，导致开发团队整体进度延后，出来的效果不尽人意；
团队分工不清晰：product owner无法清晰知道每个需求的进度。

scrum模型多适用于职能单一的团队，他们能够较好地管理需求，团队内部分工也较为清晰，product owner也可以更加合理安排内部分工。
那么对于经常周旋于不同任务之间的开发团队呢？kanban管理或许能够解决开发团队的问题。

二、kanban管理的起源

kanban管理最初起源于20世纪40年代末，是丰田汽车公司为了达到及时生产（JIT）方式控制现场生产流程的工具。
JIT生产方式与拉式开发理念不谋而合，具有以下优点：

控制库存：下游需要时上游才开始生产，有效控制库存；
加速流动：进入生产环节的物料和半成品，很快就被拉入下一环节，实现了保证安全库存的前提下物料最快流动，提高工程的运转效率；
灵活响应：用户需求变化通过看板行程的信息流快速传递至各个环节，系统能够做出快的响应；
促进改善：库存降低和流动加速，能够使生产问题快速暴露，比如生产环节的质量问题很快就会被下个环境发现。 JIT认为库存会带来商品的堆积，导致成本的增加，它鼓励企业逐步消除库存，以减少生产过程中的成本，逐步达到"零库存"状态。

三、kanban管理的优势

基于kanban管理的工作方式，能够将商品的库存量和实际消耗量对齐，只有当库存消耗殆尽才会发出信号，让生产端开始交付新一批产品。在降低库存下，降低了库存管理以及仓储开销，并能更加灵活地调整生产计划，及时发现生产过程中的问题。

四、敏捷开发中的kanban核心和原则

可视化工作流(价值流）；

kanban管理让产品的价值和价值流具体可见，工作流分为不同的阶段，每个阶段的需求都代表了不同的价值，一个需求从开始提出，经过分析、实现，测试，到最终完成，其价值不断提高。因此产品的价值流是从左至右不断提高的过程，也是信息的产出过程。
价值流中，用户价值是可视的，开发团队要清晰每个需求的用户价值,从用户的视角去组织；其次，价值从提出到交付的整个过程，也应该是可视化的；最后，问题以及block也应该可视化。在价值流中会存在一些需求不明确、开发难度大等问题，不及时处理容易堆积成长队列，影响开发效率。随着价值流动，开发团队可以及时发现项目中的问题，找到队列最长的阶段就可以发现问题，这跟交通系统的瓶颈处总是出现长长的候车队是一个道理。

限制工作进程（WIP）

WIP指在对某一个环节内的所有工作（包括正在进行以及等待安排）的进行数量上的限制。若在环节内在制品数目未饱和，可以从上一个环节加入新的需求，否则维持现有需求数量不变。通过这个环节，团队可以更加专心开发目前的项目，缩短任务从进入系统到交付的时间。同时及时暴露团队协作存在的问题，如沟通不良、需求定义错误、开发难度大、资源分配不均衡等。

显示化流程规则

通过明确的规则，可以对整个流程不同阶段的产品质量进行把控。在前一个阶段的开发质量满足了“流转规则”之后，方可转入下一个开发阶段。
开发团队需要对即将落实到位的规则展开讨论并达成一致。通过这个步骤，开发团队可以“持续改进”产品的流程以及质量，不断优化产品。

管理工作流动

为了让用户价值顺畅、高质量地流动，团队需要管理好价值的流动。一般包含三项实践：用户价值的输入、中间过程以及输出。
1）用户价值的输入：这是看板系统输入环节和价值流动的源头，输入清晰、明确的用户价值能够促进价值流流动，提高开发质量；
2）用户价值中间过程：站会是管理价值流动过程的活动，开发团队每天都会安排站会，由团队成员对看板墙中的卡片进行排列，梳理每个用户价值的完成进度、遇到的瓶颈，并解决这些问题；
3）用户价值的输出：用户价值在完成交付出去前，需要发布评审，产品经理决定上线或发布哪些需求以及发布需求的策略等。
为了对工作流进行有效管理，引入了一种度量方式--累积流量图。绘制累积流量图可以得到不同维度的信息，更形象曝光工作流中存在的问题。

5. 建立反馈，持续改进

基于价值流动，kanban管理形成了一套反馈体系，大体分为两类：一类是基于流动是否顺畅的反馈，比如阻碍问题分类、原因分析；第二类是关于用户价值质量的反馈。建立反馈系统可以让开发团队度量价值流动的状态，发现工作流中的问题，不断改进整个工作流模式，形成持续改善的闭环。
既然建立反馈体系能够暴露产品开发中的问题以及瓶颈，那么发现问题后，如何解决问题呢？kanban管理推崇2种方式--团队协作以及应用科学模型。
对于偶然出现的问题，可以通过团队协助的方式得到解决，如分配更多的资源、成员的相互支持等；而对于系统性问题，需要系统、科学的模型进行指导，通过这些方式可以不断提高团队持续改进工作流的能力，进而提升整个团队的价值交付能力。

五、kanban管理工具

基于开发团队的需求，可使用jira的kanban工具；
kanban工具有如下的功能：

不以sprint为单位，团队一直都只用一个看板，无需每周关闭和开启sprint；
kanban管理一共分为8列：
● 创意：产品经理收集需求加到这一列，可以不以user story形式描述； ● 正在分析：产品经理正在分析的需求拖动到这一列，此时可以将创意的card拆解成几个user story；
● 下N个需求：产品经理不断调整任务优先级，将即将要开发的需求拖动到这一列，这一列任务数量有限制，任务太多将会让开发人员负荷过大；
● 正在开发：开发人员将正在开发的需求拖动到这一列；
● 等待测试：开发人员将开发并自测完成的需求拖到这一列，测试人员对这一列的需求进行测试，这一列任务数量有限制，任务太多将会让测试人员负荷过大；
● 正在测试：测试人员将正在测试的需求拖动到这一列；
● 等待发布：测试人员将测试完成的任务拖动到这一列，开发人员对这一列的需求进行发布，产品经理验收；
● 已发布：开发人员发布完成并验收完毕后，将任务拖到这里，并点击Relase记录此次发布的版本，这些任务将会不显示在看板上。
任务下方会显示该任务停留的天数，以提醒团队注意该任务；
Relase功能，可以清晰看到每次发布的功能；
report里面有很多图表，看板方法最常用的应该是堆叠图，可以看到各个阶段任务的数量，以了解整体的情况。

小结

在进行了kanban管理的实践后，成员了解各个需求的进度，开发团队的开发效率有了提高，就算临时插入需求，也能根据优先级调整应对。
在敏捷实施中，适应公司的情况，发现合适的开发方法，一直是令人头疼的问题。kanban管理给出了一种新的方式，从产品开发现状出发，首先可视化工作流并显示化流程规则，接着通过限制在制品数量，推动开发团队发现工作流的问题以及瓶颈，最后通过反馈系统以及团队协作等方式，不断优化工作流，提高团队的开发效率，实现一个高效、顺畅的产品开发工作流。
对考拉的dev而言，kanban管理是一种新的尝试，也希望这种新的尝试能够给更多dev带来更多实践上的革新。

参考资料：