《敏 捷 教 练：如何打造优秀的敏捷团队》—8.2 大型可视化图表

8.2  大型可视化图表

协助团队设计一张“大型可视化图表”并将它贴到团队板上，提高他们所追踪问题的可见度。团队更容易看到自己是否在改进。例如，回顾会议时团队达成一致想要鼓励轮换结对，于是他们做了一个结对阶梯，可以显示出结对人员是谁、频率如何(参见图8.1)。这将鼓励开发人员每天换一个搭档结对。

图8.1  结对阶梯

留意图表上的信息是否仍然能为团队提供有效反馈。例如，假设团队遇到构建时间长的问题。他们开始做任务，试图降低耗时，并创建了一张构建时间的可视化图表。构建时间降下来了。他们还需要留着这张可视化图表吗？也许，他们可以自动化这个追踪事务。他们可以搭建一个预警系统记录构建时间写入日志，再运行一个脚本来解析日志，如果构建时间超过10分钟，就发出一封警告邮件。

注意，你的身份是教练，引入使用可视化图表需要谨慎，先寻求团队的许可。

燃尽图和燃耗图

你可能已经见过燃尽图，它展示的是迭代中仍需完成的工作量，例如图8.2。它最直接地体现了团队对当前进展情况的信心。

图8.2  手绘燃尽图

燃尽图的痛点在于更新。如果燃尽图是以电子形式存储的，那么团队就需要在软件中更新剩余时间(通常是一个电子表格)才能得出新的燃尽线。不用想也知道，所有团队成员都能在每日晨会前认真完成这些操作有多大可能。

我们发现，大多数团队都偏好“燃尽”任务卡的估值，也就是开每日站会的时候，划掉旧估值写上新估值。接着某个人就会根据当天总的剩余工作量，更新团队板上的手绘燃尽图。沿用此方式能够帮助团队更清楚地知道他们是否能够完成所有故事。凡是影响开发工作的情况都要标注在图表上，比如说团队有人缺席的情况。可以先留着燃尽图，等到迭代结束时审查完(演示会议或回顾会议均可)再丢掉。

图8.3  发布燃耗图

燃耗图往往更加有效，它描绘了下一次发布前各迭代所完成故事点数的情况(如图8.3所示)。团队可以每完成一个故事就更新这个图，这样一来，在这次发布中，团队进展如何，大家也就一目了然了。

在图8.3中，团队绘制了已完成故事点和要做的故事点总数两条线。上一条线显示了发布中故事增加和删除的情况，下一条线显示了他们距离“完成”还有多远。

如果差距很明显，那么团队需要削减下一次发布的用户故事数。如果团队看似无法按照原计划交付，就要确保团队将此消息告知客户和其他关键干系人。

对正确的东西进行度量
Liz

我合作过的一个团队使用发布燃耗图对故事进行追踪，不过他们标示为“已完成”的故事只表明开发人员的工作已结束，并未交给测试人员测试，也没有跟客户核查。为了确保在发布日可以做到所有故事已构建完成，整个团队都非常努力地工作着。然而，为真正完成故事所付出的这些努力却无法在发布燃耗图上显现出来。

随着发布日期逐渐逼近，未解决问题的清单也越来越长。团队不得不区分优先次序，哪些缺陷要修复，哪些缺陷无法按时修复。

最终他们还是发布了，但时间推迟了，质量也不如预期，这一切都是因为他们追踪的是开发人员声称已完工的故事，而不是真正已全部完成的故事。