敏捷开发日常跟进系列之

1、敏捷开发日常跟进系列之一：燃尽图（上）这个系列将涉及燃尽图（Burndown Chart）、故事板（看板）、每日立会等内容，描述在计划会之后，评审会之前，敏捷开发团队内部产出与产品经理和项目经理的各种活动。日常跟进中的某些内容比如团队工作模型、预估会议、用户故事跟进等在之前的松结对编程、团队管理、用户故事、产品管理等系列中有所描述。在这个系列之前，还应该有一个敏捷计划系列，描述敏捷开发的从版本规划到计划会估算的详细内容，未来将会补上，当前可以参考2.29版的火星人敏捷开发手册，有5页与其相对应。燃尽图燃尽图Burdown Chart也叫燃烧图，是罕见的敏捷度量，以至于每当有人问起“敏捷中有度量

2、吗”的时候，第一反应就是它。燃尽图的全称，应该是“总剩余时间的燃尽图”，就是本次迭代中，所有故事（或拆分的任务，以下仅称故事）的剩余时间总和，随日期的变化而逐日递减的图。图中左侧460是迭代开始的第一天，所有故事的未完成时间相加为460天，而在最右侧则表明在第17天，所有故事的剩余时间相加变为0，也就是所有故事都完成了。为什么总和会递减呢？因为每个组员每天都要汇报一件事情：当前正在做的故事，还剩余几天，如果昨天剩余3天，今天剩余2天，那么就为燃烧图贡献了1天的进度。由于可能出现“昨天剩余3天，又工作了一天后本以为会只剩下2天，结果感觉可能还要3天（甚至变成5天了！）”这种情况，所以燃尽图常常有

3、一些起伏。燃尽图的“指纹”图中的燃尽图尽管有一些起伏，依然是属于比较完美的燃尽图。实际上每个团队完成迭代的过程差别很大，常见的情况包括：先鼓起后落下原因是计划会以常常漏掉一些事情，所以开工后不但不燃尽，还发现了很多新的任务。先完美燃烧，然后突然停止燃烧一种很常见的情况，如果任务划分太粗，比如长达10天，很容易“做了1天，剩9天；做了1天，剩8天；到剩23天的时候，哎呀，好像搞不定了”。先缓慢燃烧，然后到快燃尽的时候剩下一堆没完成的任务，被推迟到下个迭代之前提到过敏捷开发的MoSCoW方法，有些故事是次要的“可以不做的”，所以这种燃烧图也很常见；但是常常有团队没有使用MoSCoW方法，只是被动地

4、发现有些故事没有完成。为了改进这些不完美，有些团队设置了一些度量项来改进燃尽图的结果，比如“迭代按时燃尽的次数”“剩余故事占总故事的比例”其实不用因为燃尽图的不完美而伤脑筋，在般若敏捷的“无住”中曾经提到，这些方法都非我们的目的，而只是一个中间的工具，因此为了完成我们的最终目的，这些工具和方法都可以灵活变通，而不要追求工具和度量数据本身的完美。但是，迭代的最终目的到底是什么呢？有哪些“灵活变通”可以应用在燃尽图中呢？且待下回分解。敏捷开发日常跟进系列之二：燃尽图（中）迭代及燃尽图的目标燃尽图的目标是完成迭代的目标，迭代的目标是什么呢？1.按产品经理的要求，交付计划会中计划的用户故事2. 尽量完

5、成1之后还会看到，这个定义还有狭隘之处，在系列后面的文章中会提到。为什么燃尽图不能直接地达成这个目标？潜在的问题包括：1. 如果燃尽图按时完成，有可能是为了按时完成，同时牺牲了所有故事（重要和不重要的）的质量，换取了进度。2. 如果燃尽图未按时完成，有可能不是一个故事没有完成，而是所有故事都剩下点活没做完，导致所有故事都无法交付。3. 如果燃尽图未按时完成，没有完成的故事中，有可能包括了极其重要的一些。只从燃尽图的形态看，是无法提前识别这三者的，也就因此带来了很多的风险，到迭代的末尾让人大吃一惊。怎么办呢？“阶梯燃尽图”之前听过这个方法，但是刚才在网络上没有找到图片。方法就是在每个故事完成的时

