9

我正在一个团队工作，该团队正在探索采用敏捷开发实践的可能性。

我们遇到的一个问题是决定何时完成迭代（冲刺）。

假设我们已经定义了我们的功能积压，并为它们生成了故事点估计，并且我们已经决定第一个 30 天的冲刺将包括功能 A、B、D 和 F。如果你遇到了你应该怎么做'再次到达 sprint 的终点，您已经完成了 A、D 和 F - 但 B 只完成了 80%。你应该：

  1. 按时完成 sprint，但排除功能 B（将剩余工作推迟到未来的 sprint）

  2. 将 sprint 延长到完成功能 B 所需的时间，但不要开始下一个 sprint。

  3. 将 sprint 延长至完成功能 B 并开始进行下一个 sprint 所需的时间。

  4. 使整个 sprint 失败，并将所有工作捆绑为未来版本的一部分。

我在选项 1 中看到的问题是团队没有兑现承诺。在某些情况下，您可能无法在不使整个版本无用（或至少显着降低价值）的情况下排除功能 B。如果没有特征 B，可能很难指导下一个 sprint 的方向。

选项 2 的问题是团队中的一些成员可能会在很长一段时间内处于空闲状态 - 这会影响整体生产力。您可能能够添加更多的单元测试，或润色特性，但它不会增加成比例的价值。在政治上也很难向管理层解释为什么你的大多数团队都处于闲置状态。

选项 3 似乎与敏捷精神背道而驰——您不允许前一个 sprint 的结果指导下一次开发迭代，从而使下一个 sprint 处于危险之中。

选项 4 似乎很严重，并且与选项 1 和 3 有大部分相同的问题。首先，你完全错过了一个承诺。其次，将更多功能捆绑到后续版本中会使与客户进行测试和验证变得更加困难——并且它再次排除了根据之前的反馈来指导未来迭代的能力。

4

6 回答 6

16

当然是选项1。下一次迭代的速度会变慢，因为它是基于昨天的天气，所以下一次迭代你有更好的机会完成。

在 scrum 中，你是时间拳击。而且您只提供有效的功能。

在sprint 计划中，您已经估计了您可以交付的内容。客户必须在估算中接受一定程度的不确定性，或者准备好团队中有太多资源。

如果您再次错过下一次迭代，请切换到更短的迭代长度，并确保单个特征的大小更小。

于 2010-01-18T18:24:01.603 回答
2

您通常会执行选项 1 - 完成 sprint。使用已完成的工作，让未完成的工作反映在项目速度中——因此未来的规划会考虑到您遇到的困难。

是的，选项 1 意味着我们没有完成我们承诺的事情——但如果发生了这种情况，那么最好承认它并学会下次更好地应对而不是隐藏它。坏事发生在每个人身上——关键是我们如何从现在的状态中改进。

您可以执行选项 2 - 通过延长 sprint 继续完成出色的工作。仅当工作对客户具有超高优先级并且他们明确选择这样做时才这样做。延长冲刺的长度使它们更难相互比较——因为它们的长度不同。

绝对永远不要让一个 sprint 合并到下一个 sprint 中——要么你正在扩展旧的 sprint，要么你正在开始一个全新的 sprint。如果您让两个 sprint 相互合并，那么您就不再真正进行 sprint 并且计划失败了……

于 2010-01-22T13:26:28.760 回答
2

我可以回答“这取决于”吗？另外，我想输入一个“定义完成”。

我们遇到过几次这种情况，并根据情况采取不同的处理方式。

据我记得，在两种情况下，我们让 sprint 失败了。这实际上更像是一种被演示拒绝的失败。团队认为这些功能本身是完整的，但在演示期间出现了太多未解决的问题、松散的结尾和小细节。将所有内容都打包好需要几天时间，所以我们让 sprint 失败，并将所有未解决的项目带入下一个 sprint。我们仍然对新的用户故事进行了回顾和冲刺计划，但是没有集成代码行，冲刺被正式标记为失败。

在另一种情况下，我们只有最后一分钟出现的几个错误，以及用户故事中的一些内容。我们将总工作估计为三天，并刚刚延长了冲刺。这足以让我们修复错误、进行一些更改并在大约三天后进行第二次 sprint 演示。

因此，当我们需要它时，它要么是选项 4，要么是选项 2。

这里有几件事需要考虑。首先，（我在这里说的是 Scrum 术语，因为我已经习惯了，所以可以随意用最合适的词代替）让 ScrumMaster、产品负责人和团队聚在一起，公开讨论选项。我认为没有一种方法可以走。你可以坚持纯粹的方法论，但在现实生活中，这并不总是最好的方法。有时稍微改变规则会有很大帮助，让每个人的生活更轻松。

如果你们一起工作得很好，你应该找到一个适合所有相关人员的选项。（如果你做不到，你可能还是有潜在的问题。）不要在没有至少讨论或至少解释原因的情况下将某些东西丢给团队。

