Project management 敏捷迭代何时被视为完成？

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

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

假设我们已经定义了我们的功能待办事项，并为它们生成了故事点估计，我们已经决定，第一个30天的冲刺将包括功能A、B、D和F。如果在冲刺结束时，您已经完成了A、D和F，但B只完成了80%，您应该怎么办。你应：

按时完成冲刺，但不包括功能B（将剩余工作推迟到未来的冲刺）

按完成功能B所需的时间延长sprint，但不要开始下一个sprint

在完成功能B并开始下一个sprint所需的时间内延长sprint

使整个sprint失败，并将所有工作打包为未来版本的一部分

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

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

选项3似乎与敏捷的精神背道而驰——你不允许上一个冲刺的结果指导下一个开发迭代，这将使下一个冲刺处于危险之中

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

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

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

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

---

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

我会选择选项1的变体。如果功能B可以被分解为已完成的和未完成的，那么这将导致修改一组任务，以便在下一个sprint中完成它。完成的东西已经交付，虽然交付并不完美，但我们的想法应该是尽最大努力，然后根据优先顺序进行下一步的工作

延长冲刺时间对我来说是一个灾难。完成该功能是否也意味着解决所有的bug？你见过没有bug的软件吗

冲刺失败会给事情带来太多完美主义。做了99%的事情是否毫无价值？我不这么认为，但有些人的标准很高，要求也很高

---

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

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

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

• Sprint-这可能包括“完成”Sprint的所有故事（见上文，已举行回顾，产品所有者已看到功能演示等）

• Release sprint—先前系列sprint的开发已成功集成并经过回归测试，功能已发布到实时环境中

就这4个选项而言，它并不那么明确。有很多人说了很多，也有很多人写了很多关于在冲刺失败、延长冲刺和排除某些特性或其他方面应该做什么和不应该做什么的文章。我发现敏捷项目需要很多实用主义，特别是在最初的几次冲刺中

---

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

你通常会做选项1-完成冲刺。利用完成的工作，让未完成的工作反映在项目速度中-因此未来规划会考虑到你经历的困难

是的，选项1意味着我们没有完成我们承诺的任务——但如果事情真的发生了，那么最好承认这一点，并学会下次更好地应对，而不是隐瞒它。坏事发生在每个人身上——关键是我们如何从哪里改进