6、候才把整个故事突然剪掉，从而形成阶梯状。阶梯状燃烧图的缺点也很明显：刚开始的时候很难看到有燃尽，甚至那些向上拱起的弧形也被掩盖了，日后回顾时，一些细节也很难记起来。所以一种解决方案，是把普通燃尽图和阶梯燃尽图混合使用，就是同时画两条线。“跟进图”跟进图是一些大型团队的创造，由于团队巨大，所以不能指望在迭代的最后用2小时评审完所有工作，所以常常是做完一个评审一个，这就要给每个工作分配一个“跟进人”，他隶属产品部门，没事就盯着“跟进图”看看有没有自己关心的工作做完了。在为一家游戏公司提供咨询的时候，他们一款产品的团队人数高达88人（另一个甚至到了200人），墙上就用手绘制了一幅巨大的跟进图，每天更

7、新动态，甚至直接在纸上画上小图标，每月画满了，就重新打印一张。下面这张，是火星人中的跟进图。图中绿色粗线，就是传统的燃尽图；每当一个故事完成，就会有一个蓝色的标记及完成故事的名字，从而提醒跟进人进行现场预评审；如果长期没有故事完成，燃烧图却还在燃烧，就肯定出现了之前说过的问题了。右下部分还有一个暗红色的细线，是“溢出时间”，就是超出预期的工作的时间，表明这段时间出现了新的任务；新任务出现的太早不好，因为一般在迭代前期都先完成最重要的故事，不应该引入新任务；但在后期随着最重要的故事完成、评审、因不满意而返工，团队会倾向于把最重要的任务更好地完成，而非草草地把所有故事都凑合完成，在产品研发中，这往

8、往是更能提升产品价值的。一家叫做广联达的公司在实践中把溢出时间作为负数倒着画，称为“基线下沉”，就是说要去的地方不是0了，而是那个负数，是一个类似目的的很好的实践。我试了一下也不错，就是图表会变高，显示起来不方便，所以还是改了回来。这样的跟进图看起来已经很强大了，但是还有一些问题没有解决：1. 有哪些故事正在做，还没有做，已经开工了但没完成？2. 最后剩下了哪些故事没完成？3. 有没有人不是一个一个完成故事，而是同时开工了很多故事？（这个是最后很多故事都开工了但都差一点完成不了的主要原因）4. 如果有跟进人，谁负责跟进哪个？有些问题需要后面的故事板（看板）解决，有些则需要一个叫做“跟进表”的东

9、西，之后我们说完故事板再回来详细说明。敏捷开发日常跟进系列之三：故事板，看板故事板和看板其实不是一个东西，前者是最初的敏捷开发里边的东西，受到了后者的启发产生的；而后者是制造业的东西，具体内容请参考末尾的百度百科。但是在敏捷开发里边提到这两样东西，可以认为大致相同。故事板简单说，故事板是展示迭代中的用户故事和任务的方法，在硝烟中的Scrum和XP的封面上就印着一个典型的故事板：一般故事板分为三列：To Do还没做的, Doing正在做的, Done做完的（有各种各样的中英文写法，大同小异）有些团队的分工比较多，会出现一些中间状态，比如“还没做的/正在开发的/等待测试的/正在测试的/等待评审的”

10、是一种典型的开发与测试分离的故事板。故事板的用法要解决的问题故事板可以帮助解决一些燃尽图解决不了的问题（见上篇）：1. 有哪些故事正在做，还没有做，已经开工了但没完成？故事板的三列正好解决问题。2. 最后剩下了哪些故事没完成？最左边剩下的就是。3. 有没有人不是一个一个完成故事，而是同时开工了很多故事？（这个是最后很多故事都开工了但都差一点完成不了的主要原因）这个复杂一些，下面讲。同时开工很多故事，很容易造成思绪散乱、最后全部完不成的情况，确切说瀑布模型就是同时开工所有故事的典范。为了防止这一点，如果是手工做的故事板，那么注意中间一个“正在做的”列一点要窄一些，这样当里边的故事挤不下的时候，就

