文章

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

scrumcn_sprint

敏捷开发日常跟进:燃尽图(下)

这是敏捷开发日常跟进系列的第二篇。
迭代及燃尽图的目标

燃尽图的目标是完成迭代的目标,迭代的目标是什么呢?

1. 按产品经理的要求,交付计划会中计划的用户故事

2. 尽量完成1

之后还会看到,这个定义还有狭隘之处,在系列后面的文章中会提到。

为什么燃尽图不能直接地达成这个目标?潜在的问题包括:

1. 如果燃尽图按时完成,有可能是为了按时完成,同时牺牲了所有故事(重要和不重要的)的质量,换取了进度。

2. 如果燃尽图未按时完成,有可能不是一个故事没有完成,而是所有故事都剩下点活没做完,导致所有故事都无法交付。

3. 如果燃尽图未按时完成,没有完成的故事中,有可能包括了极其重要的一些。

只从燃尽图的形态看,是无法提前识别这三者的,也就因此带来了很多的风险,到迭代的末尾让人大吃一惊。

怎么办呢?
“阶梯燃尽图”

之前听过这个方法,但是刚才在网络上没有找到图片。

方法就是在每个故事完成的时候才把整个故事突然剪掉,从而形成阶梯状。

阶梯状燃烧图的缺点也很明显:刚开始的时候很难看到有燃尽,甚至那些向上拱起的弧形也被掩盖了,日后回顾时,一些细节也很难记起来。

所以一种解决方案,是把普通燃尽图和阶梯燃尽图混合使用,就是同时画两条线。
“跟进图”

跟进图是一些大型团队的创造,由于团队巨大,所以不能指望在迭代的最后用2小时评审完所有工作,所以常常是做完一个评审一个,这就要给每个工作分配一个“跟进人”,他隶属产品部门,没事就盯着“跟进图”看看有没有自己关心的工作做完了。

在为一家游戏公司提供咨询的时候,他们一款产品的团队人数高达88人(另一个甚至到了200人),墙上就用手绘制了一幅巨大的跟进图,每天更新动态,甚至直接在纸上画上小图标,每月画满了,就重新打印一张。

下面这张,是火星人中的跟进图。

 scrumcn1368609297

图中绿色粗线,就是传统的燃尽图;

每当一个故事完成,就会有一个蓝色的标记及完成故事的名字,从而提醒跟进人进行现场预评审;如果长期没有故事完成,燃烧图却还在燃烧,就肯定出现了之前说过的问题了。

右下部分还有一个暗红色的细线,是“溢出时间”,就是超出预期的工作的时间,表明这段时间出现了新的任务;新任务出现的太早不好,因为一般在迭代前期都先完成最重要的故事,不应该引入新任务;但在后期随着最重要的故事完成、评审、因不满意而返工,团队会倾向于把最重要的任务更好地完成,而非草草地把所有故事都凑合完成,在产品研发中,这往往是更能提升产品价值的。

一家叫做广联达的公司在实践中把溢出时间作为负数倒着画,称为“基线下沉”,就是说要去的地方不是0了,而是那个负数,是一个类似目的的很好的实践。

我试了一下也不错,就是图表会变高,显示起来不方便,所以还是改了回来。

这样的跟进图看起来已经很强大了,但是还有一些问题没有解决:

1. 有哪些故事正在做,还没有做,已经开工了但没完成……?

2. 最后剩下了哪些故事没完成?

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

4. 如果有跟进人,谁负责跟进哪个?

有些问题需要后面的故事板(看板)解决,有些则需要一个叫做“跟进表”的东西,之后我们说完故事板再回来详细说明。

 

作者:陈勇

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

 

scrumcn_sprint

敏捷开发日常跟进:燃尽图(上)

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

这个系列将涉及燃尽图(Burndown Chart)、故事板(看板)、每日立会等内容,描述在计划会之后,评审会之前,敏捷开发团队内部产出与产品经理和项目经理的各种活动。

日常跟进中的某些内容比如团队工作模型、预估会议、用户故事跟进等在之前的松结对编程、团队管理、用户故事、产品管理等系列中有所描述。

在这个系列之前,还应该有一个敏捷计划系列,描述敏捷开发的从版本规划到计划会估算的详细内容,未来将会补上,当前可以参考2.29版的《火星人敏捷开发手册》,有5页与其相对应。
燃尽图

燃尽图Burdown Chart也叫燃烧图,是罕见的敏捷度量,以至于每当有人问起“敏捷中有度量吗”的时候,第一反应就是它。

燃尽图的全称,应该是“总剩余时间的燃尽图”,就是本次迭代中,所有故事(或拆分的任务,以下仅称故事)的剩余时间总和,随日期的变化而逐日递减的图。

图中左侧460是迭代开始的第一天,所有故事的未完成时间相加为460天,而在最右侧则表明在第17天,所有故事的剩余时间相加变为0,也就是所有故事都完成了。

为什么总和会递减呢?因为每个组员每天都要汇报一件事情:当前正在做的故事,还剩余几天,如果昨天剩余3天,今天剩余2天,那么就为燃烧图贡献了1天的进度。

由于可能出现“昨天剩余3天,又工作了一天后本以为会只剩下2天,结果感觉可能还要3天(甚至变成5天了!)”这种情况,所以燃尽图常常有一些起伏。
燃尽图的“指纹”

图中的燃尽图尽管有一些起伏,依然是属于比较完美的燃尽图。实际上每个团队完成迭代的过程差别很大,常见的情况包括:

