精益看板方法从理论到实战 (2)—— 可视化价值流动实践(上)
帮助中心 > 敏捷开发
精益看板方法从理论到实战 (2)—— 可视化价值流动实践(上)

这篇文章详细介绍了精益看板的可视化价值,理论与实践结合,是少见的好文。推荐给大家!鱼骨精益敏捷项目已经上线,多维度清晰直观的看板管理,透明化的项目整体综合展示,以及Bug管理、文档管理等功能欢迎您的使用!

作者:何勉

来源:微信公众号精益产品开发和设计(微信号LeanAction)


本篇将介绍"可视化价值流动“,如下图所示,它是所有看板方法中第一个也是最基础的实践。

本篇开始介绍看板方法中的第一个实践——可视化价值流动

我们将从一个重新设计看板系统的案例开始,帮助大家理解看板系统和看板墙设计的原则。

2.1 团队背景介绍

这是一个初具规模的创业公司的创新团队,为行业客户开发本地部署的私有网盘产品。团队当时共有开发测试约30人,以及负责不同行业及总体负责的产品经理共6人。我之前辅导过他们需求和测试实践,团队基本能贯彻敏捷需求方法,较为持续的交付用户价值;接口自动测试能与开发同步完成,并做到接近100%的功能覆盖。但总体上团队的交付能力满足不了产品的需要,内部协作略显无序,质量也有下滑趋势。

企业网盘开发明显分成两类技术,一类偏底层,如:分布式文件系统,集群管理,以及包括性能监控、负载均衡等在内的底层服务等;另一类偏前端,如:与PC资源浏览器的深度融合,Web应用开发,IOS和Android移动客户端开发等。前、后端在部署上相对独立,技能上相差很大。所以团队很自然地被分成了前端和后端两个团队,各自有所属的测试,并分别按两周的固定周期迭代开发,看上去比较敏捷。

2.2 初始的看板系统设计

团队的初始看板设计

上图是团队看板系统的初始设计,前、后端团队各自用Jira [1] 构建了看板墙,另外还有一个独立的Bug管理系统。

看上去不错,任务从左往右流经各个阶段,状态清晰,分配给谁也一目了然,团队成员能很方便的了解自己要做的工作。但,它也有明显的不足。

首先,看板系统对产品经理不友好。用户需求被分解成前后端团队任务,在各自的看板上流动。一旦分割,产品经理就很难再找到对应的任务,也不再关注这些任务。上图中“视频文件在线播放”这个用户需求,就被拆分成了前后端的任务,各自管理。对产品经理不友好只是表象,产品经理代表的是用户,问题的实质是:“这个看板系统并没有反应用户价值端到端的流动过程“。

其次,它并没有反应团队协作过程。需求被拆分成前、后端任务后,一般后端团队先行开发,在迭代中安排自己的任务,而前端团队则滞后一个迭代,以便基于后端提供的服务集成和联调。由于任务之间缺乏关联,团队间的协调,相当程度要依赖项目经理的协调,这其中既包括计划的同步,联调的安排,也包括问题的界定和Bug的处理等。例如:测试过程中发现的后端Bug,通常是前端团队过滤后再转过去的,而后端这会儿正在开发下一批需求。新需求和老Bug哪个优先级更高?我们当然希望优先解决Bug。而事实却正好相反,新需求一般有明确的期望完成时间,而Bug却没有,再说bug多没意思,这时就需要项目经理来重新安排,项目经理成了团队运作的枢纽。

最后,它不能即时和清晰的展示问题和瓶颈。没有清晰展示价值流动过程,导致价值流动中的瓶颈和问题也不能很好的体现出来。比如我们无法从看板墙上看出哪些用户需求出现了停滞,那个环节是瓶颈。这些问题更多的存在于团队及个人之间的协作中,而不是单个人或单个团队中。

2.3 看板系统的重新设计

质量管理之父戴明说过:“如果你不能以一个清晰的过程展示你所从事的工作,你就不知道你在做什么”。这句话用在这个看板系统上是合适的,正因为没有清晰的展示,团队就无法基于它协作交付价值,瓶颈和问题也无法即时暴露。

戴明是质量管理之父,也是“系统思考”的布道者,他的很多思想即使在今天敏捷和精益的背景下,也充满真知灼见

为解决以上的问题,我与团队一起重新设计了看板系统。下图是改重新设计的看板系统。这一次我们用了物理看板墙,并把前后端团队的看板墙进行了合并。让我们从左到右,来解释一下它的设计。