11、是一个危险的很多故事都在开工的信号。还有一种做法，是每个人只准放一个故事在中间，做完一个，才能再做一个。这个严格坚持有难度，因为经常遇到被卡住的情况，但是作为一种思路和精神应该尽量坚持。4. 如果有跟进人，谁负责跟进哪个？可以在卡片上写上当前负责人、跟进人的名字。通常的做法有很多种，比如每个人用自己颜色的即时贴，可以比较容易地看出每个人有多少个故事，分别处于什么状态。不过，这样就需要在“尚未开始的”里边提前分配人员了，不太利于后期的互动和互相关注；当然还可以在开始的时候重新用有颜色的即时贴重新抄一个，看大家的习惯了。介质尽管有很多故事板/看板工具，使用纸质方法仍然是一个很好的选择，原因就是作为

12、“迭代中的任务”这种东西，其生存期很短，基本上2个月后价值为0，人们也就用纸片来对付了。不过如果想在未来做几件事情，那么及早采用电子故事板/看板还是有必要的，这些事情包括：1. 希望统计和分析哪些故事容易完不成、每个月的完成情况等2. 大型团队，分布式团队3. 希望留下历史数据作为以后估算的参考值和参考故事下面这个是免费工具火星人中的故事板，做了两个案例来说明一下情况。上面这个图是不好的情况，开发中的故事一大堆，没几个完成的，很容易造成最后所有故事都差一点。下面这个要好的多，每个人只开工了1个（每种底色是一个人，案例中只有cheny和yock两个人），剩下的要末完全做完了，要么一点没做，即使到

13、期末不能全部完成，也不会把太多时间卡在半截的故事上。2012-03-07补充：昨天下午仔细调整了美术效果，现在的故事板外观如下：更多敏捷开发日常跟进系列之四：跟进表这是敏捷开发日常跟进系列的第四篇。（栏目目录）跟进表是大型敏捷团队的一种实践。在一个80多人的网络游戏团队中，他们为了清晰地显示整个团队的运作方式，使用了这种方法。跟进表以上面的网络游戏团队为例，说明一下跟进表上的信息：1. 哪些故事完成了在故事板中也能表达，但缺少结构性。故事板中的故事都是平等的，较难显示大小、父子包含关系等。2. 谁在跟进案例中这个人一般是策划人员，故事的创建者和验收者。3. 谁在开发案例中这个一般是若干个开发人

14、员、脚本、美术的群体，也可能只有其中一个工种。4. 某个任务大概可能在何时开始、结束。在故事板、燃尽图上均无法表达。5. 哪些故事被搁置了可能遇到了困难，也可能有其他原因，甚至可能做了一半干别的被忙忘了。实例这是一个在“火星人”研发中已经完成的迭代的跟进表案例。实例一我们先看看这个迭代的燃尽图（看不清楚请右键-图片另存为后观看）：对于跟进图的5个作用，上面这个已经扩展了的燃尽图只能完成第一个，就是“哪些故事完成了”，而一般的燃尽图连这个作用也没有。为了完成另外四个目标，就需要下面的跟进表。先看左边的蓝框，里边是所有迭代中的故事（Sprint Backlog），为什么要显示成这个树状结构呢？因为

15、如果是小团队，只有1020个故事，那么人们即使从只有3个字的故事名称比如“新界面”上，大家也能记住和理解说的是什么意思。但是如果故事多了，就比较困难，会导致故事的名字不得不很长，比如“计划会-讲解故事-的新界面”，而这样表达看似还行，但由于没有清晰的父子包含关系，多了也乱。所以蓝框中以父子关系的方式表达，对于大型产品的研发更清晰一些。蓝框右边两列是负责人（对应跟进人，案例中的策划人员）和当前负责人（开发人员），由于我们的团队小，不存在两个部门，所以没有设置跟进人，所以也就没有“负责人”。三个黄框（一横两竖）所框住的表格的底色有的是绿色，有的是粉红色，绿色是加班，粉红色则是假期或休假。左边竖框标

16、明15日大家集体加班，原因是右边竖框中大家19日集体放假外出春游；横向的黄框则标明yock在这个月有大量休假，他只能在特定日期完成工作。为什么要管理这些呢？有时候看似燃尽图正好指向0点，但那个地方可能正好是春节、五一、元旦什么的，有了对假期的整体把握，对重要的上线活动就降低了风险。红框中的故事看上去就有点异常，因为尽管整个迭代结束了，它的剩余时间居然还是“1人天”，所以这个故事没有完成，它停在了17日。实例二下面的图，是调整了一些数据，并将系统时间调整到2.26，模拟一个正在进行中的迭代。从最右边可以看到有4个故事没有完成，其中两个是尚未开始（最上面和最下面两个浅色的），另外两个则是遇到了障碍

