使用 Excel 进行 Scrum 产品和 Sprint Backlogs

• 下载文档和帮助文件 - 85.7 KB

引言

本文介绍了两个 Excel 文档，它们可以分别用作 Scrum 框架 的产品待办事项和 Sprint 待办事项。

尽管市面上有一些软件在许多方面做得更好，但以下情况可以考虑使用这些文档：

• 希望快速开始使用这些制品，而无需购买硬件或软件的人。唯一需要的软件是 Excel，这在大多数公司都很普遍。
• 由于是免费的，它也避免了复杂的采购流程阻碍进展的问题。
• 对于只使用 Windows 的组织来说，这可能也是为数不多的选择之一，因为我还没有看到一款好的、免费的、能在Windows\SQL Server上运行的 Scrum 工具。

由于每个待办事项都在一个文档中，它还有一些其他优点：

• 整个文档可以被通过电子邮件发送。这对于向不直接参与的人发送状态报告非常有用。
• 如果存储在文档管理系统或源代码管理系统中，您可以获取项目的整个版本。如果您想查看某个时间点待办事项中的项目，这会很有用。
• 您可以轻松添加或删除列、行或其他信息。我经常会在待办事项中添加仅与特定项目相关的列。例如：是否需要与外部开发团队讨论需求，是否需要澄清需求等。

一些缺点

• 它不直观。使用这些文档有一个学习曲线，但一旦您获得了一些经验，它们就很容易维护。这是软件具有巨大优势的领域，因为软件可以指导用户输入数据。我试图通过编写详细的帮助指南来弥补这一点。
• 因为它是一个单一的文档，所以不能有多个人同时在其上工作。
• 不适合存储制品。有些软件允许您将文档链接和存储到任务中。在 Excel 的情况下，您可以嵌入指向文件系统的链接或将制品直接嵌入到文档中，但这并不理想。
• 您无法可靠地汇总来自多个待办事项的数据。虽然仍然可以引用 Excel 文档之间的数据，但并不总是可靠的。这使得“Scrums of Scrums”难以实现。

我想指出，本文的重点不是向读者传授敏捷方法论或 Scrum。它只涵盖了我创建的制品应如何使用。有许多优秀的书籍和网站可供研究。

背景

在 T4G 工作期间，马丁·福勒（Martin Fowler）的一本电子书让我对敏捷方法论产生了兴趣。我读得越多，就越钦佩它们。最终，Scrum 成为了我的首选框架，因为尽管我们的开发流程是顶尖的，但我总觉得有一种比传统的预测性方法更好的项目管理方式。

我刚刚完成了一个大型项目，其中甘特图的更改非常频繁，几乎需要全职工作来重新确定优先级、修订、重新估算和重新排序任务。在下一个项目中，人们对采用敏捷方法论持犹豫态度，因此我需要一种能够快速、低成本地开始使用 Scrum 并证明其是更好的项目管理方法。我写了产品待办事项和 Sprint 待办事项的第一个版本，当时以为只需要几个小时。虽然确实如此，但下载的版本在我使用的每个项目上都得到了改进，以至于我认为所有的缺陷都已解决。实际上，我遇到了一些我未曾预料到的问题，尤其是在图表方面。

使用代码

这两个文档有一些共同点：

• 它们都使用 Excel 2003 编写，并在 Excel 2007 上进行了测试。
• 没有宏。许多组织会限制宏，我也不想担心我的文档传播 VBA 病毒。
• 它们都有一个包含团队所有任务的单个工作表。
• 在不同的工作表中有一个或多个图表。
• 有一个“查找”工作表，其中包含一些单元格将使用的数据，以提供选择列表。这是使用 Excel 中的“定义名称”和“数据验证”功能实现的。

我强烈建议您将这些文档存储在集中存储库中，例如文档管理系统（如 LiveLink、SharePoint、Documentum 等）或源代码管理系统（如 CVS、Team System、SourceSafe、SourceGear Vault 等）。这样，您可以有多个人（例如产品负责人、Scrum 主持人等）编辑文档，您将获得版本跟踪，并且可以看到是谁进行了更改。

有一套说明（称为Help.doc），描述了您将对产品待办事项和 Sprint 待办事项执行的常见任务。请参阅该文档了解使用这些制品的详细信息。

报告

有一套基于待办事项中数据的报告：

• 产品待办事项

  • 产品燃尽图：显示团队在每个迭代中完成任务的速度。它显示了已完成的工作量（燃尽）、已完成的新范围、未完成的新范围以及剩余的工作量。
  • 按迭代的工作量：一个饼图，显示分配给每个迭代的工作量。这可以用来尝试平衡跨迭代的需求。
  • 按优先级的工作量：一个饼图，显示每个优先级级别的工作量。这可以用来确保工作量在不同优先级之间平衡。
  • 按风险的工作量：一个饼图，显示每个风险的工作量。这可以直观地了解项目的风险。

• Sprint 待办事项

  • Sprint 燃尽图：对于当前正在进行的 Sprint，它提供了团队每天完成任务的速度。它按天跟踪剩余的当前工作。它还根据趋势线预测 Sprint 的完成日期。

关注点

速度（velocity）的概念引起了不少问题。电子表格 really only good at tracking the current state. Building a full history into it would take up a lot of space. So I had to come up with ways to track initial sets of effort, re-estimations, etc. in a way that still tracked the velocity, without requiring a day to day tracking of changes. I feel I found the right balance, but sometimes the lack of an accurate history has caused some confusion.

结论

尽可能，我将始终使用软件来跟踪敏捷项目。虽然当我们刚开始探索敏捷方法论时，这些文档是一种无需硬件或软件即可快速上手的方法。学习这些文档需要一些时间，但一旦您习惯了它们，它们就很容易维护，有时甚至比登录系统并编辑任务更快。

历史

• 2007 年 8 月 3 日：第一次修订
• 2007 年 8 月 8 日：修复了待办事项中的一些缺陷。Sprint 待办事项中的类别被隐藏，未分配的任务未正确添加到产品待办事项的范围内。
• 2007 年 9 月 7 日：更改了燃尽图的计算方式，以更好地考虑范围的剧烈变化。修复了工作日问题。移除了产品待办事项的最小工作量估算。