Scrum论坛

这项工作与同一产品有关吗?如果是这样，为什么与产品待办事项列表的其他工作相比，订购维护是困难的?

我正在尝试执行scrum，但有一个非常大的问题:

我想说的是，最大的问题是你正在尝试实现Scrum，而不是一个由个人组成的自我管理、自我组织的团队。我还建议，如果一个团队试图在没有组织其他成员支持的情况下实施Scrum，可能会出现问题。

开发新功能并进行维护的团队负责所有必要的支持。

这听起来像是一个自组织、自管理的团队需要解决的障碍。这听起来似乎还需要在组织层面上进行一些改变。Scrum并不能解决所有问题，但它确实让一些问题变得显而易见。

这意味着我们无法知道在开发新功能和支持现有客户的冲刺过程中会有多少时间。

我不同意这种说法。Sprint是一个时间框事件。这样你就能准确地知道有多少时间了。它是冲刺的长度。真正的说法是，没有简单的方法来预测Sprint中有多少时间可以集中在满足产品待办事项项上。这是需要慢慢学习的。即使这样，您也永远不会真正知道，因为每次对代码库进行更改，都为更多支持需求提供了机会。你所能做的就是在产品生命周期的过程中检查和调整。

我该怎么做呢?我是否应该有一个预先确定的时间，将用于这些支持请求，只计划在剩下的时间里开发?

问题不在于怎么做你让它起作用。问题是如何Scrum团队感觉他们可以作为一个自我管理、自我组织的团队来处理这种情况。产品负责人负责确保开发人员专注于交付价值的工作。开发人员负责确定他们如何工作以及他们在Sprint中做什么。Scrum团队作为一个整体负责向涉众提供一致的迭代价值。没有经理，没有主管，没有个人负责告诉人们如何工作。这是产品负责人、Scrum管理员和开发人员共同的行为和责任。

Scrum指南定义了一个比sprint更复杂的框架。在现实中，大多数人对Sprint的理解与如何Scrum指南定义了。如果您正在尝试推动Scrum实现，您可能希望确保您理解Scrum指南对框架的定义。你可以实现不是Scrum的敏捷实践，甚至可以使用其中的一些术语。但正如《指南》所述:

正如本文所概述的，Scrum框架是不可变的。虽然只实现Scrum的一部分是可能的，但结果并不是Scrum。Scrum仅以其整体形式存在，并作为其他技术、方法和实践的容器发挥良好的功能。