17、，卡在了17日和24日，之后没有进展。作为项目经理和技术经理，在跟进表中看到遇到障碍的故事，就要及时询问和协调；作为程序员，也应该在每日立会上报告被卡住的故事。沉默的程序员，又聋又瞎的项目经理（越大型团队的项目经理就越严重），是造成大型项目纠缠不清最终失败的重要原因。敏捷开发日常跟进系列之五：用户故事与MVC用户故事和MVC没有关系，因为MVC是实现方法，因此在思考用户故事的时候，不要一下就想到实现方法，很容易把故事写坏。但是MVC和用户故事有很大的关系，如果用户故事写好了，做MVC的时候，一定要记得参考用户故事。本人在C+的年代用过MVC，但那个时候MVC还只是一种编程思想，说用了也行，说没

18、用也行。但到了C#之后，就出现了正牌的自称是MVC的东西（现在最新版本是MVC3），本人也在用。Java世界也有MVC的概念，但是没有见识过，下文中所描述的MVC，若没有特殊说明，均指A MVC；但相信对Java中的MVC也有借鉴意义。利用MVC实现用户故事的技法如果您已经认可之六中产生用户故事的方法，那么也就得到了这样的一个用户故事树，右边则是为其量身定做的Controller-Action（来自实际项目）：=下面是对应的Controller-ActionsUsersController-Users/Index-什么也不是-/Users/Details-/Users/User2A

19、uthorities-/Users/Users2Roles-/Users/Freeze-/Users/Edit-/Users/Delete-/Users/BatchCreateRolesController-Roles/Edit-Roles/Details-Roles/Delete-Roles/IndexAuthoritesController-Authorities/URA-Authorities/Delete-什么也不是-Authorities/Index-什么也不是-/Authorities/Authorities2Roles-/Authorities/URGA=注意看每个Control

20、ler实现了一个史诗故事（要管理的数据），每个Action则实现了一个（偶然多个）用户故事（用户的业务操作），有几个值得注意的地方：1. 一个Controller几乎正好可以实现一个史诗故事2. 一个Action因为正好是一个动词，所以几乎正好和一个用户故事对应。有两个地方违反了，如“角色首页（新建+查看）”和“权限首页（新建+查看）”，因为为了方便我们在两个Index里边放了个新建用的TextBox，方便直接创建（因为角色和权限都只有一个名字而已，所以觉得犯不上做个独立页面了）。为了能记住这一点，我们在故事的缩写名字上加了（XX+XX）的标记，为了日后能自动计数故事。3. 用户没有“创建”故

21、事，也没有Users/Create，因为用户只有两种正常的创建方法：Register和BatchCreate，我们选择了后者。因此既没有“创建用户”这个故事，也没有“/Users/Create”这个Action。4. 几个绿色箭头是“增强”类型的故事（详见之五），它们正好也不对应Action。上面提到的是我们实际的一种用法，未必是普适的，但在我们项目中非常适合，甚至应该称为“舒服极了”。这种史诗-故事与Controller-Action之间偶然的巧合，实际上背后有其必然性。利用MVC实现用户故事的心法MVC以往研究的重点，是何为M，何为V，何为C，以及三者之间的关系。我们在用了一段时间后，发现

22、其中的每一个，都还有更深层次的理念在里边，这里谈的就是Controller及其Action。在MVC三者呆在一起的时候，问：何为Controller？估计还是挺容易回答的。但如果不提MV，直接问：何为一个Controller？何为一个Action？却挺难回答的。如果去一个非MVC的网站或软件，最令人烦恼的，是网站的每个页面未必有自己独立的链接，比如逛了半天，顶上的链接一直是http:/xxx./login=xxxx，想为某个页面加个收藏夹都不行。MVC在很大程度上解决了这个问题：要操作的数据是Controller，要做的操作是Action，而参数则是具体操作谁，比如/Users/Details

