浅谈BurnDown Chart （原创）

Posted 2023-04-16

参考技术A 燃尽图（burn down chart）是在项目完成之前，对需要完成的工作的一种可视化表示。我们经常用到的燃尽图有两种类型，一是基于任务（task）的燃烧；另一种是基于故事点（Story point）的燃烧。燃尽图经常用在敏捷项目里，如果从迭代周期的维度看，还可以分成Sprint的燃尽图，用来记录Sprint的进度；也可以是release的燃尽图，用来记录整个scrum项目的进度。

上图是一个典型的sprint（iteration）燃尽图，如果迭代的Burndown Chart一直是上升状态，或当Sprint进行一段时间之后，Sprint Burndown Chart上当前点的Y值仍然与Sprint刚开始时相差无几，就说明这个Sprint中的任务过多，要拿掉一些story以保证这个迭代能顺利完成。如果Sprint Burndown Chart下降得很快，例如Sprint刚过半时Y值已经接近零了，则说明为这个Sprint分配的任务太少，还要多加一些任务进来。在迭代计划会议上，如果团队对即将要做的任务理解和认识不充分，就很可能导致这两种情况的出现。总之，燃烧曲线是衡量团队进度的重要工具。

虽然大家对燃尽图都很熟悉，但我们在实际使用燃尽图的过程中，仍然有过如下 三个疑问 ：

1. 在绘制燃尽图的时候，什么时候选择基于task度量，什么时候选择基于story point度量？

2. 谁来给出起始的故事点或者任务的estimation？

3. 在使用一些项目管理工具的时候，对于task的estimatoin，remaining time以及correction，这些不同的field代表什么意思？谁来给出这些值？何时修改这些值？

疑问1：在绘制燃尽图的时候，什么时候选择基于task度量，什么时候选择基于story point度量？

想要找到这个问题的答案，必须理解这两种燃尽图各自侧重的意义。虽然两者都是用来表示项目或者迭代进度，但story point更多体现的是业务价值的完成，比较宏观；而task关注的是具体任务的完成，较为微观。所以，基于story的燃尽，是在记录燃烧了多少业务价值，离最终交付给客户业务价值还有多远。我们知道衡量一个story是否完成还依赖于DOD（definition of Done)， 不同的团队对DOD有不同的定义，例如有的团队认为story必须经过showcase才算完成，那么会明显影响到基于story point的燃尽曲线。但task关注的是敏捷团队内部的开发情况，是基于person day的，只要这个开发或者测试的任务完成就算DONE。由此可见，story point的燃尽图体现的敏捷流程，关注业务价值的交付，可以暴露诸如测试滞后，协作子系统之间的依赖等问题；task（Person day）燃尽图体现的是开发和测试进度，关注团队内部的完成风险。

所以这两种方式有各自的侧重点，可以同时使用。但对于一个成熟度不是很高的团队来讲，使用task的burn down chart似乎更加现实；如果团队足够成熟，可以均匀地拆分user story，且每个story都比较小，整个组织也比较敏捷的话，就以用story burn down chart来取代task的burn down chart。也可以将两图合并, 同时从基于task working hours的burn down与基于story points的burn up两个视角关注项目进度。

疑问2： 谁来给出起始的故事点或者任务的起始estimation？

对于谁来给出起始故事点数来说，答案比较明显，那就是团队给出。但对于谁来给出具体任务的初始estimation，不同的团队有不同的做法，我们的实践也是团队给出。

在迭代开始的计划会议里，有很大一部分时间是团队一起拆分story，并且给出每个task的estimation。由于person hour和个体关系很大，不同的人对同一个任务预估的时间也不相同，也就说团队一起给出的这个estimation可能是取了一个平均值。

那么问题来了，这样做到底什么意义？平均值会不会不准呢？其实计划会议上所做的所有预估都是为了更好地在团队内达成对业务和工作量上的一致理解，团队不应该把关注点放在准确或不准确上。无论是故事点还是任务的PH，都应该建立在团队每个人对问题的一致理解之上。实际上，根据集体智慧的原理，多人一起预估会更加接近将要发生的实际值，也更能帮助团队做为整体对客户做出承诺。

疑问3：在使用一些项目管理工具的时候，对于task的estimation，remaining time以及correction，这些不同的field代表什么意思？谁来修改这些值？何时修改这些值？

首先要理解，敏捷里所有BVC（big visual chart），首要考虑的就是，这些图形或图表能够真实地反映项目与团队的实际情况，基于task的燃尽图也是如此。通常当进入实际开发，task的owner才会被确定，那么这个owner就可以根据自己实际的开发情况来调整时间。

不同的项目管理工具有不同的设置，例如IBM的RTC，task有三个与时间相关的field，其中estimation就是计划会议上大家一起给定的那个person hours，这个值不会再去修改；第二个是remaining time，这个值相当关键，它直接影响到燃尽图的实际曲线，owner应该频繁地对剩余时间进行修改，以便真实地反应任务的实际进度，一般至少是在下班前或者任务切换时修改；第三个值是correction，代表实际可能要花费的时间，越是接近任务完成的尾声，值越接近实际。这是一个非常令人迷惑的field，因为它十分容易让人联想到事后度量，甚至是绩效评估，而敏捷是反对这类度量的。实际上，correction本意是为了真实的得出remaining hours，在实际的开发过程中，随着时间的推进，owner越来越清楚可能的实际时间花费，这个值也许比计划会议上预计的estimation大，也许比estimation小，owner通过不断调整correction，将它与已经耗费的小时数做减法，从而得出剩余时间，使得燃尽图始终保持能够真实反映迭代进度的能力。此外，IBM RTC 自动生成的燃尽图也会有一条线是专门反映预估与实际的差距，可以用于帮助团队逐渐改进自己的计划会议。所以，correction也应该是随时可以修改的，并且修改的人是task owner。

