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

迭代及燃尽图的目标

燃尽图的目标是完成迭代的目标,迭代的目标是什么呢?

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

2. 尽量完成1

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

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

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

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

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

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

怎么办呢?

“阶梯燃尽图”

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

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

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

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

“跟进图”

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

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

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

图中绿色粗线,就是传统的燃尽图;

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

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

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

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

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

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

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

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

4. 如果有跟进人,谁负责跟进哪个?

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

转载于:https://www.cnblogs.com/wodeyitian/archive/2012/02/29/2459886.html

敏捷开发日常跟进系列之二:燃尽图(中)相关推荐

  1. 敏捷开发日常跟进系列之一:燃尽图(上)

    这是敏捷开发日常跟进系列的第一篇(栏目目录). 这个系列将涉及燃尽图(Burndown Chart).故事板(看板).每日立会等内容,描述在计划会之后,评审会之前,敏捷开发团队内部产出与产品经理和项目 ...

  2. 敏捷开发日常跟进系列之三:故事板,看板

    这是敏捷开发日常跟进系列的第三篇. (栏目目录) 故事板和看板其实不是一个东西,前者是最初的敏捷开发里边的东西,受到了后者的启发产生的:而后者是制造业的东西,具体内容请参考末尾的百度百科.但是在敏捷开 ...

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

    跟进表是大型敏捷团队的一种实践.在一个80多人的网络游戏团队中,他们为了清晰地显示整个团队的运作方式,使用了这种方法. 跟进表 以上面的网络游戏团队为例,说明一下跟进表上的信息: 1. 哪些故事完成了 ...

  4. 敏捷开发用户故事系列之二:如何面向客户价值编写故事

    这是敏捷开发用户故事系列的第二篇.(之一,之二,之三,之四,之五,之六,之七,之八,之九) 敏捷开发中的用户故事采用的语法模式看似简单,却蕴含着深刻的思想. "作为一个--,可以--,以(以 ...

  5. 敏捷开发团队管理系列之二:程序与测试团队I

    这是敏捷开发团队管理系列的第二篇.(之一,之二,之三,之四) 几个真实案例 这几个团队都是我自己亲身经历的团队,从质量的角度来分析敏捷团队的工作方式. 第一个是一个较为大型的团队,约有25-30人,研 ...

  6. 敏捷开发产品管理系列之二:产品版本规划

    本文是敏捷开发产品管理系列的第二篇.(序言及设立迭代目标,产品版本规划,产品用户群规划,新产品研发,预估会议,Product Servant,Product Owner团队,产品线管理) 本文是一篇旧 ...

  7. 敏捷开发用户故事系列之四:优先级排序

    这是敏捷开发用户故事系列的第四篇.(之一,之二,之三,之四,之五,之六,之七,之八,之九) 优先级排序听起来是一个很简单的工作,一个字段无外乎"重要/一般--",调整一下然后按排序 ...

  8. 敏捷开发团队管理系列之三:程序与测试团队II

    这是敏捷开发团队管理系列的第三篇.(之一,之二,之三,之四) 测试团队的价值 这样看来,敏捷开发的质量保证问题,都被发开团队解决了,测试团队的价值何在? 这个可以从第一个项目组后来的发展来分析. 在整 ...

  9. 敏捷开发用户故事系列之一:何为用户故事

    这是敏捷开发用户故事系列的第一篇.(之一,之二,之三,之四,之五,之六,之七,之八,之九) 全系列将涉及何为用户故事,面向客户价值编写故事,用户建模,产品待开发项的分类,故事颗粒度,故事的组织结构,等 ...

最新文章

  1. 如何彻底禁用VS 2008的智能感知功能
  2. android与PC,C#与Java 利用protobuf 进行无障碍通讯【Socket】
  3. Throwable、Error、Exception、RuntimeException 区别 联系
  4. Python学习笔记:第三方模块2
  5. 续上篇随笔:陈勇提示做分批载入需要用到的数据
  6. 聊聊 cookie 管理那些事
  7. 【转】PHP会话Session使用详解
  8. 不同包之间的继承extends
  9. struts配置json需要的jar包
  10. 骑手的困境,资本的压榨
  11. Mac环境下安装Ruby
  12. 空气质量监测管理系统
  13. 求2+22+222+2222+.....的N项之和
  14. python 正则表达式量词
  15. 用 mkcert 搭建本地开发受信 HTTPS 证书环境
  16. jsp mysql问卷调查_课内资源 - 基于JSP的在线调查问卷系统
  17. php jws 数据签名,JSON Web Signature 规范解析
  18. matlab均衡的算法有哪些,从Matlab到Python的算法均衡
  19. 无线通信——调制与编码
  20. 关于四芯网线上网的奇怪问题

热门文章

  1. ESXi6.5环境搭建(三:vSphere Client6.0安装)
  2. java initcause_Java 异常
  3. 学习Web前端需要避免哪些错误
  4. 学习UI设计能做什么
  5. shiro多realm验证之——shiro实现不同身份使用不同Realm进行验证(转)
  6. oracle 11g wm_concat 、 listagg 函数的使用(合并数据)
  7. linux 定时任务crond
  8. 高可用集群之分布式文件系统
  9. OCM_第十二天课程:Section6 —》数据库性能调优_ 资源管理器/执行计划
  10. Swift:UIKit中Demo(一)