PMP考点汇总-敏捷基础概念（三）

1.7 Burn-down Chart——燃尽图

燃尽图（burn down chart）是在项目完成之前，对需要完成的工作的一种可视化表示，向项目组成员和相关方提供工作进展的一个公共视图。

1.7.1 冲刺燃尽图

Sprint 燃尽图用于展示冲刺周期内故事点的变动情况，理想情况下，该图表是一个向下的曲线，随着剩余工作的完成，Sprint 故事点“烧尽”至零。然而实际上，每个迭代都有很多待开发的 Story，在敏捷开发中，工作量的评估是以 Story 为单位的，一个迭代 Story 的数量会影响到燃尽图的 Y 轴。如果 Story 的数量过少，绘制出来的燃尽图就会呈明显的折线形状，也会对速度和风险的判断带来影响。所以，曲线未必能真的代表剩余的工作数量，也不能完美地作为管理层进行项目可视化管理和绩效管理的工具。但它可以反映出项目冲刺规划、管理和进度控制上的一些问题。

以下是某项目某个冲刺周期的燃尽图：

图中曲线在第二周时有三个时间段比较集中地下降，说明团队在这三个时间段比较集中地确认任务已完成；

图中没有比较大的向上的突起，说明冲刺策划工作还算不错，Scrum Master 对冲刺有较强的控制力，没有在冲刺周期内引入过多的新特性；最终曲线没有到达零点，说明冲刺周期内有任务未完成，需要反思是否存在一个冲刺内工作量过多还是、引入了新特性还是存在别的工作效率或团队协作的问题。

而下面这张图反映了项目团队对冲刺的策划和控制可能存在更多的问题：

1.7.2 交付燃尽图

对于 PMO 而言，交付燃尽图可能比冲刺燃尽图更具有实际意义。

冲刺燃尽图反映了一个 Sprint 内工作的“燃尽”情况，而交付燃尽图则展示了在更长的、可能跨越很多个Sprint 周期的情况下，软件是否能如期交付某个版本或某个模块。以下是某项目的某个版本的交付燃尽图。

交付燃尽图中，浅绿色的柱状代表这个 Sprint 完成了的故事点数，所以前面加了个减号；

浅蓝色的柱状代表，在这个 Sprint 开启之前就存在的故事点数，在这个 Sprint 结束时还剩下多少；

​深蓝色的柱状代表，在这个 Sprint 开启后到下个 Sprint 开启前这段时间，版本中增加了多少故事点数，所以用加号。

以下通过 2 个图例说明如何解读交付燃尽图。

1. 较正常的交付燃尽图，可以预测这个版本可以在什么时候交付

两条预测线，上面那条的由来是，浅蓝色柱状的顶部中点，用最小二乘法计算的拟合直线；下面那条则是深蓝色柱状的底部中点，用最小二乘法计算的拟合直线。两条线斜率的意义是，每个 Sprint 故事点数完成的速率和故事点数新增的速率。两条预测线的交点对应的横坐标代表这个版本预计会在哪个冲刺内完成。

2. 存在较大的无法按时交付甚至永远无法交付的风险
   

上图两条预测线，纵坐标轴的右侧没有交点，代表这个版本恐怕存在较大的交付风险，需要注意。如果发现版本无法可能无法交付的时候可以选择的策略，一般是增加开发的速率，或者是减少一些当前版本的故事点数，放到下一个版本中去。

1.8 Fist-of-five——举手表决

举手表决（Fist to five，fist of five）是敏捷软件开发团队用于调查团队成员并帮助达成一致意见的一种技术。使用举手表决技术，Scrum Master 或 PO 重申该团队也许会采取的行为，并要求团队成员展示他们的支持级别。每个团队成员通过举起紧握的拳头或竖起对应支持级别的手指数来回应。如果一个团队成员举起的手指少于 3，他有机会陈述其反对意见，团队会给出回应。Scrum Master 或 PO 继续举手表决过程直到达成一致意见（每个人都举起的手指都不小于 3）或同意转移到下一话题。

紧握拳头：不，我完全不同意。

1 根手指：我非常担心。

2 根手指：我想讨论一些小问题。

3 根手指：我不完全同意但我可以接受意见通过而不须进一步讨论。

4 根手指：我认为想法不错且愿意为其工作。

5 根手指：想法棒极了，执行时我愿意带头。

1.9 需求空间、开发空间和测试空间

通常，一个项目的开发过程，可以通过 3 个空间来进行表达：需求空间、开发空间和 QA 测试空间。3 个空间相互间应当是完全整合的，使得整个团队的不同职能能够相互协作。其中：

1. 需求空间：存放、描述项目所有待实现的需求，表现为 Product Backlog，由 PO 主导并管理，所有团队成员可以参与梳理。

2. 开发空间：包含项目正在开发实现的所有事项，表现为 Sprint Backlog 和 Scrum Board，在 Scrum Master指导下由开发团队共同管理。

3. 测试空间：管理项目的测试计划和测试用例，是项目的一系列质量目标和验收标准，由 QA 主导管理。当Sprint 开始后，QA 根据 User Story 编写对应的测试用例，加入 QA 空间；当开发人员提交到 To QA 后，QA 根据测试用例执行测试，反馈测试结果。此外，还包括其他不同级别的测试计划和用例。