我正在研究一个正在探索采用敏捷开发实践的可能性的团队。
我们遇到的一个问题是决定何时完成迭代（冲刺）。
假设我们已经定义了我们的功能积压，并为他们制作了故事点估计，我们已经确定第一个30天的冲刺将包括功能A，B，D和F.如果在你到达冲刺结束时你已经完成了A，D和F - 但是B只完成了80％。你应该：
按时完成冲刺，但排除功能B（将剩余的工作推迟到未来的冲刺）
将sprint扩展到完成功能B所需的时间，但不启动下一个sprint。
将sprint扩展到完成功能B所需的时间并开始处理下一个sprint。
在整个sprint中失败，并将所有工作捆绑在一起作为未来版本的一部分。
我在选项1中看到的问题是团队没有提供它所承诺的内容。在某些情况下，您可能无法在不使整个版本无用（或至少实质上不那么有价值）的情况下排除功能B.如果没有特征B，可能很难指导下一个冲刺的方向。
选项2的问题在于团队中的某些成员可能在很长一段时间内闲置 - 这会影响整体生产力。您可以添加更多单元测试或抛光功能，但不会增加比例值。在政治上也难以向管理层解释为什么你的大部分团队都处于空闲状态。
选项3似乎违背了敏捷的精神 - 你不会让前一个sprint的结果引导下一次开发迭代，从而使下一个sprint面临风险。
选项4似乎很严重，并且在选项1和3中存在大部分相同的问题。首先，您完全错过了承诺。其次，将更多功能捆绑到后续版本中会使得更难以与客户进行测试和验证 - 并且它再次排除了根据之前版本的反馈来指导未来迭代的能力。
答案 0 :(得分：15)
选项1当然。下一次迭代的 velocity 将会更少，因为它基于昨天的天气，所以下一次迭代你有更好的机会完成。
在scrum中你是 time-boxing 。而且您只提供有效的功能。
在 sprint计划中，您已经估算了可以提供的内容。客户必须接受估算中的一定程度的不确定性，或准备在团队中拥有太多资源。
如果再次错过下一次迭代，请切换到较短的迭代长度，并确保单个要素的大小较小。
答案 1 :(得分：2)
您通常会选择1 - 完成冲刺。使用已完成的工作，让未完成的工作反映在项目速度中 - 因此未来的计划会考虑到您遇到的困难。
是的，选项1意味着我们没有完成我们所承诺的 - 但如果发生了什么事情那么最好承认它并且下次学会更好地应对而不是隐藏它。不好的东西每个人都会遇到 - 关键是我们如何从现在的位置进步。
您可以选择2 - 通过扩展冲刺继续完成优秀的工作。只有当工作对客户具有超高优先级并且他们明确选择这样做时才这样做。延长冲刺的长度使得它们之间难以比较 - 因为它们的长度不同。
绝对永远不要让一个sprint合并到下一个 - 要么扩展旧的sprint，要么开始一个全新的sprint。如果你让两个冲刺相互融合，那么你就不再真正做冲刺了，并计划分解......
答案 2 :(得分：2)
我可以回答“这取决于”吗？另外，我想投入一个“定义完整”。
我们曾经多次遇到这种情况，并根据具体情况采取不同的处理方式。
据我记得，在两个案例中，我们让sprint失败了。它实际上更像是一种被拒绝的演示 - 失败。团队认为这些功能本身已经完成，但是在演示过程中出现了太多未解决的问题，松散的目标和细节。将所有内容包起来需要花费几天的时间，因此我们让sprint失败并将所有打开的项目带入下一个sprint。我们仍然对新用户故事进行了回顾和冲刺规划，但没有整合代码行，并且sprint被正式标记为失败。
在另一个案例中，我们在最后一刻只出现了几个错误，还有一些来自用户故事的错误。我们估计总工作量达到三天，并且只是延长了冲刺期。这足以让我们修复错误，进行一些更改，并在三天后进行第二次sprint演示。
所以，当它被召唤时，它是选项4或选项2。
这里有几点需要考虑。首先，（我在这里谈论Scrum术语，因为我已经习惯了它，所以随意用最好的东西代替它）让ScrumMaster，产品负责人和团队一起公开讨论选项。我认为没有办法。你可以坚持纯粹的方法论，但在现实生活中并不总是最好的方法。有时弯曲规则有点帮助，让每个人的生活更轻松。
如果你们在一起工作得很好，你应该找到适合所有人的选项。 （如果你不能，你可能会遇到潜在的问题。）不要只是在团队中放弃一些东西而不至少讨论它或者至少解释原因。
选项3听起来对我来说是最混乱的，所以我要排除它。
很多人都认为选项2违反了基本的敏捷（或Scrum）规则，但我不同意。 Scrum明确表示，如果需要，您可以扩展sprint，就像减少故事或添加资源一样。在绝对必要之前你不应该这样做，但据我所知，并不严格违反这本书。在我们这样做的基础上，它是每个人的最佳解决方案，因为我们仍然完成了冲刺，仅仅三天之后，每个人都对结果非常满意。如果我们谈论一个星期或更长时间，那么选择2就不合适了。
我真的不喜欢选项1.在工作实现中使用半完成的东西可能非常混乱。你已经失去了与已完成的代码的接触，坦率地说，整合可能是一种痛苦。根据您的工作方式，它可能会有所不同，但根据我的经验，从代码行中取出代码并不是您想要做的事情。
至于选项4，它非常苛刻，但是再次，当正确地传达它应该没问题。团队通常知道什么时候搞砸了，无法交付，所以不像是在向他们发消息。
所以，有几件事需要考虑。
答案 3 :(得分：1)
对于敏捷项目，重要的是要有“完成定义”。这是一个小的检查清单，列出了为了完成某些事情而需要完成的事情。有不同程度的完成并不罕见：
用户故事 - 这可能包括与美国相关的所有任务必须完成，所有代码都已签入并通过单元测试成功构建，验收测试已完成。
Sprint - 这可能包括sprint的所有故事都已完成（见上文，回顾展，产品所有者已经看过功能演示等等。
发布sprint - 上一系列sprint的开发已成功集成并进行回归测试，该功能已发布到实时环境中。
就4个选项而言，它不太明确。我们已经说了很多，并且已经写过关于在冲刺失败，延长冲刺和排除某些功能或其他功能方面应该和不应该做什么。我发现敏捷项目需要很多实用主义，特别是在前几个冲刺中。
重要的是不要挂断它。只需从中学习，适应并继续前进。
答案 4 :(得分：0)
我会对选项1进行修改。如果功能B可以分解为已完成的内容和未完成的内容，则应该导致修改的任务集以完成下一个sprint的任务。完成的是什么，虽然交付不完美，但我们的想法应该是尽力而为，然后根据优先事项处理下一步。
扩展冲刺是我心中的灾难。完成功能是否意味着解决它上面的所有错误？曾经见过没有错误的软件吗？
失败的冲刺在事物中引入了太多的完美主义。 99％的事情是毫无价值的吗？我不这么认为，但也有一些人有很高的标准，而且要求很高。
编辑：有时，一个功能最初会给出模糊的要求，这些要求会在冲刺过程中得到澄清。例如，作为规划冲刺或冲刺期间的一部分，“作为用户，我想下订单”的功能请求可以进一步细分。在任何一种情况下，如果某些涉及特征的故事已经完成，那么可以并且应该在演示中呈现这些故事。关键是能够说，“这就是我们所处的位置。完成这项任务有多少优先权？”因为在冲刺结束时可能不会如此紧急。
答案 5 :(得分：0)
首先，规则：迭代是固定长度的时间框，它们在时间框的末尾完成。因此，这消除了选项2和选项3.关于选项4，迭代异常终止可能在非常特殊的情况下发生（确定无法实现目标，外部事件使目标无效，......）但这必须保持异常事件。在中止之前，通常还有其他选择：1。做其他事情/创新2.获取帮助/外包3.缩小范围。这将为您提供选项1，这是显而易见的选择。
我在选项1中看到的问题是团队没有提供它所承诺的内容。在某些情况下，您可能无法在不使整个版本无用（或至少实质上不那么有价值）的情况下排除功能B.如果没有特征B，可能很难指导下一个冲刺的方向。
如果这是真的，那么B比A，D和F更重要并且你没有首先处理最重要的项目是错误的，它不应该发生或...... A，D和F实际上非常有价值，在这种情况下，你的假设实际上并不正确，因此推迟B不是一个大问题。所以，只要你意识到它不会完成就看它，看看你是否可以用一个较小的项目替换它。