敏捷开发日常跟进系列

分享到

敏捷开发日常跟进系列

作者：cheny_com ，发布于2012-12-19，来源：CSDN

目录：

敏捷开发日常跟进系列之一：燃尽图

敏捷开发日常跟进系列之二：故事板，看板

敏捷开发日常跟进系列之三：跟进表

敏捷开发日常跟进系列之四：用户故事与MVC

敏捷开发日常跟进系列之五：开发与跟进

敏捷开发日常跟进系列之六：验收标准

敏捷开发日常跟进系列之一：燃尽图

这个系列将涉及燃尽图（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方法，只是被动地发现有些故事没有完成。

……

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

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

但是，迭代的最终目的到底是什么呢？有哪些“灵活变通”可以应用在燃尽图中呢？

迭代及燃尽图的目标

燃尽图的目标是完成迭代的目标，迭代的目标是什么呢？

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

2. 尽量完成1

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

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

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

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

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

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

怎么办呢？

“阶梯燃尽图”

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

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

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

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

“跟进图”

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

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

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

图中绿色粗线，就是传统的燃尽图；

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

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

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

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

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

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

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

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

4. 如果有跟进人，谁负责跟进哪个？

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

敏捷开发日常跟进系列之二：故事板，看板

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

故事板

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

一般故事板分为三列：

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

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

故事板的用法

要解决的问题

故事板可以帮助解决一些燃尽图解决不了的问题（见上篇）：

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

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

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

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

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

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

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

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

介质

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

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

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

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

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

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

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

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

2012-03-07补充：

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

敏捷开发日常跟进系列之三：跟进表

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

跟进表

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

1. 哪些故事完成了

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

2. 谁在跟进

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

3. 谁在开发

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

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

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

5. 哪些故事被搁置了

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

……

实例

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

实例一

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

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

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

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

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

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

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

实例二

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

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

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

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

敏捷开发日常跟进系列之四：用户故事与MVC

用户故事和MVC没有关系，因为MVC是实现方法，因此在思考用户故事的时候，不要一下就想到实现方法，很容易把故事写坏。

但是MVC和用户故事有很大的关系，如果用户故事写好了，做MVC的时候，一定要记得参考用户故事。

本人在C++的年代用过MVC，但那个时候MVC还只是一种编程思想，说用了也行，说没用也行。但到了C#之后，就出现了正牌的自称是MVC的东西（现在最新版本是MVC3），本人也在用。Java世界也有MVC的概念，但是没有见识过，下文中所描述的MVC，若没有特殊说明，均指Asp.net MVC；但相信对Java中的MVC也有借鉴意义。

利用MVC实现用户故事的技法

如果您已经认可之六中产生用户故事的方法，那么也就得到了这样的一个用户故事树，右边则是为其量身定做的Controller-Action（来自实际项目）：

=============================================

下面是对应的Controller-Actions

UsersController

--Users/Index

----什么也不是

--/Users/Details

--/Users/User2Authorities

--/Users/Users2Roles

--/Users/Freeze

--/Users/Edit

--/Users/Delete

--/Users/BatchCreate

RolesController

--Roles/Edit

--Roles/Details

--Roles/Delete

--Roles/Index

AuthoritesController

--Authorities/URA

--Authorities/Delete

--什么也不是

--Authorities/Index

----什么也不是

--/Authorities/Authorities2Roles

--/Authorities/URGA

=============================================

注意看每个Controller实现了一个史诗故事（要管理的数据），每个Action则实现了一个（偶然多个）用户故事（用户的业务操作），有几个值得注意的地方：

1. 一个Controller几乎正好可以实现一个史诗故事

2. 一个Action因为正好是一个动词，所以几乎正好和一个用户故事对应。

有两个地方违反了，如“角色首页（新建+查看）”和“权限首页（新建+查看）”，因为为了方便我们在两个Index里边放了个新建用的TextBox，方便直接创建（因为角色和权限都只有一个名字而已，所以觉得犯不上做个独立页面了）。

为了能记住这一点，我们在故事的缩写名字上加了（XX+XX）的标记，为了日后能自动计数故事。

3. 用户没有“创建”故事，也没有Users/Create，因为用户只有两种正常的创建方法：Register和BatchCreate，我们选择了后者。因此既没有“创建用户”这个故事，也没有“/Users/Create”这个Action。

