精益看板在建立阶段的工作纲要(2月20日更新完)

一、有必要对何勉的表述进行补充阐述之处:

1)何勉所举企业网盘开发的案例中,原始做法的本质问题并非是前、后端的划分。事实上,进入开发后,最终必然会需要做前、后端的分割。问题之要害是"过早"的进行了前、后端划分;从尽量体现用户价值、让用户价值充分流动的原则角度,更为合理的做法是尽量延后前后端的任务分割,让尽量多的环节是能明确体现用户价值的,不到迫不得已,就尽量别破坏对用户价值的可读性体现(只要能保持用户价值的可读,是允许拆分用户价值的,譬如将一个需求拆分为几个用户故事) 。更进一步理解,其实就是对“将用户价值可视化”这一条原则的体现,即让用户价值在尽可能多的环节中可见(可视、可读)

2)该案例的原始做法没有反应团队协作过程。项目经理成为需求、bug等工作的协调枢纽。精益敏捷的一个核心诉求是实现用户价值尽量“顺畅无阻的自动流动”,所以应该尽量减少工作中出现”枢纽“节点,无论是看板墙上还是看板墙之外。一定程度上,又是”去中心化“的体现——从用户价值需求输入到用户价值输出兑现的全过程去中心化。当协作规则、价值流动规则不清晰、未全员形成相同理解时,就会出现依赖于某个人来协调的”中心化“倾向,该中心就很有可能成为价值流动的瓶颈所在。

因此,何勉才对该做法进行了改造,设计出文中的新看板系统。

3)控制在在制品数量的理由”束水攻沙“,将“水”解释为团队力量,“束水”解释为集中团队力量,似乎更为直观些。

二、看板墙示范模板

以下是基于何勉案例整理编制出的看板墙示范模板excel,源文件可从网盘下载:https://pan.baidu.com/s/1HEWSEQS2VwrDvB4K18cKrg 提取码:fi8c)。由于一张整图不清晰,这里截成前、中、后三部分贴出。

看板墙示范模板-前段
看板墙示范模板-中段
看板墙示范模板-后段

三、看板系统建立过程中的一些方法、要诀收录

1)需求抛弃区;

2)用不同颜色、大小的卡片代表不同类型需求;

3)分别设计需求和任务的卡片模板,打印;

4)统一粘贴标识语言(什么代表紧急、代表重点等),形成统一的符号语言体系;

5)定义初始规则、充分传达规则、持续迭代规则。规则显示化(明文化),才能通过规则的版本迭代,实现规则的改进。

       需要显示化的规则可以归为三类,例如包括:需求的准入条件是什么;优先满足哪类需求;怎么应对紧急需求;移交给测试前,需求要达到怎样的质量标准;短期进度和长期质量冲突时,如何决策;多长时间进行一次需求排期等等。

6)三类主要规则:价值流转规则、周期性事件相关的规则、其它日常协作规则。

      价值流转规则:譬如需求可以开始分析的接收标准;需求进入就绪的标准;代码提交和任务完成的标准;功能转测试的标准;功能提交验收的标准;需求发布的标准等等。

       譬如需求进入就绪(故事队列)的标准,包括大的原则和特定团队自己特有的内容。其中大的原则有:已识别业务风险、关联风险、技术风险,并作出应对;需求不不能太大。(特定内容则参考原文中示图)

       看板方法中主要的定期事件有:每日站立会议、就绪队列填充会议、产品发布规划会议,以及定期的改进活动等。(在规划方案阶段,可以明确罗列出这些事件)。可用时钟标记。需要明确它们的节奏、内容及相关规则。以就绪队列填充为例,团队需明确:1)事件的频率;2)事件进行开展的方式,如:要完成哪些目标,和大致的流程;3)适用的规则,如怎么选择需求,一次选择多少需求。4)例外情况,如:正常的就绪队列填充节奏之外,出现紧急需求如何应对。

      日常协作规则,如:看板墙的更新和可视化规则;在制品限制的规则;度量、反馈的收集和分析机制;改进行动的制定和跟踪规则等。初始时,可以先只明确那些影响较大的规则

7)将看板可视化准备好,达到傻瓜化,让团队们直接往里填具体项目内容、可直接用的状态,无需再为物料、规则花费精力的程度。

8)限制在制品数量。该上限值取多少适宜? “偶尔达到,但不总是达到”,所谓“偶尔达到”,每一到两周达到上限一次,是一个合适的初始值。

      控制在制品的数量,只是“果”,实现控制需要有端到端的思维,要从“用户价值流动”的视角,不能局限于一个环节上。

9)在制品数量的限制,可以不一步到位而是先松后紧,逐步调低"水位",从而所揭示的问题也先简单容易再复杂困难。(流过看板墙的应该是连续不断的一批需求)

10)要以用户价值为单位控制在制品数据量。在制品数量不等于任务数量!控制在制品数量不等于控制任务的并发数!

11)限制在制品数量的方法:通过限制泳道数实现、通过限制特定阶段最大需求数(譬如待测试的需求数)实现、通过限制每个人并行任务数实现。

12)关于在制品数量限制的初始值设定,方法有:对现状进行看板可视化后得到、基于团队人数进行估算、利用利特尔法则从目标交付周期导出(在制品数目 =交付周期 * 交付速率)

13)解决在制品的阻塞问题,首先是一定要将在制品可视出来。在制品队列阻塞,是致使产品开发低质低效的最重要因素。

四、需要解决的疑问

1)泳道里什么时候可以拉入新的任务? 是等整个泳道行(或整个模块列)空出才能拉取, 还是只要有空格出现就能拉取?

2)最终的验证、验收环节都是以“故事”为单元,不进行合并为用户需求的动作?与看板流程发起前期的环节不对应,不回到"用户价值"?

3)以目前的看板架构看,对如何体现用户价值这一点似乎还未充分体现。比较明显,这个是偏开发的流程。需求设计、产品设计阶段还应该有对应的细分流程。

4)看板是基于每个项目进行个性化设计,还是各种项目统一?(早期可以一对一设计,逐步确定一些后续哪些可共用,哪些需要个项目自己做)   如果看板形式是不那么确定的,那么价值流转的规则又如何提前明确呢?(从A环节到B环节的规则,连A、B的名称/内容都不固定,怎么确定A到B的规则?) 所以一个办法是先找一个案例,写一个示范(包括初始规则、初始手册等),然后基于案例示范和响应的初始手册尽早启动真实的试点项目,在试点中再确定后续工作(对“后续工作”能否做出初步预判和初步的具体安排?不能完全一抹黑)。  此外,对于一些可以提前相对确定的环节,可以提前形成初始的通用规则。 再有,先明确影响大的重要规则。

      从在制品数量可以先松后紧来看,看板墙是针对"团队“的,一个(或一类)团队,或一种类型需求,用一种看板,这样在制品就是能够由松到紧进行变化的。总之,流过看板墙的应该是一批接一批的需求,而非单一个需求

5)如果造成阻塞的问题本身很棘手,在限制在制品的情况下集中团队力量也没法很快排除,怎么办?



附注:

(只列原文标题,跳出链接太多会被平台封号;主要参考何勉的公众号,看板方法实践体系)

原文一、实践一(上):可视化价值流动——案例

原文二、实践一(下):可视化价值流动——实践

原文三、实践二:显式化流程规则实践

原文四、实践三(上):控制在制品数量——束水攻沙

原文五、实践三(中):控制在制品数量——暂缓开始、聚焦完成

原文六、实践三(下):控制在制品数量——湖水岩石效应

你可能感兴趣的:(精益看板在建立阶段的工作纲要(2月20日更新完))