在敏捷方法论中，后期有什么意义吗？

这来自对另一个问题（这个问题）的一些答案和评论。

我主要从事瀑布项目，虽然我从事过一些采用敏捷行为并且对敏捷有一定了解的特设项目，但我会说我从未从事过“适当的”敏捷项目。 。

我的问题是“后期”的概念在敏捷中是否有任何意义，如果是的话，那又是什么？

我的理由是，有了敏捷，您就没有前期计划，一开始就没有详细的要求。您可能有一个高水平的目标，并附带了一个概念上的日期，但两者都可能发生变化（可能会发生巨大变化），而且不确定。

因此，如果您直到交付和用户接受之前都不知道要交付什么，并且如果您没有下一个冲刺之外的时间表，那么您怎么会迟到呢？真的有意义吗？

（显然，我知道冲刺可能会超车，但我所谈论的是超出此范围。）

只是要清楚一点，我（个人）对以下假设的假设感到满意：基于我已经看过并参与其中的事实，准时瀑布项目（甚至是相对较大的项目）是可能的，即使这些项目也不容易，也不常见但是它们是可能的。

这不是敲门敏捷，而是关于我的理解。我一直认为敏捷的好处与截止日期或预算无关（或者只是间接地），与范围无关-敏捷在交付之前更接近真正重要的内容，而不是项目团队认为重要的东西。看过任何东西。

我不同意敏捷项目没有前期计划。

我的经验是，业务分析师花费了大量时间与客户和开发人员进行设计会议，以提出可实现的需求的详细列表，这些需求以用户案例的形式呈现。然后将这些细分为任务，并由经验丰富的开发人员进行适当的估算。

一旦在冲刺/迭代开始时确定了最重要的任务，便可以开始编码。该选择过程确定了整个项目中迭代的含义（“我们正在构建登录过程”）。团队的各个成员继续着各种必要的任务，以使用户故事得以实现。

在迭代结束时，该迭代的所有用户故事应已完成，否则您将迟到。同样，开发应该能够在每次迭代结束时停止并发布产品。就所有用户故事而言，它可能并不完整，但是在迭代中请求的那些用户故事是完整的，并且产品可以在这些限制范围内工作。

敏捷方法中的“迟到”与瀑布方法中的含义相同：估计错误，在指定的时间内范围太大，出现了意外的困难，客户没有足够的响应能力，程序员变得懒惰，机器崩溃了，你的狗吃了我的字节码，等等。

您可以从中学习并为下一次迭代进行调整

区别在于，这种情况每2-4周就会发生一次，因此您可以吸取教训并迅速调整流程

是的，但是只需要1个月的时间，您就不会达到9个月的神话般的最终项目到期日期，而不是9个月。

您的推理基于这样的假设，即大型项目的前期计划和详细要求是可能的。不确定有很多证据支持这一点。也许所有的恐怖故事都只是轶事？任何开发人员都希望使用客户完全同意并理解的完整且永不更改的规范。

每当您做出某种承诺时，都会冒迟到的风险。这同样适用于敏捷。

但是我们知道您无法预测未来，我们知道客户将不断改变主意，我们同意这是一件好事。如果我们接受这一点，我们还必须接受所有承诺几乎都是错误的，这反过来又使关于迟到的问题易于回答：我们总是错的（早到晚）。不管多么精细，这都是猜测的问题。抛硬币。

这是我们开发人员必须接受的事情，从这个角度出发，尝试寻找另一种工作方式，这种方式可以将延迟问题变得不那么重要。观点的改变。我认为这样做的方法是着重于尽快交付可运行的软件，并可以选择在客户满意时退出。

这就是敏捷的全部内容。解决这个迟来的事实的明智方法是聪明的方法，我们只需要尽我们所能应对。

例如，当您未能兑现您在当前迭代开始时所做的承诺时，您就来晚了。这是预料之中的，您应该从中学到并且调整您的过程，这样就不太可能在下一次迭代中失败。处理此问题的最佳方法是使迭代尽可能小。

对于多迭代计划（也称为发布计划），您可以使用从完成的迭代中计算出的速度，并外推数据以预测未来的发布日期。我推荐詹姆斯·肖尔斯（James Shores）的文章或我自己的文章（简称），以获取更多有关此的详细信息。请注意，这从来都不是一项坚定的承诺，更多的是“我们80％可以确定我们将在该日期之前完成下一个功能”。这可能会导致您迟到，但是承诺只是一种可能性，而不是事实。

现在，将这与敏捷的基本承诺相提并论，您应该始终准备发布有效的软件，无论功能是否完整。当客户认为系统足够好时，这使客户可以自由地停止开发，这可能比预期的要早得多。它还鼓励根据最新迭代的实际反馈，将项目推向新的方向。

以上几点对所有客户来说都足以完全控制开发，我希望这能回答有关敏捷方法的最新性的问题。

敏捷SCRUM中有两种“晚期”类型>

1. 遗留-冲刺结束时故事没有“完成”，开发人员“致力于”完成PBI，因此，如果未完成，则可以认为是随身携带。

2. 路线图-假设您的组织有一个路线图，并假设它有日期，那么如果错过了这些日期的主要交付物，则可以认为是“晚期”。