如何制作一份行之有效的Sprint摘要文档?

如何制作一份行之有效的Sprint摘要文档?

一个敏捷sprint或迭代的结束应该是相对轻量级的行为。毕竟,这是一件每个月至少要进行一次的事情。为让团队免除不必要的仪式环节负担,通常一个非常简洁的sprint回顾就足够了。

那么,这份包含重要信息点的回顾应该怎样生成?回顾的重要性如何体现?回顾中应包含哪些行之有效的内容呢?

一、Sprint摘要文档

作为一个CSM,我喜欢生成一个sprint摘要文档。这个简短的文档中记录了sprint期间非常精简的细节,例如某个sprint期间完成了什么工作、sprint的时间段、参与者、重要决策、以及一些关键的标准数据等。

受众

Sprint摘要文档有两类目标受众。首先是任何项目团队外但对该项目感兴趣的人员。他们可能是开发副总裁、执行人员、利益相关者、部门管理人员、或其他团队成员等等。

第二类受众是逐渐成长的敏捷团队自身。我碰到过团队想要回顾项目历程的情况。而此时,sprint摘要就可以提供回顾全局的素材。我举个例子。

一个团队对他们编写的自动化测试程序如此之少感到沮丧,在之前的sprint过程中,他们一共只添加了大约200个自动化测试程序,他们知道这与系统需求相距甚远。因为团队CSM一直在生成sprint摘要文档,所以我检索了6个月前的sprint摘要文档。而后我与团队回顾分享了他们曾经在每个sprint期间只能编写出一两个自动化测试程序的经历。(他们重构代码以便于支持自动化测试程序,并学习了相关概念和工具。通过回顾,我帮他们意识到团队的发展进程。虽然还有很长的路要走,但他们已经打开局面,并且势头强劲。

如果没有sprint摘要文档来提供准确客观的信息,我们将不得不依靠记忆,或者必须通过挖掘源代码存储库来拼凑细节片段。

二、内容

虽然sprint摘要文档的具体内容因人而异,但是我发现有些内容是非常有效的,其中包括:

1.背景

简单地列出sprint的起始日期以及天数。还有团组成员、每人预计可用天数、以及每个人大致的实际可用天数。

例如,团组成员的实际工作天数可能与计划可用天数不同,比如病假、或在sprint期间被牵扯进其他项目。

2.数据指标

包含任何对CSM、利益相关者或团队有重要意义的标准数据。简洁直白的来说,我倾向于用一张可以体现最近10次左右(或您认为合理的范围)的sprint效率图表或表格。如果你正在使用燃尽表,那么这些已经包含在内。

还可以考虑的内容包括:发现或修复的瑕疵数量、添加的自动化测试程序数量、代码覆盖率、部署的构建数量等等。

如果您正在为客户端构建软件,需要汇报成本,还可在数据项目中增加计费工时和成本等内容。 但要切记保持简洁。

3.内容和评估

包含团队计划完成的每个产品的待办事项列表,并标明是否完成。如果团队评估产品待办事项列表项(例如,故事点),则需包括故事点的大小。

还包括sprint评审中关于相关决策的全部附加注释。

最后,考虑包含一个操作列表来体现sprint回顾的结果。这是在确保团队可接受的情况下的可选 项。

三、制作摘要的时间要短

一旦生成了最初的sprint摘要文档,你会发觉为每个sprint创建新文档是非常简单的。如果您可以保证数据部分的简洁明了,我认为每次sprint的摘要生成时间应不超过15分钟。

我已经总结了一个sprint总结文档示例,您可以试着使用它开始工作。

原文作者:Mike Cohn Summarizing the Results of a Sprint

留下评论

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据