23、?user=cheny或CSDN博客上常见的：/cheny_com/article/details/样式。所以如果已经按照之六中提到的数据-操作方法来组织史诗-故事结构了，而且又在使用MVC,则非常推荐编程时将其继续映射到Controller-Action中。可能细心的读者已经注意到本文图中有些故事后面有个链接符号，那个正是我们在已经实现了的即金色的故事的后面，加上了其超链接（全部是/Controller/Action，一一对应，非常舒服）。这相当于一个Action写好了，一个故事（偶然情况是多个）就正好也完了；而测试人员就可以点击那个链接去到Action

24、测试。他测试完了Action，就能说故事被测试完了（而不只是Action被测试完了）。以这种方式来对应用户故事和开发内容，产品经理和开发人员很容易沟通，因此非常推荐使用。用户故事 vs. FPA功能点分析法 vs. MVC功能点分析法（FPA）、敏捷开发用户故事、A MVC在一定程度上具有相同的目的：作为用户需求与开发人员工作的桥梁，只是侧重点有所不同。因此若能将它们联合应用，就可能用一种组织方式贯穿性地管理估算、需求管理、架构设计三者。完整地表述三者的关系，大致如下：用户故事FPAMVC数据史诗故事ILF内部逻辑文件EIF外部接口文件Controller操作普通故事（功能）EI外

25、部输入EO外部输出EQ外部查询Action敏捷开发日常跟进系列之六：验收标准要想不在评审会上得到“惊喜”，Product Owner最好提前约定好用户故事的验收标准，而且每个用户故事可能各不相同。面向客户价值设定验收标准简单说，就是客户看到说“完成了”，才算完成了。从这一点上说，用户眼中的“可工作软件”和我们认为“可以运行，自动化测试了的，没有缺陷的”软件还是有差别的。用户拿到软件，是要使用从而获得价值的，这常常需要多个功能联合运行，前后数据完整一致才可以做到。在“敏捷产品管理”系列中，还会更加深入地探讨这个话题。下面的例子，很好地表明了客户眼中的完成标准，它是EA（电子艺界，世界最大的游戏发

26、行商和开发商之一）用于判断游戏中不同故事完成标准的。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=

27、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 bu

28、g fixing.G=Great. “完美的”（可以上线而且估计反响强烈的）Shippable and likelyto receive a great review score.为什么要搞这么复杂呢？因为游戏中有些功能，在开发出来之前策划人员也说不明白怎样才是好，但又急于开发出来看看，因此会采用最低标准S，就是能用就行，不测试，不写文档，不做性能优化而另外一些功能，则可能比较正式一些，比如需要给某些玩家看到的，就会选择T或A级别；而正式功能，则会选择G。不同的公司，有不同的客户群，为了不同的目的，需要制定自己相应的完成标准。客户价值与工程实践的映射上面是一个完全面向客户价值编写的完成标准，看

29、起来很好，但是实践起来开发人员很难把握。其实，每个面向客户价值的标准，背后都有相应的工程标准。在熟悉之后，开发人员一望便知。比如下面是上述标准中S和W标准的工程实践描述：W能运行的 =编码完成 单元测试 手工功能测试 压力测试可回归自动测试使用手册S可获得反馈的 =编码完成 单元测试手工功能测试压力测试可回归自动测试使用手册使用方法上述面向价值的描述及其工程实践映射，不是在迭代计划会上现场想的，而是早就在项目之初就在项目甚至组织层面设置好了的。在迭代计划会上，PO每讲完一个故事，都会在团队估算前指出故事完成的标准，这样团队就知道是不是要花费额外的测试、优化等工作量了。不过，即使事先约好完成标准，若PO与开发组分开一个月，仍然可能得到一个”惊喜“。这就需要下篇提到的用户故事的开发与跟进。敏捷开发日常跟进系列之六：开发与跟进产品负责人常常被描述成在计划会前准备好用户故事，在计划会上讲解并帮助开发团队估算后就万事大吉，只等月底接收“可工作软件”的样子，其实如果真的这样，很容易出问题。需求精化这是发生在迭代周期中间的常规活动，产品负责人会与团队密切接触（确切说如果能经常坐在一起更好），在每个故事开发的前夜或中间，将之前讲解过的用户故事更详细地描述一番（有时候是在看到开发一半的半成品后做一些细化或更正）。一般认为产品负责人在开发的中间来打扰开发组工作是不令人欢