重新设计后的看板

  1. 原始需求的提出:左边的蓝色卡片是原始用户需求,产品经理对它们简单地归并、拆分和过滤后,统一放入需求池(pool),等待进一步处理。

  2. 需求的设计:产品经理团队从需求池中选择优先级较高的进行产品设计,决定要不要满足该需求,以什么方式满足等。设计完成的需求,进入待澄清列,等待与开发团队澄清。

  3. 需求的澄清和就绪:每周,开发团队和产品经理进行会议,选择适当数量的高优先级需求 [2]进行澄清,充分讨论和更详细的描述这些需求,确保产品、开发和测试对需求达成一致的理解[3] ,并明确定义验收标准,需要时还会对需求进行拆分。经过这一步处理,原始需求被转化并称作故事(story) [4] 。为了区分故事和原始需求,团队不再用蓝色纸条,而是用白色的纸条来代表一个故事,从这一步开始,产品经理也将基于故事来跟踪和沟通和验收需求。故事放入“就绪”列等待实现。

  4. 故事的拆分和开发实现:经过充分沟通后“就绪”的故事随时可以开始实现。开发要做的第一件事是分解它——前后端团队在一起,将工作分解为子任务。图中蓝色和黄色纸条就是这些任务,它们隶属于不同的模块,分别是后端的数据、集群和应用模块;前端的Web,PC和Mobile模块。注意,这些模块虽然从左到右排列,但他们之间是并列的没有先后关系。蓝色的是开发任务,黄色的是接口自动化测试任务,这也是黄色纸条只出现在后端模块的原因。所有的子任务和它们所属的故事被放在同一行,称为“泳道”。其中,最下方一条是技术泳道,放置并非直接来自用户的工作,如:代码重构和技术预研等。

  5. 故事的开发:单个任务完成后被放入“实现中”阶段的最后一个子列——“完成”列,它代表的是子任务而不是故事的完成。一个泳道中所有的子任务都完成后,则对应的故事也就完成了,可以进入“待验证”阶段等待测试,这时子任务就可以从看板墙上清理出去,泳道也空出可以接受下一个需求了。现实中,对较为复杂的需求,团队会指定一个开发人员作为总体协调,在将需求移入待验证前,他会再次确认所有集成和自测工作都已经完成。

  6. 测试人员验证故事:测试人员从“待验证”列将故事拉入“验证”列进行测试,并用红色纸条标记发现的Bug,与开发人员沟通解决。测试工作完成以及对应的Bug被解决后,需求进入“待验收”列。

  7. 产品经理做最后的验收:产品经理定期验收实现和验证完毕的故事,确保其与最初的设想一致和解决了用户的问题,再根据市场的最新情况确定发布计划。

2.4 重新设计的看板系统发挥的作用

重新设计的看板解决了前文所提及的问题,但它究竟起到了哪些实际作用呢?下图反应了它的特点。

重新设计后的看板系统的特点

首先,它体现了用户价值端到端的流动。在这个看板系统中,流动的单元回归了用户的价值(需求),而不再是原先的任务。并且它反应了价值端到端的流动——从用户的问题出发,到交付用户解决方案结束。上图中,看板墙的最左边是代表用户的产品工作,中间是开发和测试工作,最右边又是产品的工作。

其次,它反映了团队协作交付价值的过程。团队工作的本质是协作交付用户价值,这个看板系统反应了这一本质,它包括了各个环节间的移交和等待;也包括实现阶段内需求如何被拆解成各个模块任务,拆分后子任务又是如何合并和整体移交的。这为团队基于看板系统协作提供了基础。

最后,它反应了价值交付过程中的缺陷、问题和瓶颈。问题和Bug即时体现到看板墙上,并与所属需求关联,促进团队更快的去解决。如果某个环节流动不畅,需求就会在该环节积压形成瓶颈,这为团队指明改进方向。例如:站会上团队从右往左审视每一列需求,当靠右的测试有问题或有Bug阻碍时会优先解决,而出现拥塞的瓶颈列也是团队要重点关注的。

这个看板系统的设计并无花哨,只是忠实反应了团队协作交付价值的过程。也正因为此,才更接近团队工作的本质。看板系统改造完,我问了团队以及负责这个产品的副总裁三个问题。

第一:看板系统能全面地反映需求交付过程吗?

第二:瓶颈和问题能在看板墙上得到即时体现吗?

第三:团队可以根据看板墙上的信息协作和做决定吗 ?

对这三个问题的肯定回答,一直是我设计看板系统的底线要求。前两个他们给出了明确且肯定的回答。第三个问题的回答则没有那么肯定,这个看板系统能提供了决策所需要的大部分信息,但团队要据此协作和做决定,还需要清晰的价值流转和团队协作规则。规则也是看板系统的一部分,这对应着看板方法的下一个实践——显式化流程规则,我们将在近期文章中讨论。

总结

可视化价值流动是看板方法的第一个实践,也是其它几个实践的基础。例如,常有人告诉我“控制在制品的数量”这个实践实施难度很大,但每次进行深入分析,往往会发现价值流还没有理清,要控制的在制品是什么都不清晰,又何谈控制?又例如,没有很好的价值流的呈现,又何谈显式化流程规则?何谈流动管理?更不要说持续改进了。当然可视化价值流动只是第一步,是比不可少的基础,看板系统的应用和运作,还要靠其它几个实践。

推荐您使用鱼骨精益敏捷项目,将上文中的理论落实到实际中,真真切切的让您的公司或团队体验精益敏捷项目所带来的高效,让工作快起来!


评论页面|
文章评论
发表评论

您还没有登录,请您登录后参与讨论:


 或 

京ICP备案证书号(京ICP备13026048号-6) Copyright 2013-2017 Yugusoft(Beijing)All Rights Reserved.

京公网安备 11010502036844号

  • 服务协议
  • 隐私条款