0°

看板学问多,但是你却不知道……

写在前面

作为“敏捷”主题的最后一篇文

我在想是要轰轰烈烈的开始,还是平平淡淡的结束呢?

要不我来贴一张我的“腹肌”照片来拉个转发量?

嗯,算了,最近小婧“很受伤”。

我们还是延续之前敏捷主题的方式,以问答的方式来进行看板的介绍,尽可能的解答大家常见的问题

PS:同样的,如果下文有任何的名词看不懂,请翻阅“历史消息”里面的关于Scrum的角色和会议相关内容。





什么是看板Kanban?

有人说:“不就是在墙上挂个白板,然后在上面贴便利贴嘛!”

嗯,就像这样:

看板学问多,但是你却不知道……

其实对,也不对。

你贴在一张挂在墙上的纸上,或者直接贴墙上……也是可以的

哈哈,开个玩笑吼,别着急……

对:确实是把便利贴贴在一个介质上,进行任务的计划和跟踪

不对:不仅仅是进行任务的计划和跟踪这么简单,里面有很高深的管理理念以及很别扭的规矩。后面我慢慢讲。



Kanban应该要怎么实施(理论上)?

我们先来说说理论上是怎么实施的吧。

首先,认识一下,这个板子上的元素。

看板学问多,但是你却不知道……


角色:

  • PO(红色的小人):负责按照优先级整理Backlog,这里面全部都是Story

  • Dev(蓝色的小人):负责按照优先级进行Story的开发及实现工作

  • QA/QC(绿色的小人):负责根据Story的要求进行测试,这里的测试包括:功能测试、性能等非功能性测试

PS:这里我们发现一个有趣的事情,老外提倡的角色比例:1:4:2,至少开发和测试的比例建议是2:1


列:

  • Backlog:按照优先级排列的Story Pool,你可以理解为需求池

  • Selected:决定准备要开始的Story

  • Develop:正在进行及已经开发完成(待测)的Story

  • Deploy:测试中的Story

  • Live:完成测试的Story



接下来,我们来介绍一下过程:

  • 1.PO将要做的Story放到Selected里面,图中的2表示最多只能放2个Story

  • 2.Dev开始来做这2个Story,此时,PO可以再放2个Story到Selected中,因为此时的Selected列空了。

  • 3.Dev做完后,将Story放到Done里面,表示测试可以开始部署测试了

  • 4.测试开始测试时,将1个待测的放到Deploy里面,此时,开发可以再挑1个Story到Develop列中

  • 5.测试完成后,移动到Live,并且可以再选择一个Story从Done移到Deploy中

不断循环,直至所有的Backlog都完成




有4名Dev,为什么要限制只能开发2个Story?

其实,这里面有个思想:结对编程

还有个理念:互为Backup

PS:后面会讲,实际操作中和Scrum结合,我们应该怎么实施



为什么要限制数字?

Kanban很讲究专注。

一个人一次只能专注在一件事情上,只能专注在一个Story上,不能一会儿做做这个,一会儿做做那个。

PS:后面会讲,实际操作中和Scrum结合,我们应该怎么实施





Kanban要怎么实施(实际操作中与Scrum结合)?

之前我们说过Scrum中的角色以及各类会议。

所以,看了理论上的实施方法,不知道你除了上面的两个问题外,是否还有其他问题?

比如:不是说PO要对Story做验证测试吗?为什么这边测试通过后,就直接算是Live了?

比如:为什么这里叫Deploy(部署)而不是Verify(测试)?

比如:这里不划分Sprint吗?要是把Backlog里面的Story全部做完,那一个Sprint要多少周啊?

……


所以,如果想要把Kanban和Scrum结合,并不是那么容易的事情。


  • 1.Kanban列的改造:

根据Scrum的观点,范围是在Plan Meeting中确认的。

可是,我们刚才在讲理论的时候有说到各种会议吗?

没有。

所以,这其实是Kanban的理念与Scrum不同的地方。

但是这不妨碍我们把Kanban改造下,让它能够适合Scrum。

  • Unchecked:所有的Sprint已经评估过待完成的Story

  • Checkout:Dev开始做的Story(分为两个子列:Ongoing、Done)

  • Verify:测试开始测的Story(分为两个子列:Ongoing、Done)

  • Done:PO验证测试的Story(分为两个子列:Ongoing、Done)

类似下面的这张图:

看板学问多,但是你却不知道……


有人注意到右下角,在Burndown Chart下有多出来的两列:

  • Unplaned:代表这个Story很紧急,是临时插进来的,我们可以在做完手头上Story后开始它。

  • Next:为了方式在Plan Meeting上评估过多或过少准备的。


说到这里,你们有啥疑问吗?

没有嘛?

我说,你们看文的同时要思考,这样才能进步哎!

算了,我继续自问自答吧!


为什么不把Unplaned的Story直接放到Backlog里?

什么叫做Next是为评估过多或过少准备的?


嘿嘿,我就不告诉你

如果你知道答案或者你猜可能是因为什么,可以直接在底下写留言。



2.限制数字的改造

考虑到国内大部分IT公司是劳动密集型企业

所以我们使用结对编程或者组织Backup的情况非常少

一般来说,我们会将限制扩展为:人数+1

比如Dev有4个人,限制Story在Checked列中的总数为5。


为什么呢?

这是经验。


你可以试试4或者10的实施效果。

别告诉你们领导就行了。



3.流程的改造

整个Kanban的流程没有什么特别要改造的

只是Story的迁出不是从Backlog里面,而是从评估并计划好的Unchecked里面



Kanban和Scrum到底什么关系?

看板Kanban源自于霓虹,属于精益管理的一个工具。

最早的时候是用在工厂里的,用来进行进度和任务的跟踪,提升效率。

这也就可以理解为什么人家的列是Deploy和Live了。


后来敏捷Scrum等传入,进行了东西方智慧的融合。


但是,我觉得其实对于需求快速变化,甚至每天都会变化的互联网公司来说,实施Kanban会更加适合。


因为对于这类公司来说,它们无法Plan,计划赶不上变化。


而且很明显Kanban的节奏会更快一些,人员也会更专注。





写在最后:

在文字中间,我穿插了两个小问题,其实是担心你们哗啦一下子就拉到底下,忽视了重点……


很多事情并不是我们表面开起来那么简单的

就一个看上去很白的Kanban,你要是深入研究的话,发现的肯定不止小婧说的那么简单

同理,“与小婧同行”会让你发现小婧每天都很用心的和你说一些实用的东西

真心建议你不要看看就算了,要给自己列个Action,想办法把这些融到你的工作和生活中


以今天的Kanban为例,你不要以为你们团队不使用,你也推动不了,就算了

你其实可以把Kanban缩小,作为自己的任务计划评估执行管理


你会惊奇的发现其实Kanban也好,Scrum也罢,里面的精髓竟然与GTD是部分重合的!!!!


What?你竟然连GTD都不知道?


呵呵,问度娘去!


等等,去之前先留言答了上面的两个问题,再投下票,最后再给小婧赞一下,赏一个,转发一下呗

看板学问多,但是你却不知道……


「点点赞赏,手留余香」

    还没有人赞赏,快来当第一个赞赏的人吧!
0 条回复 A 作者 M 管理员
    所有的伟大,都源于一个勇敢的开始!
欢迎您,新朋友,感谢参与互动!欢迎您 {{author}},您在本站有{{commentsCount}}条评论