0

在停止我们当前的 sprint 之后，我们需要将很多项目移动到下一个 sprint。这提出了一些问题，我们作为新的 scrum 用户没有找到答案。

我们知道我们需要创建新的 PBI，并将标记为 To Do 的任务移动到新创建的 PBI。（In Progress 任务会发生什么，应该如何移动它们？只是移动它们，或者关闭它们并为新的 sprint 创建一个新的？）

提出的讨论之一是我们应该如何命名我们的 PBI，因为管理层希望它对我们的客户来说足够清楚，他们可以阅读我们的产品待办事项和 Sprint 待办事项。

从开发人员的角度来看，PBI 诸如“研究功能 A”、“实施功能 A”、“波兰功能 A”，而我​​们的管理层认为 PBI 应该命名为“功能 A（第 1 部分）”、“功能 A（第 2 部分）”、“功能 A（第 3 部分 - 结束）”，因为他们和我们的客户都不了解我们的 PBI，他们想知道何时可以开始测试功能 A。我们的管理层基本上只想打印出 Sprint Backlog 查询和将其传递给我们的客户，以显示已完成的工作。

第二个不太重要的问题是：我们应该如何正确使用区域路径？如果我们有一个特征 A，那么创建一个特征 A 区域路径并将其用作所有 PBI 和与之相关的任务的通用标识符对我们来说是有意义的。但是我们应该如何处理与多个特征（以及区域路径）相关的工作项？我们担心我们最终会得到很多区域路径，并且列表会变得混乱。我们无法删除区域路径，因为可能会为此提交错误，或者我们需要在稍后阶段将其拾取。另外，如果一个特性已经在应用程序的多个版本中实现了怎么办？

4

1 回答 1

1

我们知道我们需要创建新的 PBI，并将标记为 To Do 的任务移动到新创建的 PBI。（In Progress 任务会发生什么，应该如何移动它们？只是移动它们，或者关闭它们并为新的 sprint 创建一个新的？）

您无需为每个 sprint 创建新的 PBI！PBI 一直在进行，直到其所有子任务完成。它的迭代可能会前进到下一个 sprint（例如“Release 1\Sprint 1 > Release 1\Sprint 2”或只是停留在上层（“Release 1”）。任务不会转移到另一个 PBI，但可以进入下一个 sprint。

这将解决命名问题，因为 PBI 不会获得“part X”后缀。PBI 的一个可能名称是“功能 A - 基础设施”或“功能 A - UI”。所以它的子任务可能被命名为“功能A-基础设施-设计”、“功能A-基础设施-实现”和“功能A-UI-设计”等等。

第二个不太重要的问题是：我们应该如何正确使用区域路径？

如果Iteration是按时间顺序排列的时间点，那么Area就是用来表示产品的一个逻辑模块。例如：

|-Server
| |--Database
| |--Web Services
|
|-Client
| |--UI
| |--Navigation
|
|-Configuration
|
|-Documentation
|
|-Installation
| |---Client
| |---Plugins
|

不要过度使用区域定义。列表应该干净且易于理解。

如果在应用程序的多个版本中实现了一项功能怎么办？

Create another PBI and assign it with the same Area path but different Iteration path.

于 2012-06-07T22:57:42.580 回答