文章

物理看板还是电子看板?

无可厚非,敏捷项目的最终成败与看板本身是物理的还是电子的没有直接关系。所以本文不是讨论敏捷项目的成败,而是讨论:如果你用了看板,那么哪种看板更适合你? 笔者基于辅导过的上百个敏捷团队的经验做了一些总结。

物理看板的优势。物理看板在一定的历史背景下确实发挥了很大的作用,大部分的敏捷教练一开始也是推荐物理看板,笔者也是建议一开始使用物理看板。

Read more

scrumcn_kanban

精益生产中的看板方法

看板管理,常作“Kanban管理”(来自日语“看板”,カンバン,日语罗马拼写:Kanban),是丰田生产模式中的重要概念,指为了达到及时生产(JIT)方式控制现场生产流程的工具。及时生产方式中的拉式(Pull)生产系统可以使信息的流程缩短,并配合定量、固定装货容器等方式,而使生产过程中的物料流动顺畅。   在看板标示系统中常将塑料或纸制成薄板,将产品名称及数量写于其上,故此得名。及时生产方式的看板在生产线上分为两类:领取看板和生产看板,旨在传达的信息是:“何物,何时,生产多少数量,以何方式生产、搬运”。   看板的具体信息包括:零件号码、品名、制造编号、容器形式、容器容量、发出看板编号、移往地点、零件外观等。 Read more

scrumcn_kanban

什么是看板方法?

看板方法是用于高效管理软件开发流程的新技术。看板方法源自丰田的“及时生产”(JIT=just-in-time)系统。尽管生产软件是一项创造性活动,与批量生产汽车有所不同,但是生产线管理背后所蕴含的原理仍然适用。 Read more

scrumcn_kanban

敏捷开发日常跟进:故事板,看板

这是敏捷开发日常跟进系列的第三篇。

故事板和看板其实不是一个东西,前者是最初的敏捷开发里边的东西,受到了后者的启发产生的;而后者是制造业的东西,具体内容请参考末尾的百度百科。但是在敏捷开发里边提到这两样东西,可以认为大致相同。
故事板

简单说,故事板是展示迭代中的用户故事和任务的方法,在《硝烟中的Scrum和XP》的封面上就印着一个典型的故事板:

scrumcn1368609640

一般故事板分为三列:

To Do还没做的, Doing正在做的, Done做完的(有各种各样的中英文写法,大同小异)

有些团队的分工比较多,会出现一些中间状态,比如“还没做的/正在开发的/等待测试的/正在测试的/等待评审的”是一种典型的开发与测试分离的故事板。
故事板的用法

要解决的问题

故事板可以帮助解决一些燃尽图解决不了的问题(见上篇):

1. 有哪些故事正在做,还没有做,已经开工了但没完成……?故事板的三列正好解决问题。

2. 最后剩下了哪些故事没完成?最左边剩下的就是。

3. 有没有人不是一个一个完成故事,而是同时开工了很多故事?(这个是最后很多故事都开工了但都差一点完成不了的主要原因)这个复杂一些,下面讲。

同时开工很多故事,很容易造成思绪散乱、最后全部完不成的情况,确切说瀑布模型就是同时开工所有故事的典范。

为了防止这一点,如果是手工做的故事板,,那么注意中间一个“正在做的”列一点要窄一些,这样当里边的故事挤不下的时候,就是一个危险的很多故事都在开工的信号。

还有一种做法,是每个人只准放一个故事在中间,做完一个,才能再做一个。这个严格坚持有难度,因为经常遇到被卡住的情况,但是作为一种思路和精神应该尽量坚持。

4. 如果有跟进人,谁负责跟进哪个?可以在卡片上写上当前负责人、跟进人的名字。

通常的做法有很多种,比如每个人用自己颜色的即时贴,可以比较容易地看出每个人有多少个故事,分别处于什么状态。不过,这样就需要在“尚未开始的”里边提前分配人员了,不太利于后期的互动和互相关注;当然还可以在开始的时候重新用有颜色的即时贴重新抄一个,看大家的习惯了。

