敏捷开发日常跟进系列之二:燃尽图(中)
这是敏捷开发日常跟进系列的第二篇(栏目目录)。
迭代及燃尽图的目标
燃尽图的目标是完成迭代的目标,迭代的目标是什么呢?
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
敏捷开发日常跟进系列之二:燃尽图(中)相关推荐
- 敏捷开发日常跟进系列之一:燃尽图(上)
这是敏捷开发日常跟进系列的第一篇(栏目目录). 这个系列将涉及燃尽图(Burndown Chart).故事板(看板).每日立会等内容,描述在计划会之后,评审会之前,敏捷开发团队内部产出与产品经理和项目 ...
- 敏捷开发日常跟进系列之三:故事板,看板
这是敏捷开发日常跟进系列的第三篇. (栏目目录) 故事板和看板其实不是一个东西,前者是最初的敏捷开发里边的东西,受到了后者的启发产生的:而后者是制造业的东西,具体内容请参考末尾的百度百科.但是在敏捷开 ...
- 敏捷开发日常跟进系列之四:跟进表
跟进表是大型敏捷团队的一种实践.在一个80多人的网络游戏团队中,他们为了清晰地显示整个团队的运作方式,使用了这种方法. 跟进表 以上面的网络游戏团队为例,说明一下跟进表上的信息: 1. 哪些故事完成了 ...
- 敏捷开发用户故事系列之二:如何面向客户价值编写故事
这是敏捷开发用户故事系列的第二篇.(之一,之二,之三,之四,之五,之六,之七,之八,之九) 敏捷开发中的用户故事采用的语法模式看似简单,却蕴含着深刻的思想. "作为一个--,可以--,以(以 ...
- 敏捷开发团队管理系列之二:程序与测试团队I
这是敏捷开发团队管理系列的第二篇.(之一,之二,之三,之四) 几个真实案例 这几个团队都是我自己亲身经历的团队,从质量的角度来分析敏捷团队的工作方式. 第一个是一个较为大型的团队,约有25-30人,研 ...
- 敏捷开发产品管理系列之二:产品版本规划
本文是敏捷开发产品管理系列的第二篇.(序言及设立迭代目标,产品版本规划,产品用户群规划,新产品研发,预估会议,Product Servant,Product Owner团队,产品线管理) 本文是一篇旧 ...
- 敏捷开发用户故事系列之四:优先级排序
这是敏捷开发用户故事系列的第四篇.(之一,之二,之三,之四,之五,之六,之七,之八,之九) 优先级排序听起来是一个很简单的工作,一个字段无外乎"重要/一般--",调整一下然后按排序 ...
- 敏捷开发团队管理系列之三:程序与测试团队II
这是敏捷开发团队管理系列的第三篇.(之一,之二,之三,之四) 测试团队的价值 这样看来,敏捷开发的质量保证问题,都被发开团队解决了,测试团队的价值何在? 这个可以从第一个项目组后来的发展来分析. 在整 ...
- 敏捷开发用户故事系列之一:何为用户故事
这是敏捷开发用户故事系列的第一篇.(之一,之二,之三,之四,之五,之六,之七,之八,之九) 全系列将涉及何为用户故事,面向客户价值编写故事,用户建模,产品待开发项的分类,故事颗粒度,故事的组织结构,等 ...
最新文章
- 如何彻底禁用VS 2008的智能感知功能
- android与PC,C#与Java 利用protobuf 进行无障碍通讯【Socket】
- Throwable、Error、Exception、RuntimeException 区别 联系
- Python学习笔记:第三方模块2
- 续上篇随笔:陈勇提示做分批载入需要用到的数据
- 聊聊 cookie 管理那些事
- 【转】PHP会话Session使用详解
- 不同包之间的继承extends
- struts配置json需要的jar包
- 骑手的困境,资本的压榨
- Mac环境下安装Ruby
- 空气质量监测管理系统
- 求2+22+222+2222+.....的N项之和
- python 正则表达式量词
- 用 mkcert 搭建本地开发受信 HTTPS 证书环境
- jsp mysql问卷调查_课内资源 - 基于JSP的在线调查问卷系统
- php jws 数据签名,JSON Web Signature 规范解析
- matlab均衡的算法有哪些,从Matlab到Python的算法均衡
- 无线通信——调制与编码
- 关于四芯网线上网的奇怪问题
热门文章
- ESXi6.5环境搭建(三:vSphere Client6.0安装)
- java initcause_Java 异常
- 学习Web前端需要避免哪些错误
- 学习UI设计能做什么
- shiro多realm验证之——shiro实现不同身份使用不同Realm进行验证(转)
- oracle 11g wm_concat 、 listagg 函数的使用(合并数据)
- linux 定时任务crond
- 高可用集群之分布式文件系统
- OCM_第十二天课程:Section6 —》数据库性能调优_ 资源管理器/执行计划
- Swift:UIKit中Demo(一)