在敏捷方法中，晚一点有什么意义吗？

Question

这来自于对另一个问题(这一个)的一些回答和评论。

我主要从事瀑布项目，虽然我从事过一些具有敏捷行为的临时项目，也读过一些关于敏捷的文章，但我要说的是，我从未从事过“适当的”敏捷项目。

我的问题是，“迟到”这个概念在敏捷中有什么意义吗?如果是的话，那又如何呢？

我的推理是，对于敏捷，您没有预先的计划，并且在一开始就没有详细的需求。你可能有一个高层次的目标和一个名义上的日期，但两者都可能发生变化(可能是大规模的)，两者都不确定。

所以，如果你不知道你要交付什么，直到你交付它并且用户接受它，如果你没有超过下一次冲刺的时间表，你怎么可能以任何有意义的方式迟到呢？

(很明显，我理解冲刺可能会超支，但我要说的是超越这一点。)

显然，我(个人)对这样一个假设感到满意:根据我所见过并参与其中的事实，按时进行瀑布项目(甚至是较大的瀑布项目)是可能的--它们不容易，也不常见，但它们是可能的。

这不是敲门敏捷的问题，而是我理解它的问题。我一直认为敏捷的好处与最后期限或预算无关(或者只是间接的)，它与范围有关--敏捷交付更接近真正重要的东西，而不是项目团队在看到任何东西之前认为重要的东西。

Answer 1

我不同意敏捷项目没有预先计划.

我的经验是，业务分析人员在与客户和开发人员的设计会议上花费了相当多的时间，提出了一份详细的可实现需求列表，这些需求都是以用户案例的形式呈现的。然后将这些任务分解为有经验的开发人员附加适当估计值的任务。

一旦在sprint/迭代开始时确定了最重要的任务，那么编码就可以开始了。这个选择过程决定了整个项目中迭代的意义(“我们正在构建登录过程”)。团队的各个成员都完成了使用户故事发生所需的各种任务。

在迭代结束时，该迭代的所有用户故事都应该完成，否则您就迟到了。同样，开发应该能够在每次迭代和产品发布结束时停止。可能并不是所有的用户故事都是完整的，但是迭代中请求的那些用户故事是完整的，并且产品可以达到这些限制。

Answer 2

敏捷方法中的“迟来”意味着与瀑布方法中的含义相同:估计错误，范围太大，无法分配时间，出现了意想不到的困难，客户反应不够，程序员懒惰，机器崩溃，你的狗吃了我的字节码等等。

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

不同的是，这种情况可以每2-4周发生一次，因此学习到的课程和过程得到了迅速的调整。

Answer 3

是的，但你只需要一个月就能知道你不会达到你的9个月-神话般的-最终-项目-到期日，而不是9个月。

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