4. 几个绿色箭头是“增强”类型的故事（详见之五），它们正好也不对应Action。

上面提到的是我们实际的一种用法，未必是普适的，但在我们项目中非常适合，甚至应该称为“舒服极了”。

这种史诗-故事与Controller-Action之间偶然的巧合，实际上背后有其必然性。

利用MVC实现用户故事的心法

MVC以往研究的重点，是何为M，何为V，何为C，以及三者之间的关系。

我们在用了一段时间后，发现其中的每一个，都还有更深层次的理念在里边，这里谈的就是Controller及其Action。

在MVC三者呆在一起的时候，问：何为Controller？估计还是挺容易回答的。

但如果不提MV，直接问：何为一个Controller？何为一个Action？却挺难回答的。

如果去一个非MVC的网站或软件，最令人烦恼的，是网站的每个页面未必有自己独立的链接，比如逛了半天，顶上的链接一直是http://xxx.../login=xxxx，想为某个页面加个收藏夹都不行。MVC在很大程度上解决了这个问题：要操作的数据是Controller，要做的操作是Action，而参数则是具体操作谁，比如/Users/Details?user=cheny或CSDN博客上常见的：http://blog.csdn.net/cheny_com/article/details/6616794 样式。

所以如果已经按照之六中提到的数据-操作方法来组织史诗-故事结构了，而且又在使用MVC,则非常推荐编程时将其继续映射到Controller-Action中。

可能细心的读者已经注意到本文图中有些故事后面有个链接符号，那个正是我们在已经实现了的即金色的故事的后面，加上了其超链接（全部是/Controller/Action，一一对应，非常舒服）。这相当于一个Action写好了，一个故事（偶然情况是多个）就正好也完了；而测试人员就可以点击那个链接去到Action测试。他测试完了Action，就能说故事被测试完了（而不只是Action被测试完了）。

以这种方式来对应用户故事和开发内容，产品经理和开发人员很容易沟通，因此非常推荐使用。

用户故事 vs. FPA功能点分析法 vs. MVC

功能点分析法（FPA）、敏捷开发用户故事、Asp.net MVC在一定程度上具有相同的目的：作为用户需求与开发人员工作的桥梁，只是侧重点有所不同。因此若能将它们联合应用，就可能用一种组织方式贯穿性地管理估算、需求管理、架构设计三者。

完整地表述三者的关系，大致如下：

	用户故事	FPA	MVC
数据	史诗故事	ILF内部逻辑文件 EIF外部接口文件	Controller
操作	普通故事（功能）	EI外部输入 EO外部输出 EQ外部查询	Action

敏捷开发日常跟进系列之五：开发与跟进

产品负责人常常被描述成在计划会前准备好用户故事，在计划会上讲解并帮助开发团队估算后就万事大吉，只等月底接收“可工作软件”的样子，其实如果真的这样，很容易出问题。

需求精化

这是发生在迭代周期中间的常规活动，产品负责人会与团队密切接触（确切说如果能经常坐在一起更好），在每个故事开发的前夜或中间，将之前讲解过的用户故事更详细地描述一番（有时候是在看到开发一半的半成品后做一些细化或更正）。

一般认为产品负责人在开发的中间来打扰开发组工作是不令人欢迎的行为，那这两者之间到底区别何在呢？

在以后将会编写的一个《敏捷开发产品管理》系列中将会提到，产品负责人要做到“迭代期内无变更”，必须要做好长周期的研发管理，就是为每个版本每个迭代提前设定好目标。因此落实到具体迭代的时候，这个目标不是那么容易发生变化的，但“如何更好地达到这个目标”，则可能经常在变化。

需求精化的过程，就是产品负责人帮助团队更好地达到目标的过程。

“需求精化到底包含哪些活动？”确切说，只要把产品负责人和团队放在一起，什么事情都可能发生。

可能会对模糊的需求进行细化；可能会根据半成品做一些调整；可能给开发人员讲解一下用户背景……总之试一试，就知道了。

