关于看板的思考与总结
https://mp.weixin.qq.com/s?__biz=MzkwNTI2NjAxMA==&mid=2247483726&idx=1&sn=6e7c07bdc9292027467e0796490f6baf&chksm=c0fb177bf78c9e6d54fdfd1724baa46cc2cbc86da2353b00f3956a87a45af8713ffe45d2f18a&scene=178&cur_album_id=1979309913222742017#rd
看板活动是敏捷中非常常见的一项活动,它是用来发现组织内部流程瓶颈的一种高效方式。通过看板的流程和工作内容可视化,可以很快发现整个流程中可能存在的问题。因为工作上的需要,最近重读了《看板实战》一书。结合最近两年在工作过程中的使用,有了一些新的体会,也发现了过往在使用看板中的一些误区。本文通过总结和思考,为未来团队的敏捷化转型做一些指导。
NO.1
为什么优先使用看板来导入敏捷的理念
首先,内容相对轻量,核心只有三大原则:可视化、限制在制品、管理流动。
其次,不改变任何流程,只让流转规则可视化,让每个人的分工透明化,不会给团 队带来新的负担;
再次,通过看板的可视化,让团队决策的可视化,当我们关注看板反馈出来的“味道”时,很容易让成员理解团队的决策以及要解决的问题;
最后,看板活动不需要增加额外的角色。现有的团队成员就足够完成。
因为看板活动内容的轻量,很多人在给团队导入看板活动时,喜欢给出明确的信息,例如应该使用什么样的工作流,卡片应该怎么画,准入准出应该是什么样的。其实这样并不友好。每个团队当下的流程和所需要展示、处理的问题不一样,应该和团队一起共创属于当下团队最适合的内容,在逐步改进的过程中向一些最佳实践去靠拢。除非你对团队的掌控程度很高,否则容易引起团队的对抗性,导致效果不理想。
NO.2
关于在制品(WIP)的定义
书中关于在制品的定义如下:指你手头正在处理的所有事情,包括正在处理的任务、等着被验证或者部署的工作项、还有那些虽然还没开始处理,但已经等在你的收件箱里的事情。这里要注意的是“所有事情”,在实际的工作过程中,我们会额外处理一些非常规的工作项(大量的会议,迭代外的工作、沟通,流程任务等等),虽然不在迭代规划内,但会大量占用你的时间,最好也在建立一类工作项(卡片),让团队成员清楚你在做什么。
在之前的团队中,我差不多有40%的时间用于编码,还有60%的时间用于处理团队其它事务,这会导致在团队的看板中,每个迭代我只有20~30个估时(正常每个迭代成员的估时数在48左右),在观察看板给出的反馈时,好像我一直是“空闲”状态,这样不管对团队决策还是拉动卡片(解决阻塞或者处理时长过长的卡片)都是不利的。所以需要增加一类工作项,把我的所有工作都显示化,也有助于我自己安排优先级。
NO.3
在制品过多带来的影响
在制品过多,也就是你手上的任务过多时,会带来一系列的问题:
1)频繁的任务转换带来的资源消耗(上下文切换):因为你需要记住当前任务的状态,以便下次回到这个任务时,能够知道处理到哪了(像不像CPU的工作形式),为什么多数程序员喜欢戴耳机?不是因为他们多么喜欢音乐,只是纯粹的不想让人打扰罢了。
2)延迟带来的额外工作:因为任务大部分是延续性的,如果不及时处理,时间一长,往往你自己都不知道当初的具体情况是怎么样的了,为什么要那么处理,导致很多延迟的决策会变的不清晰(例如BUG的解决)。
3)缺少动力:这个很明显,当你看到一堆的待办时,总不会自觉的告诉自己,反正还有那么多事,一时半会也做不完,那就不着急处理。而且会影响其他人的工作进度,因为研发活动会涉及到很多联调、依赖的事,如果某个卡片停滞了,会影响其它人的进度,导致更多的消极情绪蔓延。
4)书中还提到了其它的影响,如增加风险、质量下降等,个人认为影响最大的就是前面三点。
NO.4
限制在制品的活动
前面我们了解了在制品过多的影响,那我们是不是可以限制在制品的数量呢?是不是越少越好?在理想情况下,我们希望做到“单件流”,每个人只处理一件事,上下游顺利无缝对接。在实际的研发活动中,过少的在制品会引起人员的闲置,我们不太可能所有的研发员都投入到一个功能的研发中去(想象一下所有人都去做登录,每个人写几行代码?不可取),过程也会遇到小时间段的阻塞(前后端联调不顺利,后端有人开会去了等等),那就停下来?所以,在制品过少也不行。所以为团队选择合适的在制品数量就成为很大的挑战。书中给出的建议是:团队协商,一般情况是人数*1.5,在最开始的时候,可以选择一个数,试运行一段时间,找出合适团队的在制品数量,当团队成熟后,以20%的速度降低在制品数量,加速流动。
在团队实践过程中,我们更应该关注瓶颈处的在制品数量,所有的工作流程都会存在某个瓶颈,而瓶颈决定了整个工作流的步伐。如果提高瓶颈上游的吞吐率,工作就会在瓶颈处排起长队。在这种情况下,提高瓶颈下游的吞吐率毫无用处,因为这里不会有足够的工作输入。例如我们通常说在敏捷研发活动中,测试最容易成为瓶颈,那就优先提高测试活动的效率(引入自动化、测试左移等方案)
NO.5 关于利特尔法则的使用
在讨论WIP时,不可避免的会说的一个公式:
从这个公式可以看出来,在团队初期,我们很难改变吞吐量的情况下,可以通过减少在制品来的降低交付周期,我们一般会通过对需求端的优化来解决,比如拆分更细粒度的需求,每次交付较少的增量,增加交付频次,来提升团队的信心。
当团队逐渐成熟时,我们的交付周期也会相对固定下来(2周),这时候再降低交付项就不合适了,需要我们提升吞吐量,改进效率。这时候通过看板我们可以很清晰的发现流程的瓶颈点在哪,并加以改进。
NO.6 关于站会和流动
看板上的卡片只有流动起来,才能产生价值,所以我们要关注卡片在通道中停留的时间,限制在制品有利于流动,提高资源利用率。所以在每日的站会上,我们更应该关注右边的卡片,关注卡片是否流动到了最右边(价值现实,一般是待发布),如果卡片还没流动到最右侧,则需要关注原因是什么,是否形成了阻塞。这个和Scrum中的每日站会的三个问题(昨天,我做了什么?今天,我要做什么?我遇到了什么问题?)有些不同。从看板上我们可以很清晰的看到你做了什么。更关心的是遇到了什么问题,卡片为什么还不能流动。
在团队实际的实践过程中,对于每日的站会,我们还是遵循Scrum的玩法,回答三个问题,我们往往更关注的是人,这个有点不太对。我们是否更应该以故事为维度,关注卡片是否移动了。当我们聚焦于人的时候,往往发现不了看板反馈出来的“味道”。因为最终要交付的不是个人的工作量,而是故事。是否可以有新的尝试。期待后续的实践。
在每日站会时,我们还要可以思考以下几个问题,让站会的意义最大化:
1. 我所有的工作项都在看板上了么?
2. 我们在做正确的事么?(推进卡片流动,交付价值)
3. 我们还可以做哪些改进项呢?
NO.7 度量指导改进
最近研发效能的度量一度引发了各路大神的各种讨论,但在大方向上,还是比较一致的,就是关注团队指标,轻个人指标。书中给出了几个看板实践下的常用指标,我记下了团队几个常用的指标:
前置时间=完成整个流程所需要的时间
吞吐量=完成的卡片数量
准时率表现=是否遵守了承诺的发布时间
质量=能否保证质量的发布价值
我们可以根据一段时间内,这些指标的变化来评估团队是否在有序的前进。切记不要在不同的团队之间做比较。因为每个团队都是不一样的。我们需要评估的是我们的团队是否比之前做的更好了。
同时,度量本身不是改进,它只是让问题显示化,所以,我们不要以度量来考核人员,更不能因为度量数据的波动而惩罚成员。否则你将会受到来自度量的反噬(为了度量而度量)。度量的数据是用于过程的改进。
书中还提到了两种强大的可视化方式:变异理论和累积流图,有兴趣的同学可自行查看(我比较熟悉了,就不在这里展开)。
NO.8 看板陷阱
书中给出了几种使用看板的常见陷阱,很有意思,也是我们在实践看板中经常会遇到的问题,这里只列两种,有些需要额外的知识点,在这里不展开,有兴趣的同学自行查看。
第一种:看板最终会变成永不停止的工作流——只有工作,工作,工作。通过增加必要的评审、回顾和计划的节奏以保证这不会发生
我们之前的团队就陷入了这个陷阱之中,大家对于看板逐渐变成了事务记录器,不再反思,不再推进。我们需要有回顾,有庆祝,甚至于有惊喜。
第二种:因为看板只有三个简单原则,没有规定太多东西,这有时会成为停止尝试有益实践的借口,从而使你变得懒惰。
我们使用看板来显示化流程,更希望通过看板来推动问题的解决,在敏捷化的过程中,我们还会有很多有意义的实践可以融入进来,而不是说这不是看板的内容,我们就不玩了。
NO.9
未来团队规划
对于新团队的期待,总结起来其实就三个句话:
以看板为切入点,发现问题;
以Scrum为实践路线,解决问题,提升效率;
以DevOps为长远目标,真正实现敏捷转型
NO.10 停止启动,聚焦完成
最后谈一点,也是个人在这本书中学到的最核心的一点:停止启动,聚焦完成。不是“你开始的越多,就完成的更多”而是“你结束的越多,才完成的越多。”只有完成的事务才能产生价值,切记不要有太多的半成品停留在手上。
书中还有更多有价值的观点值得大家一起来讨论,在公众号中回复“看板实战”,可以下载电子版。期待你读完之后,可以一起进行更多关于看板的讨论