介质

尽管有很多故事板/看板工具,使用纸质方法仍然是一个很好的选择,原因就是作为“迭代中的任务”这种东西,其生存期很短,基本上2个月后价值为0,人们也就用纸片来对付了。

不过如果想在未来做几件事情,那么及早采用电子故事板/看板还是有必要的,这些事情包括:

1. 希望统计和分析哪些故事容易完不成、每个月的完成情况等

2. 大型团队,分布式团队

3. 希望留下历史数据作为以后估算的参考值和参考故事

下面这个是免费工具火星人中的故事板,做了两个案例来说明一下情况。

scrumcn1368609841

上面这个图是不好的情况,开发中的故事一大堆,没几个完成的,很容易造成最后所有故事都差一点。

下面这个要好的多,每个人只开工了1个(每种底色是一个人,案例中只有cheny和yock两个人),剩下的要末完全做完了,要么一点没做,即使到期末不能全部完成,也不会把太多时间卡在半截的故事上。

scrumcn1368609860

2012-03-07补充:

昨天下午仔细调整了美术效果,现在的故事板外观如下:

scrumcn1368609892

本专栏经作者授权开设,专栏文章未经许可不得转载

博客地址:http://blog.csdn.net/cheny_com

电子敏捷管理工具如何让你盲目—实物Kanban板如何帮助你重见光明

多年来,我们一直使用PivotalTracker作为我们的敏捷软件开发流程管理工具。一直以来我们都对PivotalTracker非常满意。无论什么时候,只有我们有新的想法,无论想法有多抽象多模糊,我们都把它写成Epic记录在系统的Tracker里面。当我们准备开始要实现这个想法的时候,我们通常会把它分解成更加详细的用户故事。一旦我们的用户故事足够涵盖到这个想法的所有内容的时候,我们就把这个Epic删除。然后,我们会把这些用户故事打上这个Epic的标签,这样我们就知道它们是从哪里来的了。
Read more

Scrum还是Kanban?这不是问题

几天前,我就Matthias的关于Scrum强制团队只能在sprint结束之后才能发布,而Kanban则更灵活的帖子发表了看法。

我想知道Scrum和Kanban的不同,我很疑惑为什么有人抱怨Scrum把规则定得太死,不够灵活等等。于是,我参加了David Anderson的Kanban中级课程。

结果,David的课程让我大开眼界。David表示Kanban并不是去改变什么东西,而只是将工作流程可视化和将隐藏的政策公开讨论而已。Kanban通过加入并行任务的限制,使得公司需要进行的改变慢慢地涌现出来。David说Kanban和Scrum的不同就在于,Kanban所引起的改变是自发的,Scrum引起的改变是被动的。革新由于革命。

首先,我要承认的是我真的非常喜欢精益的思想。我对David能够把这种思想融入到软件开发中感到十分敬佩。有趣的是,和我一起上课的人里面有人把我认出来了,而且他们觉得很奇怪,我明明是Scrum的支持者,为什么我会出现在这里呢?

从1994年起,我就开始相信学习精益理论非常有用。当我在2002年知道Scrum以后,我就确信Scrum能够处理精益理论解决的问题。我认为David这种优雅地将精益思想引入到软件开发世界中来的方法是朝着正确的方向迈出了坚实的一大步。

但是,在这课堂中十分困扰我的是居然没有人提及一些在我讲授的课程里经常提及的问题,例如:
 如果大家愿意创建任务版怎么办?
 如果团队成员之间不想合作怎么办?
 如果大家不想坐在一起怎么办?
 如果管理层反对这样的工作方式怎么办?
 我该怎么样创建一个发布计划?
 我该如何计算出项目成本?

