使用 Scrum，用户故事的主体和这些词干提取任务等会迭代到成品——这很好。
但是，假设我有 100 个需要实现的功能，在现实世界中，在完成许多正常的辅助工作之前，我不能让任何开发人员参与这些功能 - 例如，做一个 UI 设计（当然你需要有对此功能的总体概念？），或构建不一定表现为功能的底层内容。
那么，这发生在哪里？
Neil Middleton
问问题
477 次
5 回答
9
我的理解是，在 scrum 中，您只构建实现每个用户故事所需的内容。因此，只有在需要为您正在处理的用户故事实现功能时，您才构建不是功能的底层内容。
于 2009-03-16T17:29:01.143 回答
9
在我看来，非功能性任务仍然会出现在产品待办列表中——当我使用 Scrum 时，我们当然会这样做。我们必须向产品负责人解释为什么它们应该被视为重要，这样我们才能有时间去做。如果产品负责人不认为他们非常重要，他们就不会完成 - 负责人必须接受结果。在通过驳回您对负载测试之类的请求而被咬了几次之后，它们很可能会回来:)
另一方面，您可能会发现有一些您最初认为很重要的非功能性需求，但可以在没有影响的情况下憔悴。有时，只是有时，开发人员的直觉是错误的 :)
对于真正是门控因素的任务，我认为你只需要对产品负责人诚实，并坚持你必须去做。如果你不能与产品负责人相处到继续项目所需的程度，那么问题比没有 UI 设计要大:)
于 2009-03-16T17:32:36.673 回答
4
我会将辅助任务构建到需要它的第一个功能中。
区分产品积压和冲刺积压之间的区别很重要。产品待办事项包含代表“什么/为什么”的用户故事，而不是“如何”。当一个故事被选为一个 sprint 时，故事会被分解成构建它所需的任务。例如：“UI 设计”将是“选择要购买的物品”故事的任务。在 sprint 计划级别，任务具有依赖关系也没有什么害处；事实上，大多数时候会有一些任务让其他产品积压项目的工作变得更轻松。
希望有帮助！
于 2009-03-27T03:41:17.533 回答
3
基本上，它发生在每个功能中，说起来容易做起来难，但这可能是敏捷增量软件开发的重点。
例如，与其构建大量“不一定将自身表现为功能的基础内容”，不如怀疑自己不需要它，并且只为所讨论的功能构建所需的量。
于 2009-03-16T17:30:18.800 回答
0
在我看来，最好的办法是将尽可能多的东西作为“故事”包括在内，这样每个人都可以很好地了解时间的应用。
但是，总会有一些计划外的任务必须完成（例如，如果机器坏了，请重新安装）。对于该任务，一个选择是在每次迭代中留出一定百分比的空闲时间，如果每次迭代的速度为 300 个故事点，例如，一开始只有 250 个故事点，以便为计划外的事情留出空间，然后，在以下迭代中，您可以根据过去的历史调整这些值。
于 2009-03-16T17:29:40.517 回答