AI考拉技术分享会--kanban管理从实践到入门

前言

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

1、scrum的痛

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

1. 项目估时不清晰：因为scrum没有具体交付日期，需求方会不间断增长新的需求，致使开发团队总体进度延后，出来的效果不尽人意；
2. 团队分工不清晰：product owner没法清晰知道每一个需求的进度。

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

2、kanban管理的起源

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

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

   

3、kanban管理的优点

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

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

1. 可视化工做流(价值流）；

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

2. 限制工做进程（WIP）

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

3. 显示化流程规则

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

4. 管理工做流动

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

5. 创建反馈，持续改进

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

5、kanban管理工具

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

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

   

小结

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

参考资料：

1. 敏捷其实很简单（4）--初识看板
2. 精益看板方法从理论到实战 （1）—— 看板方法和看板实践体系