AI考拉技术分享会--kanban管理从实践到入门
发布于 17 天前 作者 kalengo 247 次浏览 最后一次编辑是 14 天前 来自 分享

前言

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

一、scrum的痛

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

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

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

二、kanban管理的起源

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

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

三、kanban管理的优势

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

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

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

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

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

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

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

五、kanban管理工具

基于开发团队的需求,可使用jira的kanban工具;
kanban工具有如下的功能:

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

小结

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

  1. 敏捷其实很简单(4)–初识看板
  2. 精益看板方法从理论到实战 (1)—— 看板方法和看板实践体系
回到顶部