在收集所有需求之前确定发布日期是不敏捷的吗？

Question

我刚刚开始阅读克雷格·拉尔曼( Craig )的“应用UML和模式”一书。我发现它非常有趣，因为它挑战了我在工作中所听到的许多内容。我读到，需求不是一次完全收集在敏捷中，需要很多迭代才能完成需求收集。如果是这样的话，是不是要设定一个固定的截止日期，这就是我在工作中被迫做的事情，非常不敏捷，考虑到明天可能会有一些新的突破性需求(或伪装成需求的变更请求)？

Answer 1

如果您准备移动“铁三角”的另外两个边，那么拥有一个固定的发布日期是绝对没有“敏捷”问题的:对于该版本所需内容的需求，或者您所拥有的资源。您无法修复这三个方面--而且在实践中，三角形的“资源”边通常不是非常灵活，就是修改效率不高。

如果明天有一个重大的新需求，那么只要业务准备接受，这个需求可能不会使发布日期提前--也就是说，它会滑到下一个版本。

Answer 2

我认为许多敏捷阵营的问题在于最后期限这个词。最后期限的风险在于你认为你知道该做什么。正如你所指出的，你不可能有一个未知的最后期限。

菲利普在回答中所描述的，与其说是最后期限，不如说是一种约束。我们可以说，我们在3月份之前都有资金，因此我们必须在这段时间内生产出最好的产品。

举个例子，假设我让你去看杂货店的故事，买下这周所有的杂货，然后，在你去看任何价格之前，我想让你告诉我你到底要花多少钱。此外，如果你错了，你将受到惩罚。你会按照人们对项目最后期限所做的去做--你会在你认为的范围的高端选择一个数字，因为它是你被惩罚的几率最低的。现在，让我们说，我告诉你，这是不可接受的，你必须买同样的东西，你的计划，但你必须以50美元便宜，否则。现在你能做什么？你可以拒绝，你可以把争论推迟到购物之后，或者你可以想办法欺骗情况。这是在许多组织中发生的事情，在未知数上设定了最后期限。

现在，看到这种情况是多么的不健康，敏捷只是说：“如果你有一个预算，我可以保证，在这个约束下，我会在本周给你提供最好的食物。”这是一次健康得多的谈话。

Answer 3

敏捷是一种技术，而不是一种结果。与割草相比，一次迭代就像你修剪过的一排草。如果有人说“15分钟内修剪完你的整个草坪”，而你正在使用敏捷，也许你会在最后完成30%的工作。然后，稍后再迭代一些，并完成它。