敏捷开发日常跟进系列之1-6.docxVIP

敏捷开发日常跟进系列之一：燃尽图（上） 这个系列将涉及燃尽图（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人），墙上就用手绘制了一幅巨大的跟进图，每天更新动态，甚至直接在纸上画上小图标，每月画满了，就重新打印一张。 下面这张，是火星人中的跟进图。 ? 图中绿色粗线，就是传统的燃尽图； 每当一个故事完成，就会有一个蓝色的标记及完成故事的名字，从而提醒跟进人进行现场预评审；如果长期没有故事完成，燃烧图却还在燃烧，就肯定出现了之前说过的问题了。 右