DevOps读书敏捷之旅

看板方法读书笔记和团队落地建议

2017-12-08  本文已影响14人  撒哈拉的海马_敏捷

什么是看板:

看板简单点说就是一个信号拉动系统,所谓拉动的产生是因系统限制了在制品的数量,只有空余产能的出现才拉入新的工作项。

为什么使用看板:

我自己比较认同这个理念,定期可信赖和高质量的发布软件所带来的价值和客户度满意度一定比快速发布质量低下软件更高。

看板的几个阶段:

1、可视化任务(其实主要就是任务跟踪)

2、价值流转化和体现(描述和转化实际的工作流程,并对在制品进行限制以及一系列的实践活动,程序关注任务的流动)

3、持续改进看板(我的理解是,在应用的过程中根据实际的团队发生行为,针对缓冲区,在制品限额、服务分类,产能分配等一些列的实践来改进看板和工作流)

频繁的输入需求变化和优先级变化详细需求估算没有价值。

看板的实施秘诀:(针对每个阶段我们要切入一个具体的工作事项)

专注于质量(DoD,增强对自动化测试的投入)

减少进行中的工作(在制品限制)

频繁交付

根据交付速率来平衡需求

进行优先级排序

消除变异性提升可预测

我认同作者的一个观点,建立工作节奏、降低变异性、提高可预测行,来增加“富余”时间,在“富余”时间的前提下促团队成员的持续改进和优化工作流程和工作方法。

看板的价值:

1、可视化工作流程

2、通过在制品的限制建立拉动的节奏和发布节奏

3、因为限制使得瓶颈的产生,也能驱动大家更快捷、更频繁地进行富有挑战性的互动

4、看板的停止生产线机制,能够鼓励整个价值流中的人员产生群策群力,攻克难题的行为

5、最重要的一点是,促进持续改进文化的形成

实施看板的方法:

1、价值流映射:

前期的关键是怎么从当前的工作流程中映射一个工作流程到看板上,以最小的变动引入变革。

主要是定义基本的工作环节,如需求(未分析|已分析)、开发(待开发|完成)、测试(待测试|已测试)、发布。

2、定义基本的工作项类型:

需求,缺陷,维护工作,技术债务等等。

后面在实施的过程中根据经验来优化流程。

3、定义看板的起点和终点

这个团队开会的时候,会过看板上的内容。大家觉得是按从左到右过,还是右到左的顺序更好呢?答案是从右往左,原因是我们的最终目的是完成需求,而非开始需求,工作流越靠近用户约有价值。

开始是一件非常简单的事情,但团队交付的速度是完成速度决定的,要赶快把这些接近完成的完成。从右往左,优先完成已经开始的需求,有问题及时解决问题,这也体现了用户价值的拉动。

4、每日站会

针对看板的站会,主要是为了拉动价值流动,同时也起到scrum站会的目的之一,促进交流协作。每日站会优先从后往前看看板。并说明昨天的工作进度,今天的工作计划,以及遇到什么阻碍。

5、任务队列填充会议

任务需要细化并确定优先级才能导入到看板中,此会议主要是确定优先级,并且尽量以固定的频率定期召开。

会议的干系人尽量是业务提出方、产品负责人和团队成员一起。频率根据各自的实际情况,要考虑到自己的迭代发布周期。

6、建立一定的交付节奏

此处要考虑具体的交付成本,也推荐固定频率来交付

7、设置在制品限额

在制品限额的限制方式可以有多种方式:

a、以团队中每个人的最大同时可工作任务为基数,变相限制在制品

b、直接设置看板总的限制品数量

c、针对不同的环节设置限制品

d、针对不同的服务类型设置限制品和产能

主要要设置缓冲区,前期的操作不需要关注此,带运转一段时间后根据各自的实际情况来加入

8、服务分类

服务分类主要体现在不同的工作类型设置不同的产能。

比如我们的实际情况:

a、每日维护和支撑任务

b、固定交付日期的里程碑任务

c、基本的变更需求任务

在大家设置此不同的产能分配时需要考虑不同的类型,前期可以先不用考虑,后期慢慢深入和优化自己的流程时再接入。

9、度量

度量有几个指标,如前置时间(需求从进入到交付的时间),准时交付率,问题和受阻工作项

我这边现在主要是通过累积流图来进行基本的分析和度量。

看板方法读书笔记和团队落地建议 看板方法读书笔记和团队落地建议
上一篇下一篇

猜你喜欢

热点阅读