手把手教你写《迭代总结文档》

敏捷的结束应该是一个相对不太重要的场合。毕竟,这是一个月做一次的事情,并且通常比一个月一次要频繁得多。重要的是我们不会使一个团队承担除必要之外的过程仪式。因此,通常,团队只需要一个非常简单的迭代评审会议。

迭代总结文档

有时候,尽管身为一个Scrum Master,我还是喜欢写《迭代总结文档》。这个简短的文档中包含在迭代中完成的工作的简单的细节,迭代的时间跨度,团队成员有哪些人,以及在迭代中做所出的所有关键决策,也许还包含一些重要的度量指标。

受众

《迭代总结文档》的目标受众有两类。第一类是任何对此感兴趣的局外人。这一类可能包括研发部副总裁、执行总裁、项目干系人、部门管理人员、其它团队等等。

第二类受众是未来的团队成员本身。我已经遇到过很多这样的情况——就是团队成员想回顾从前。而一份《迭代总结文档》能够提供这样的内容。让我来举一个例子。

一个团队因为他们写的自动化测试太少而感到沮丧。在上一个迭代中,他们仅仅添加了大约200个自动化测试,对于他们的系统所需的量来说,这个值太低了。

由于他们的Scrum Master 一直有写《迭代总结文档》,我检索了之前六个月的总结文档。

我和团队成员分享了一个事实——他们曾经很难在一个迭代中写出哪怕是一两个自动化测试。【当时,为了支持自动化测试,他们重构代码,并且正在学习概念和工具。】

我从团队的迭代总结中分享这些信息给团队成员,帮助他们认识到他们已经走了多远。是的,他们还有很长的路要走,但是他们已经开始“移山”,而且形势向他们这边倾斜。

如果没有《迭代总结文档》提供确切的事实,我将不得不依赖记忆或通过挖掘源代码库得来的片段将事情拼凑在一起。

内容

尽管《迭代总结文档》的具体内容完全取决于你,但是我发现记录这样一些东西会非常有帮助,它们包括:

1. 背景

简单地列出迭代的开始日期和结束日期,以及在迭代中的工作天数。我也会列出哪些人在团队中,每个人预期的可用时间天数以及实际可用天数的大概数字。 团队成员的工作天数与计划的天数可能不同,例如,团队成员生病或者被拉入另一个项目的中期迭代中。

2. 度量指标

这里所记录的所有度量指标对于Scrum Master、项目干系人或团队都非常重要。保持简单。我倾向于内容中包含一个图或表格,标注之前大约十个迭代的速率(即便对于你的团队来说,迭代速率看起来保持水平)。如果你正在使用燃尽图,也请放入迭代总结文档。 你还可以考虑加入一些东西,诸如发现或修复的缺陷数目、添加的自动化测试数目、代码覆盖率、部署的数量等等。 如果你正在为一个客户开发软件,并且需要成本报告,请将这部分时间和花费包含在内。 但是,请保持它的简单。

内容及评估

在这一部分,涵盖了团队计划中每一个产品的待办事项列表。指明这些事项是否完成。如果团队估算了产品待办事项(例如,使用故事点),将故事的大小记入在内。 也要记录下,在迭代评审会议中,有关决定的额外的解释说明。

最后,考虑在《迭代总结文档》中包含迭代回顾会议最终所做的行动决议。这完全是可选的,而且要保证团队成员同意这么做。他们可能会,也可能不会,这取决于《迭代总结文档》的受众。

保证投入很少的精力

一旦你创建了一个初步的《迭代总结文档》,你会发现为每一个迭代创建一个新的迭代总结文档是如此的简单。我的原则是,每个迭代写迭代总结文档的时间应该不超过15分钟。如果你保持度量指标部分的简单,这是相当可行的。
我已经添加了一个《迭代总结文档》范例,你可以参考开始写你的《迭代总结文档》:

联系我们

无论是咨询,培训,商务合作还是想加入我们,都可以用以下方式联系我们.