在某微信群中,有小伙伴儿问了这么一个问题:

在看板的状态流转的时候,大家觉得是否把交互视觉设计等状态也体现进去呢,还是一般都从需求都明确了,从开发开始呢,因为前面的交互与视觉等不是按story细分的,不适很好跟踪。

下面是各位专家大牛给出的解答:

首先,进一步确认问题,

意思是:看板是从产品设计就开始管理还是从研发阶段开始管理?

补充信息是:

产品的原型设计和交互视觉设计过程是否要体现在看板的状态列中

于是,大家开始了热烈的讨论。

可以把Story和看板结合起来用,其实在看板里的每个item都是一个story。

无论是Scrum Board,还是看板,无论如何,建议你将产品设计阶段的流程/状态,也放在看板里管理要管就从产品的整条链路管起来,而产品设计和研发就是两个比较核心的阶段,一起放看板里,可以清楚看到瓶颈在哪里,产品,还是研发?

放进去有点奇怪,因为prd和交互大多不会一个个story去做,会一批需求去做,所以操作起来可能还是等prd出来后再分解成一个个story合理的样子。

只能给你个倾向:尽可能全面覆盖价值流。要考虑实际情况的限制。是否可视化成列,取决于是否要通过这列指导你解决问题。

一批一批做是现状,有没有问题呢?是否需要改进呢?如何改进呢?

这几个问题在明确改进方向同时,还会激发进一步的思考:怎么样通过看板设计和数据反馈来指引团队向目标前进呢?

现在这样做我认为没问题的,我的问题是想给团队做看板视图的时候怎么才能也体现出来前期的设计阶段呢?因为设计是大功能,开发对应的是大功能分解出来的小需求,这个维度不一样,怎样设计到了一个看板上更合适?

大功能是什么,小需求是什么,它们之间什么关系吗?为什么要放到一个看板上?

我来分享一下,你可以在kanban上表现出最近的三个backlog,这样,大家看得到最近三个迭代做哪些。然后,关于你说的大功能小功能,我的理解就是feature特性和拆分后的story吧。你的大功能可以继续用这个title或者编号id,小功能的卡片上,标注一下是来自哪个大功能的id编号。这样是否可以满足您的需求呢

我们过去的实践上,也可以把编号和jira上的主卡和子卡对应起来。

如果你不想做三个迭代的backlog,那么,简单些来说,你的大功能移动到implement 的栏后,其他小功能都跟着移动,但是直到小功能全部移动到testing栏,大功能才能移动。这种我们仅碰到8分以上没有拆分卡的时候,会这么做,一般feature以后,都是拆分的,也自然看不到大功能的移动了。毕竟不拆分的大功能都是风险

feature的设计阶段要不要体现在板上呢?

具体应该在backlog中体现,在你墙上的设计应该是feature被break down之后的story的设计,大型的feature 理应是做不断的refine梳理和break的。至于体现,我会建议体现在墙上,打散break之前,我们做spike,调查怎么做,如何拆分以及技术难点,现状分析。所以可以是前一个迭代不做实施,后一个迭代需要打散并且分析梳理后的拆分后story。如果你对这个迭代有信心,也可以一张做spike,另开一个实施的卡。方法很随意。用看板我们的过去实践就是,所有可追述的工作都应提现在墙上。

—— 剧 终 ——