先鼓起后落下

原因是计划会以常常漏掉一些事情,所以开工后不但不燃尽,还发现了很多新的任务。

先完美燃烧,然后突然停止燃烧

一种很常见的情况,如果任务划分太粗,比如长达10天,很容易“做了1天,剩9天;做了1天,剩8天;……到剩2~3天的时候,哎呀,好像搞不定了”。

先缓慢燃烧,然后到快燃尽的时候剩下一堆没完成的任务,被推迟到下个迭代

之前提到过敏捷开发的MoSCoW方法,有些故事是次要的“可以不做的”,所以这种燃烧图也很常见;但是常常有团队没有使用MoSCoW方法,只是被动地发现有些故事没有完成。

……

为了改进这些不完美,有些团队设置了一些度量项来改进燃尽图的结果,比如“迭代按时燃尽的次数”“剩余故事占总故事的比例”……

其实不用因为燃尽图的不完美而伤脑筋,在般若敏捷的“无住”中曾经提到,这些方法都非我们的目的,而只是一个中间的工具,因此为了完成我们的最终目的,这些工具和方法都可以灵活变通,而不要追求工具和度量数据本身的完美。

但是,迭代的最终目的到底是什么呢?有哪些“灵活变通”可以应用在燃尽图中呢?且待下回分解。

 

作者:陈勇

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

高度专门化时代下的敏捷开发

本文我们一起来谈谈高度专门化时代下的 敏捷开发 。

自从18世纪的工业革命开始,专门化的程度一直处于上升的趋势。工人们逐渐开始只生产产品的小部件,而不是像以前那样涉足到整个产品生产的所有环节。 Read more

应该为bug修复的故事安排故事点吗

在把一个产品从传统方法向敏捷方法的迁移过程中,团队通常带着一大堆bug前行。这通常是缺泛持续的高质量要求的自然结果。导入敏捷后不用多久,很多团队(及他们的产品负责人)会决定激进去清除这些Bug的backlog。 通常的做这件事的方法都是在每个Sprint中计划修复掉X个bug,或者是每个Sprint中计划花Y小时用在修复bug上。有时团队会为这样的活动写一个用户故事如“作为一个用户,我希望至少有15个bug被修复”或者“作为一个用户,我希望你这个Sprint中花大约50个小时去修复bug,使得应用系统逐渐的变得质量更高”。即使团队并没有明确的写一个这样的用户故事,他们也通常会在他们的任务板中加这么一行,以便于bug修复的工作是可见并且可以跟踪的。 Read more

什么样的项目最适合于敏捷开发

我最近被问到关于什么样的项目才是最适合于敏捷方法,在此关于这方面进行一个探讨。在我看来,最适合敏捷方法的项目是那些有着激进的时间期限限制,那些有着高度的复杂程度,以及那些有着高度新颖性(独特性)的项目。 Read more

优秀的 Scrum Master 应该具备哪些特质?

如今的外科医生是受过高级训练和技能娴熟的人,他们经过多年的正规教育,然后又做过广泛的实习。早期的情况并不总是这样的,Pete Moore写道“首批外科医生不懂解剖知识,但之所以能开展他们的业务,是因为他们有锋利的器械和强壮的胳膊。他们在当地的工作是理发师或者铁匠,经常在业余时间做手术。”(2005,143) Read more

工欲善其事,必先利其器

敏捷开发的潮流并不是由敏捷工具来推动的,因为你可以仅使用命令行接口、单元测试工具和需求卡片来展开敏捷开发。但近年来,为了更好地支持敏捷开发,敏捷工具也有了很大的发展。其中部分工具是直接面向新型项目管理方式的,特别是有些种类的工具已与敏捷开发密不可分。根据Forrester研究公司(Forrester Research)高级分析师Carey Schwaber的研究结果,面向敏捷开发的项目管理工具、持续集成构建工具和自动测试工具已是敏捷开发不可或缺的工具。 Read more

如何保证质量?

现在,我依然能碰到一些敏捷开发者和团队,他们在项目中还未采用自动化实践,比如微测试,自动化集成测试和集成测试。这种现象存在主要是因为三种原因:

1.开发者没有看到它的价值

一些开发者技术好经验足,他们很少出错,自动化测试对他们来说是个额外的负担。当一些初级开发者在忙着改bug时,他们往往在做更重要的事,比如把他们的技术应用到系统架构上。如果团队中有这样一批开发者的话是很难实施自动化测试的。 Read more

Scrum中的测试:人少事不少

导读:Scrum团队以小著称,团队中一般只有一到两名测试人员,那么这一两名测试人员在Scrum团队中又是如何开展测试工作,起着什么样的作用呢?

Scrum敏捷开发有一个明显特征就是重团队,轻部门,每个团队里面包含了开发、设计、测试各种角色,Scrum团队以小著称,团队中的测试人员一般只有一到两名。

在传统的瀑布式开发 中,测试人员经常因进入测试阶段的条件不满足而需要较长的等待。而在Scrum敏捷开发中,测试人员需要尽可能早的开展工作,“等待”在Scrum开发的测试中已属一种错误概念。

测试人员应具备三方面的能力:编码,测试和分析。不同的阶段对测试的要求不同,在功能测试中偏重编程能力,在系统配置测试中偏重分析能力,Scrum团队中的测试人员需要将这三种能力融会贯通,才能适应迭代过程中的诸多变化。

测试是软件开发中必不可少的一部分,那么Scrum团队中测试人员又要如何开展测试工作呢? Read more