选项 3 听起来对我来说是最混乱的，所以我会排除它。

这里的很多人都认为选项 2 违反了基本的敏捷（或 Scrum）规则，但我不同意。Scrum 明确表示，如果需要，您可以扩展 sprint，就像您可以减少故事或添加资源一样。除非绝对必要，否则您不应该这样做，但据我所知，这并不严格违反这本书。我们在基地做的时候，对每个人来说都是最好的解决方案，因为我们仍然完成了冲刺，仅仅三天后，每个人都对结果非常满意。如果我们谈论一周或更长时间，那么选项 2 就不合适了。

我不太喜欢选项 1。将完成一半的东西拿出一个可行的实现可能真的很混乱。您与已完成的代码失去联系，坦率地说，集成可能会很痛苦。根据您的工作方式，它可能会有所不同，但根据我的经验，从代码行中取出代码并不是您想要做的事情。

至于选项 4，它非常苛刻，但话又说回来，如果沟通得当，应该没问题。团队通常知道什么时候出现问题并且无法交付，因此您不会向他们透露任何消息。

所以，有几点需要考虑。

  • 完成它需要多少时间？如果只有一两天，延长冲刺时间可能是最好的选择。
  • 删除已经存在的代码需要付出多少努力？如果它很混乱并且需要时间，请解决选项 2 或 4。如果它很容易，也许选项 1 是要走的路。
  • 团队是怎么想的？产品负责人是怎么想的？别人怎么看？春季失败可能会影响团队士气，但可能不会。
于 2010-01-26T22:01:19.653 回答
1

对于敏捷项目，有一个“完成的定义”很重要。这是一个小清单，列出了为了将某件事归类为完整而需要完成的事情。完成不同级别的工作并不罕见：

  • 用户故事 - 这可能包括所有与美国相关的任务必须完成，所有代码都已签入并通过单元测试成功构建，验收测试已完成。

  • 冲刺——这可能包括冲刺的所有故事都“完成”（见上文，已举行回顾，产品负责人已看到功能演示等）。

  • 发布冲刺——前一系列冲刺的开发已经成功集成和回归测试，功能已经发布到现场环境中。

就 4 个选项而言，它不太明确。关于在 sprint 失败、扩展 sprint 和排除某些功能或其他方面应该做什么和不应该做什么，已经说了很多，并且已经写了很多。我发现敏捷项目需要很多实用主义，尤其是在最初的几个 sprint 中。

重要的是不要挂断它。只需从中学习，适应并继续前进。

于 2010-01-21T22:41:37.373 回答
0

我会对选项 1 进行修改。如果功能 B 可以分解为已完成和未完成的内容，这应该会导致修改一组任务以在下一个 sprint 中完成它。完成的东西是交付的，虽然交付并不完美，但想法应该是尽力而为，然后根据优先级处理下一步。

在我看来，延长冲刺是灾难的秘诀。完成该功能是否也意味着解决其上的所有错误？见过零错误的软件吗？

冲刺失败会给事情带来太多的完美主义。99%完成的事情是不是一文不值？我不这么认为，但有些人的标准非常高，而且要求很高。

编辑：有时最初给出的功能具有模糊的要求，这些要求在冲刺过程中得到澄清。例如，“作为用户，我想下订单”的功能请求可以作为规划冲刺的一部分或在冲刺期间进一步细分。在任何一种情况下，如果完成了一些涉及某个功能的故事，则可以而且应该在演示中展示这些故事。关键是要能够说，“这就是我们所处的位置。完成这件事有多少优先级？” 因为之前可能很紧急的事情在 sprint 结束时可能不会那么紧急。

于 2010-01-18T18:35:54.537 回答
0

首先，规则：迭代是固定长度的时间盒，它们在时间盒的末端完成。所以这消除了选项 2 和选项 3。关于选项 4，迭代异常终止可能在非常特殊的情况下发生（确定目标无法实现，外部事件使目标无效，...），但这必须是异常事件。在中止之前，通常还有其他选择：1. 做其他事情/创新 2. 获得帮助/外包 3. 缩小范围。这给您留下了选项 1，这是显而易见的选择。

我在选项 1 中看到的问题是团队没有兑现承诺。在某些情况下，您可能无法在不使整个版本无用（或至少显着降低价值）的情况下排除功能 B。如果没有特征 B，可能很难指导下一个 sprint 的方向。

如果这是真的，那么要么 B 比 A、D 和 F 更重要，而且你没有先处理最重要的项目，这是错误的，它不应该发生，或者...... A、D 和 F 实际上非常很有价值，在这种情况下，您的假设实际上是不正确的，因此推迟 B 不是一个大问题。所以，只要你意识到它不会完成就立即做，看看你是否可以用更小的物品替换它。

于 2010-01-22T14:18:57.320 回答