这是敏捷开发日常跟进系列的第四篇。 (栏目目录

跟进表是大型敏捷团队的一种实践。在一个80多人的网络游戏团队中,他们为了清晰地显示整个团队的运作方式,使用了这种方法。

跟进表

以上面的网络游戏团队为例,说明一下跟进表上的信息:

1. 哪些故事完成了

在故事板中也能表达,但缺少结构性。故事板中的故事都是平等的,较难显示大小、父子包含关系等。

2. 谁在跟进

案例中这个人一般是策划人员,故事的创建者和验收者。

3. 谁在开发

案例中这个一般是若干个开发人员、脚本、美术的群体,也可能只有其中一个工种。

4. 某个任务大概可能在何时开始、结束。

在故事板、燃尽图上均无法表达。

5. 哪些故事被搁置了

可能遇到了困难,也可能有其他原因,甚至可能做了一半干别的被忙忘了。

……

实例

这是一个在“火星人”研发中已经完成的迭代的跟进表案例。

实例一

我们先看看这个迭代的燃尽图(看不清楚请右键-图片另存为后观看):

敏捷开发日常跟进系列之四:跟进表

对于跟进图的5个作用,上面这个已经扩展了的燃尽图只能完成第一个,就是“哪些故事完成了”,而一般的燃尽图连这个作用也没有。

为了完成另外四个目标,就需要下面的跟进表。

敏捷开发日常跟进系列之四:跟进表

先看左边的蓝框,里边是所有迭代中的故事(Sprint Backlog),为什么要显示成这个树状结构呢?因为如果是小团队,只有10~20个故事,那么人们即使从只有3个字的故事名称比如“新界面”上,大家也能记住和理解说的是什么意思。但是如果故事多了,就比较困难,会导致故事的名字不得不很长,比如“计划会-讲解故事-的新界面”,而这样表达看似还行,但由于没有清晰的父子包含关系,多了也乱。所以蓝框中以父子关系的方式表达,对于大型产品的研发更清晰一些。

蓝框右边两列是负责人(对应跟进人,案例中的策划人员)和当前负责人(开发人员),由于我们的团队小,不存在两个部门,所以没有设置跟进人,所以也就没有“负责人”。

三个黄框(一横两竖)所框住的表格的底色有的是绿色,有的是粉红色,绿色是加班,粉红色则是假期或休假。左边竖框标明15日大家集体加班,原因是右边竖框中大家19日集体放假外出春游;横向的黄框则标明yock在这个月有大量休假,他只能在特定日期完成工作。为什么要管理这些呢?有时候看似燃尽图正好指向0点,但那个地方可能正好是春节、五一、元旦什么的,有了对假期的整体把握,对重要的上线活动就降低了风险。

红框中的故事看上去就有点异常,因为尽管整个迭代结束了,它的剩余时间居然还是“1人天”,所以这个故事没有完成,它停在了17日。

实例二

下面的图,是调整了一些数据,并将系统时间调整到2.26,模拟一个正在进行中的迭代。

敏捷开发日常跟进系列之四:跟进表

从最右边可以看到有4个故事没有完成,其中两个是尚未开始(最上面和最下面两个浅色的),另外两个则是遇到了障碍,卡在了17日和24日,之后没有进展。

作为项目经理和技术经理,在跟进表中看到遇到障碍的故事,就要及时询问和协调;作为程序员,也应该在每日立会上报告被卡住的故事。

沉默的程序员,又聋又瞎的项目经理(越大型团队的项目经理就越严重),是造成大型项目纠缠不清最终失败的重要原因。

分类:

技术点:

相关文章: