搜索
敏捷开发日常跟进系列之一：燃尽图（上）这个系列将涉及燃尽图（BurndownChart）、故事板（看板）、每日立会等内容，描述在计划会之后，评审会之前，敏捷开发团队内部产出与产品经理和项目经理的各种活动。日常跟进中的某些内容比如团队工作模型、预估会议、用户故事跟进等在之前的松结对编程、团队管理、用户故事、产品管理等系列中有所描述。在这个系列之前，还应该有一个敏捷计划系列，描述敏捷开发的从版本规划到计划会估算的详细内容，未来将会补上，当前可以参考2.29版的《火星人敏捷开发手册》，有5页与其相对应。燃尽图燃尽图BurdownChart也叫燃烧图，是罕见的敏捷度量，以至于每当有人问起“敏捷中有度量吗”的时候，第一反应就是它。燃尽图的全称，应该是“总剩余时间的燃尽图”，就是本次迭代中，所有故事（或拆分的任务，以下仅称故事）的剩余时间总和，随日期的变化而逐日递减的图。图中左侧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》的封面上就印着一个典型的故事板：一般故事板分为三列：ToDo还没做的,Doing正在做的,Done做完的（有各种各样的中英文写法，大同小异）有些团队的分工比较多，会出现一些中间状态，比如“还没做的/正在开发的/等待测试的/正在测试的/等待评审的”是一种典型的开发与测试分离的故事板。故事板的用法要解决的问题故事板可以帮助解决一些燃尽图解决不了的问题（见上篇）：1.有哪些故事正在做，还没有做，已经开工了但没完成……？故事板的三列正好解决问题。2.最后剩下了哪些故事没完成？最左边剩下的就是。3.有没有人不是一个一个完成故事，而是同时开工了很多故事？（这个是最后很多故事都开工了但都差一点完成不了的主要原因）这个复杂一些，下面讲。同时开工很多故事，很容易造成思绪散乱、最后全部完不成的情况，确切说瀑布模型就是同时开工所有故事的典范。为了防止这一点，如果是手工做的故事板，，那么注意中间一个“正在做的”列一点要窄一些，这样当里边的故事挤不下的时候，就是一个危险的很多故事都在开工的信号。还有一种做法，是每个人只准放一个故事在中间，做完一个，才能再做一个。这个严格坚持有难度，因为经常遇到被卡住的情况，但是作为一种思路和精神应该尽量坚持。4.如果有跟进人，谁负责跟进哪个？可以在卡片上写上当前负责人、跟进人的名字。通常的做法有很多种，比如每个人用自己颜色的即时贴，可以比较容易地看出每个人有多少个故事，分别处于什么状态。不过，这样就需要在“尚未开始的”里边提前分配人员了，不太利于后期的互动和互相关注；当然还可以在开始的时候重新用有颜色的即时贴重新抄一个，看大家的习惯了。介质尽管有很多故事板/看板工具，使用纸质方法仍然是一个很好的选择，原因就是作为“迭代中的任务”这种东西，其生存期很短，基本上2个月后价值为0，人们也就用纸片来对付了。不过如果想在未来做几件事情，那么及早采用电子故事板/看板还是有必要的，这些事情包括：1.希望统计和分析哪些故事容易完不成、每个月的完成情况等2.大型团队，分布式团队3.希望留下历史数据作为以后估算的参考值和参考故事下面这个是免费工具火星人中的故事板，做了两个案例来说明一下情况。上面这个图是不好的情况，开发中的故事一大堆，没几个完成的，很容易造成最后所有故事都差一点。下面这个要好的多，每个人只开工了1个（每种底色是一个人，案例中只有cheny和yock两个人），剩下的要末完全做完了，要么一点没做，即使到期末不能全部完成，也不会把太多时间卡在半截的故事上。2012-03-07补充：昨天下午仔细调整了美术效果，现在的故事板外观如下：更多敏捷开发日常跟进系列之四：跟进表这是敏捷开发日常跟进系列的第四篇。（栏目目录）跟进表是大型敏捷团队的一种实践。在一个80多人的网络游戏团队中，他们为了清晰地显示整个团队的运作方式，使用了这种方法。跟进表以上面的网络游戏团队为例，说明一下跟进表上的信息：1.哪些故事完成了在故事板中也能表达，但缺少结构性。故事板中的故事都是平等的，较难显示大小、父子包含关系等。2.谁在跟进案例中这个人一般是策划人员，故事的创建者和验收者。3.谁在开发案例中这个一般是若干个开发人员、脚本、美术的群体，也可能只有其中一个工种。4.某个任务大概可能在何时开始、结束。在故事板、燃尽图上均无法表达。5.哪些故事被搁置了可能遇到了困难，也可能有其他原因，甚至可能做了一半干别的被忙忘了。……实例这是一个在“火星人”研发中已经完成的迭代的跟进表案例。实例一我们先看看这个迭代的燃尽图（看不清楚请右键-图片另存为后观看）：对于跟进图的5个作用，上面这个已经扩展了的燃尽图只能完成第一个，就是“哪些故事完成了”，而一般的燃尽图连这个作用也没有。为了完成另外四个目标，就需要下面的跟进表。先看左边的蓝框，里边是所有迭代中的故事（SprintBacklog），为什么要显示成这个树状结构呢？因为如果是小团队，只有10～20个故事，那么人们即使从只有3个字的故事名称比如“新界面”上，大家也能记住和理解说的是什么意思。但是如果故事多了，就比较困难，会导致故事的名字不得不很长，比如“计划会-讲解故事-的新界面”，而这样表达看似还行，但由于没有清晰的父子包含关系，多了也乱。所以蓝框中以父子关系的方式表达，对于大型产品的研发更清晰一些。蓝框右边两列是负责人（对应跟进人，案例中的策划人员）和当前负责人（开发人员），由于我们的团队小，不存在两个部门，所以没有设置跟进人，所以也就没有“负责人”。三个黄框（一横两竖）所框住的表格的底色有的是绿色，有的是粉红色，绿色是加班，粉红色则是假期或休假。左边竖框标明15日大家集体加班，原因是右边竖框中大家19日集体放假外出春游；横向的黄框则标明yock在这个月有大量休假，他只能在特定日期完成工作。为什么要管理这些呢？有时候看似燃尽图正好指向0点，但那个地方可能正好是春节、五一、元旦什么的，有了对假期的整体把握，对重要的上线活动就降低了风险。红框中的故事看上去就有点异常，因为尽管整个迭代结束了，它的剩余时间居然还是“1人天”，所以这个故事没有完成，它停在了17日。实例二下面的图，是调整了一些数据，并将系统时间调整到2.26，模拟一个正在进行中的迭代。从最右边可以看到有4个故事没有完成，其中两个是尚未开始（最上面和最下面两个浅色的），另外两个则是遇到了障碍，卡在了17日和24日，之后没有进展。作为项目经理和技术经理，在跟进表中看到遇到障碍的故事，就要及时询问和协调；作为程序员，也应该在每日立会上报告被卡住的故事。沉默的程序员，又聋又瞎的项目经理（越大型团队的项目经理就越严重），是造成大型项目纠缠不清最终失败的重要原因。敏捷开发日常跟进系列之五：用户故事与MVC用户故事和MVC没有关系，因为MVC是实现方法，因此在思考用户故事的时候，不要一下就想到实现方法，很容易