我见过有些人没有成功连续完成3个Sprint,经常找不到Product Owner,或者团队经常被打扰的问题无法解决。然后,这些人就说Scrum没有办法解决这些问题,Kanban才是更好的解决方案。恕我不客气地说一句,就在Kanban倒在无数无法解决的问题前的时候,Scrum的支持者们已经给这些问题提供了解决方案。

今天,Scrum的实践者们已经懂得了如何:
 管理大型项目
 解决大型团队的问题
 解决团队之间的依赖关系
 使用Scrum构建大型架构的框架
 在项目开始之前计算项目成本
 快速有效地进行估算
 还有很多很多
在David的一本书中解释的著名的“泳道”模式,是为了管理大型企业的模式。这个模式是我2004年在德国WEB.DE的时候为4个Scrum团队发明的。直到今天,我还在用这种模式来管理180人的团队。从2005年起,我在我的所有课程中都会解释这种模式。

但是,无论是Scrum,还是Kanban,还是ASD,还是Crystal都无法解决下面的这个问题:人们害怕改变,尽管他们已经看到问题所在。很多人,包括Scrum Master,都需要一个领路人来让他们变得更好。

使用Kanban,Crystal或者ASD的人都必须说服他们的团队或者管理层他们建议的方法是真正能够带来改进的。Ken Schwaber总是说:“行动才是最好的证明。”我必须承认的是,我也不大明白,David能够让人相信使用他推荐的方法,而不是单纯他们自己本身的能力能够解决问题。

我认为David就是一个天才,一个天生的领导者。我承认以他提倡的方式开展一个新项目会比使用Scrum看起来更加简单。Kanban可能在某些环境中更加有效,当然我们也可以在实施Scrum的时候使用Kanban中的某些方法。

其实,Scrum,Kanban,Crystal和ASD在核心上是非常类似的:找出障碍和问题的来源,然后有针对性的行动。

我的建议是按照你认为能够符合你当前情况的方式进行。你可以先使用Kanban然后在其中应用一些Scrum的内容,或者先使用Scrum然后在其中应用一些Kanban的内容。例如,为任务定义Service Levels是解决分组工作的很好的办法,或者让循环周期可见度更高。这些都是对Scrum很有用的补充。

我所关心的是,我们想要改变我们公司成员的工作方式。我们想要给他们授权,我们想要让他们高兴和给他们最好的,因为他们热爱他们所做的事情。

然而,更常见的是,在很多Scrum团队中,有的人默默离开,有的人行为根本不像成年人,有的人只愿意被动地接受别人指派的任务。正是这些人,通常会在我的课程里面问类似“我们真的有必要分割任务吗?如果我们不能完成所有用户故事怎么办?如果一个用户故事本应该是8个故事点而被估成5个点怎么办?”的问题。

我认识很多Scrum实施顾问经常会把他们的客户引导这些问题上面来,因为他们只懂得回答这些问题,或者更不幸的是,他们害怕使他们的客户面对更加麻烦的流程问题。这些顾问败坏了Scrum的名声,因为他们不敢向他们的客户提出一些有可能让他们感到不自在的问题。于是,为了保住他们的客户,他们选择了沉默。

当然,有时候我们会损失一些客户。因为客户对我们呈现出来的真相感到恐惧。我们并不迷信Scrum,我们只是做我们认为对的事。我们是很务实的!我们坚持真相和让事情更透明。那是因为Scrum虽然简单,但是却很难用好。

作者:Boris Gloger

原文地址:http://www.agileweboperations.com/scrum-or-kanban-it-does-not-matter

应用精益思考来帮助Scrum团队

多年来帮助大大小小的公司转型为更加敏捷,我学到一样东西:公司越大,应用Scrum的时候,精益思考就可越有效地提供帮助。精益对于拥有独立的团队的小公司来说,并不那么必须。但它对大公司至关重要,比方说有100人或者更大的公司。如果你所工作的是大公司,那么这篇文章就是为你量身定做的。 Read more