NEC的迭代开发中甚至有一个固定的时间（忘了是一个月中的第10天还是第20天），产品负责人会帮助全组对下一个迭代的故事进行一次提前通告，以帮助团队预测到以后发生的故事，从而略微地为未来做一些准备。这种准备既有提前了解业务的方面，也有潜在的在架构上为扩展做一些有限的准备。

跟进人，渐进评审

若开发组的人数众多，而产品负责人只有一个，他的工作会相当繁忙，顾此失彼。

跟进人制度是在产品负责人团队基础上建立起来的。所谓产品负责人团队，就是多个对产品了解的人组成一个团队，集体行使产品负责人的职责，典型的如软件或嵌入式产品研发中的产品总监-产品经理-产品专员团队，游戏团队中的主策划-策划组长-策划团队。

而跟进人，就是针对某个用户故事，指定相应的产品负责人团队的某个组员，来跟踪故事的开发进展。

跟进人最大的好处，是可以在用户故事一完成的时间点就进行评审、改进，防止了到最后却发现故事实现的不好，一则返工浪费时间，二则影响了上线日期（只能下个迭代修改）。

跟进人制度和渐进式评审在网络游戏的敏捷开发中非常普遍，原因是网游的策划人员比较多能完成跟进，而且对于“影响上线”比较敏感。

个人感觉跟进人制度和渐进式评审在普通研发中也应该推广，无论如何如果用户故事因为“只差一点，需要改进”而不能交付，要延期到下一迭代中，的确令人沮丧。

故事板安排技巧

故事板的一般概念就不多说了，无外乎几个栏目：待开发-开发中-待测试-测试中-待发布-发布之类的，大同小异。

一个技巧则是“开发中”这一列一定要窄，含义是不要同时开发多个故事，最好结束几个再开几个。目的是不要所有故事开始了却都没有结束，导致最后无法交付。

这也使得跟进人不会太忙乱于多个故事，可以一个一个介绍，一个一个评审。

敏捷开发日常跟进系列之六：验收标准

要想不在评审会上得到“惊喜”，Product Owner最好提前约定好用户故事的验收标准，而且每个用户故事可能各不相同。

面向客户价值设定验收标准

简单说，就是客户看到说“完成了”，才算完成了。

从这一点上说，用户眼中的“可工作软件”和我们认为“可以运行，自动化测试了的，没有缺陷的”软件还是有差别的。用户拿到软件，是要使用从而获得价值的，这常常需要多个功能联合运行，前后数据完整一致才可以做到。在“敏捷产品管理”系列中，还会更加深入地探讨这个话题。

下面的例子，很好地表明了客户眼中的完成标准，它是EA（电子艺界，世界最大的游戏发行商和开发商之一）用于判断游戏中不同故事完成标准的。

S =Sufficient for feedback. “可获得反馈的”（第一次能看得见的）

Generally the firsttime something can be seen in software, however incomplete.

W=Working. “能运行的”（能用，但是艺术性欠佳的）

The functionality isbroadly in place but art work (e.g. graphical quality, UI) may be very lowfidelity or placeholder.

T=Testable. “可提交玩家测试的”（可以交给玩家而不会破绽百出的）

(by kids in ourcase). The software is sufficiently done to put it in front of people that havenot seen it before and for them to be able to use it with minimal intervention.

A=Alpha. “可提交Alpha测试的” （改改BUG就可以上线的）

Potentiallyshippable, likely needing some polish and bug fixing.

G=Great. “完美的”（可以上线而且估计反响强烈的）

Shippable and likelyto receive a great review score.

为什么要搞这么复杂呢？因为游戏中有些功能，在开发出来之前策划人员也说不明白怎样才是好，但又急于开发出来看看，因此会采用最低标准S，就是能用就行，不测试，不写文档，不做性能优化……而另外一些功能，则可能比较正式一些，比如需要给某些玩家看到的，就会选择T或A级别；而正式功能，则会选择G。

不同的公司，有不同的客户群，为了不同的目的，需要制定自己相应的完成标准。

客户价值与工程实践的映射

上面是一个完全面向客户价值编写的完成标准，看起来很好，但是实践起来开发人员很难把握。

其实，每个面向客户价值的标准，背后都有相应的工程标准。在熟悉之后，开发人员一望便知。比如下面是上述标准中S和W标准的工程实践描述：

W能运行的 =

编码完成 √

单元测试 √