举一个极端的例子来说明一下，假设一个迭代有6天，这个迭代里只有一个任务，estimation是24ph。进行到第三天的时候（已花费12小时），程序员突然意识这个任务要比原来想象中复杂，于是调整correction为30ph，remaining time变成18ph （correction - 已花费）。由下图一可知，更改correction是会影响planned以及Remaining这两条曲线。当然在实际的操作上，尤其是团队采用物理看板，由人工去维护燃尽图的时候，通常只需要简化成图二。当然，一个迭代是由多个task组成，那么整个燃尽图实际上是所有task不断更改correction与remaining time的效果叠加，籍此将Risk和Progress透明化，指导团队及时做出适应与调整。

一个敏捷团队在开始使用燃尽图的时候，容易陷入一个误区，就是将注意力放在生成漂亮的曲线上，而不是项目本身，这就失去了燃尽图的意义。所以作为管理层绝对不能过分依赖它作为监督和考核的依据，否则就会产生bed smell。

技术分享 | 浅谈 MySQL 的临时表和临时文件

作者：姚嵩

爱可生南区交付服务部经理，爱好音乐，动漫，电影，游戏，人文，美食，旅游，还有其他。虽然都很菜，但毕竟是爱好。

本文来源：原创投稿

*爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。

---

本文内容来源于对客户的三个问题的思考：

1. 哪些 SQL 会产生临时表/临时文件
2. 如何查看已有的临时表
3. 如何控制临时表/临时文件的总大小

说明：

以下测试都是在 MySQL 8.0.21 版本中完成，不同版本可能存在差异，可自行测试；

首先，让我们了解下什么是临时表|临时文件？

临时表和临时文件都是用于临时存放数据集的地方；

一般情况下，需要临时存放在临时表或临时文件中的数据集应该符合以下特点：

• 数据集较小(较大的临时数据集一般意味着 SQL 较烂，当然有例外项)
• 用完就清理(因为是临时存储数据集的地方，所以生命周期和 SQL 或者会话生命周期相同)
• 会话隔离(因为是临时数据集，不涉及到与其他会话交互)

• 不产生 GTID

从临时表|临时文件产生的主观性来看，分为2类：

• 用户创建的临时表
• SQL 产生的临时表|临时文件

用户创建临时表：

  用户创建临时表(只有创建临时表的会话才能查看其创建的临时表的内容)

create database if not exists db_test ;
use db_test ;
CREATE TEMPORARY TABLE t1 (c1 INT PRIMARY KEY) ENGINE=INNODB;
select * from db_test.t1 ;

  注意：

  可以创建和普通表同名临时表，其他会话可以看到普通表(因为看不到其他会话创建的临时表)；

  创建临时表的会话会优先看到临时表；

  同名表的创建的语句如下

CREATE TABLE t1 (c1 INT PRIMARY KEY) ENGINE=INNODB;
insert into  t1 values(1);

  当存在同名的临时表时，会话都是优先处理临时表(而不是普通表)，包括：select、update、delete、drop、alter 等操作；

查看用户创建的临时表：

  任何 session 都可以执行下面的语句；

  查看用户创建的当前 active 的临时表(不提供 optimizer 使用的内部 InnoDB 临时表信息)

SELECT * FROM INFORMATION_SCHEMA.INNODB_TEMP_TABLE_INFO\\G

  注意

  用户创建的临时表，表名为t1，

  但是通过 INNODB_TEMP_TABLE_INFO 查看到的临时表的 NAME 是#sql开头的名字，例如：#sql45aa_7c69_2 ；

  另外 information_schema.tables 表中是不会记录临时表的信息的。

用户创建的临时表的回收：

1. 会话断开，自动回收用户创建的临时表；
2. 可以通过 drop table 删除用户创建的临时表，例如：drop table t1;

用户创建的临时表的其他信息&参数：

  会话临时表空间存储 用户创建的临时表和优化器 optimizer 创建的内部临时表(当磁盘内部临时表的存储引擎为 InnoDB 时)；

  innodb_temp_tablespaces_dir 变量定义了创建 会话临时表空间的位置，默认是数据目录下的#innodb_temp 目录；

  文件类似temp_[1-20].ibt ；

  查看会话临时表空间的元数据：

select * from information_schema.innodb_session_temp_tablespaces ;

  用户创建的临时表删除后，其占用的空间会被释放(temp_[1-20].ibt文件会变小)。

  在 MySQL 8.0.16 之前，internal_tmp_disk_storage_engine 变量定义了用户创建的临时表和 optimizer 创建的内部临时表的引擎，可选 INNODB 和 MYISAM ；

  从 MySQL 8.0.16 开始，internal_tmp_disk_storage_engine参数被移除，默认使用InnoDB存储引擎；

  innodb_temp_data_file_path 定义了用户创建的临时表使用的回滚段的存储文件的相对路径、名字、大小和属性，该文件是全局临时表空间(ibtmp1)；

  可以使用语句查询全局临时表空间的数据文件大小：

SELECT FILE_NAME, TABLESPACE_NAME, ENGINE, INITIAL_SIZE, TOTAL_EXTENTS*EXTENT_SIZE

AS TotalSizeBytes, DATA_FREE, MAXIMUM_SIZE FROM INFORMATION_SCHEMA.FILES
WHERE TABLESPACE_NAME = \'innodb_temporary\'\\G 

SQL 什么时候产生临时表|临时文件呢？

  需要用到临时表或临时文件的时候，optimizer 自然会创建使用(感觉是废话，但是又觉得有道理=.=!)；

  (想象能力强的，可以牢记上面这句话；想象能力弱的，只能死记下面的 SQL 了。我也弱，此处有个疲惫的微笑