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