截止日期是敏捷的吗？

为了清楚起见，截止日期为：

时间限制或最后期限是必须完成目标或任务的狭窄时间范围或特定时间点。

^{来自维基百科}

在我整个软件开发生涯中，我一直在做“敏捷”，到处似乎都意味着至少遵循以下实践：

• 每周或每两周冲刺
• 回顾性冲刺计划
• 产品负责人
• Scrum
• 用户故事

但是，我参加过的每个项目都坚持设定截止日期。鉴于敏捷试图将重点放在适应性计划，灵活性和变更上；截止日期是敏捷的吗？

我个人认为它们不是，因为我认为截止日期会导致缺乏灵活性和质量。相反，我认为将精力集中在Sprint和早期交付方面可以提供更多价值。然而，似乎在我所经历的每个圈子中，情况并非如此，并且截止日期与敏捷开发紧密相关。

截止日期是现实。大多数情况下，您必须在某个日期之前拥有某些东西。这是不可避免的。没有截止日期，即使是敏捷项目也可以屈服于帕金森定律：

工作会扩展，以填补完成工作所需的时间。

换句话说，如果您的项目可以永远进行下去，那么它将会成功。

关于截止日期，敏捷尝试做一些事情：

• 确保每个人都能始终看到截止日期之前将完成多少工作
• 确保最重要的功能先完成
• 确保已完成的功能不依赖尚未完成的功能，就可以使用
• 确保发展以可持续的速度继续进行

这样，当不可避免的一天到来时，您不会有一堆无用的代码，但是希望它能正常工作且经过测试，并且只有最重要的东西未完成。没有人会对成品感到惊讶。

是的 “敏捷”和“最后期限”可以完全兼容。

截止日期是生活中的事实。有些事情有很确定的日期。

我们需要Comdex的软件

要么

游戏必须在黑色星期五之前在商店货架上

等等。一个人不能推迟Comdex或黑色星期五-世界其他地区则无法正常工作。

敏捷的目标是无法按时完成任务（这是一件好事），或者可以尽快重新检查范围，以便将资源集中在正确的ROI上。更及时的方式。

截止日期是一个很难确定的艰难日子。敏捷是一种工具，它使人们可以在周期的早期意识到该软件的开发时间将是最初希望的两倍。对于项目经理来说，能够及早意识到这些问题很重要，以便可以添加更多的资源，更改范围，调整截止日期（在确定的截止日期而不是固定的截止日期的情况下）或项目取消。

敏捷寻求的透明性是在周期的早期显示问题和进展。典型的瀑布式交付失败是您在关门后花了几个月的时间，在截止日期前一周交付产品，并被告知您做错了所有事情，浪费了数月的时间（现在已经完全超过了截止日期） 。另一个经典的瀑布式故障是在您还有数月的时间才能找到截止日期之前的一周。敏捷力求在流程的早期就知道这些问题。

敏捷计划在截止日期的范围内进行的另一部分工作是，即使仅部分达成共识的功能是完整的（无论出于何种原因），该软件的当前版本也是有用且可部署的。

好的，我们错过了4月15日部署税务软件所需的一切，但是我们已经有75％的人可以使用，并且自去年11月启动以来我们一直在努力。我们知道自12月中旬以来我们将无法部署全部功能集，并将工作重心转移到80％的客户群上。

必须满足一些截止日期。合同义务，约定，法规要求。有些是由管理人员强加的，他们希望能够将软件开发与电子表格上的制造图放在同一张图表中。无论是什么原因，大多数人都无法摆脱它们。

如果您在一个运转良好的团队中工作，那么开发人员与管理层/利益相关者之间的沟通意味着需要做出决定的人员会被告知要决定是否错过最后期限或继续进行开发更为重要。

即使您每周或每月两次提供完整的用户案例，您仍可能会有截止日期。当一个人出现时，请确保您的利益相关者知道您认为在截止日期之前将适合什么并设定期望。

如果您一直在按照每个阶段当前的要求不断开发最好的软件，那么从理论上讲，任何sprint的最后期限都是一个问题。实际上，通常不是这种情况，但最后期限也不是凭空出现的。我所获得的最重要的最后期限是很久以前就传达给我的，这是对质量和功能的期望。

如果错过了任何期限，那么任何期限都不是那么灵活，但是在某些情况下，出于某些原因，必须设置并保留开发团队无法控制的期限。幸运的是，如果最后期限是合理的，则有很多方法可以使方程式反转并以敏捷的方式处理最后期限。

截止日期并不总是错误的。正如我们从欧比万中学到的：

“只有西斯绝对交易”

可以公平地说，在大多数情况下，最后期限是愚蠢的，不必要的，而且当然不是敏捷的，但是愚蠢的说情况总是如此。大宗案例是时间敏感型应用所需的软件，例如选举跟踪软件。如果软件没有及时准备好进行大选，那么推迟大选就不会变得明智或不切实际，而且似乎不是很面向客户，只是说“对不起，看来我们花了太长时间。我知道您要向我们付款的软件是完全没有价值的，但是最后期限并不敏捷，因此您怎么能因不满足要求而对我们不利？

告诉您的客户因为想要一些对时间敏感的东西而推销它并不是很敏捷，并且最终要有人构建这些东西。那么，如何才能使客户满意并仍然为时间敏感的事物提供看似合理的解决方案呢？好吧，如果开发软件花费的时间不确定，并且截止日期没有变化，那么处理此不确定性还需要改变一些其他东西 ...

如果交货日期保持不变，则其他方面将变为变量。众所周知，软件项目可能存在很大的不确定性。如果您想在项目中取得成功，则必须对某些不确定性做出响应，这通常是交货日期。无论如何，这似乎很自然。但这不是您唯一的选择。如果您坚持要严格的期限，那么解决的方法就是使交付的功能可变。确定功能列表的优先级，明确传达在该日期之前可以交付的功能数量不确定的信息。与客户合作确定这些功能的优先级，以便最重要的功能有更高的发货可能性。然后，一切照旧，只有在截止日期临近时，您才可以装运任何准备好的产品。在这个模型中

如果有人想设置一个截止日期，那很好，并且可以确定截止日期，但是他们必须了解的是，如果截止日期是固定的，则范围必须保持灵活。

tl; dr

在理想的世界中，我们没有最后期限，只能在准备就绪时交付东西。但是，现实是人们通常会想知道何时付款。敏捷方法论确实认识到了这一点，但也认识到并非所有事情都可以被束缚。

这样可以确保您将交付质量保持在适合产品的水平。如果您确定了截止日期和范围（以及预算），那么事情就会变得很匆忙，最终您将回到旧的瀑布世界，而在项目结束时却陷入了疯狂的紧缩时期。通常，增加预算并不是解决问题的办法，因为增加更多的开发人员和测试人员并不能更快地解决问题。这是一种众所周知的观点（我从经验中也同意这一观点），即您添加的人（每个人都有自己的缺点）越多，花费的时间就越多。

现在，通常（除非他们真的很了解敏捷方法），否则不愿告知购买软件的人，我们可以按时完成任务，但无法做任何您想做的事情。这可以通过优先考虑组成软件的功能来进行管理。您的优先级讨论可能如下：

开发团队（D）： “请问您能优先考虑要交付的功能，最重要的是第一吗？”

客户（C）： “一切都是第一要务的-我希望在下个月底之前完成所有工作。”

D：“这可能是可行的，但是如果需求发生变化或者我们发现开发过程中没有想到的问题，那将是不可能的。”

C： “好吧，如果我给你更多钱怎么办？”

D： “ 感叹 ……即使拥有更多资源，也要花一个月才能真正开始使用；因此，如果您不确定如何确定功能的优先级，只需告诉我们您要先完成哪些功能即可。”

C： “好吧，我想要大按钮，但要使其真正大一点，然后...等等”

现在，您可以按优先级顺序开始使用这些功能。确实也有助于与您的团队一起按照优先顺序降低那些项目，并进行一些早期估计，因为知道更多的信息后，您可能会在开发时对其进行更改。如果您还没有路线图，可以使用它来重新定义或创建路线图。这样便构成了发布计划的基础。可以与客户讨论该路线图，并确认范围可能会发生变化，但是您确实要交付一些东西。

敏捷的一大优势在于，它认识到事物在您进行开发时会发生变化，并且在进行调整时会发生变化。与更传统的方法相反，此原则与常规的sprint交付品以及与客户的持续沟通相结合，意味着您自然会被迫对进度更加透明，这是一件好事。

有时，客户不喜欢他们在某个日期之前无法获得想要的东西，但是他们会理解为什么以及获得的东西将是高质量的。在交付功能6个月后，客户将不会在乎或记得您在某个日期之前交付了产品，他们会记住他们仍在使用的产品质量。

截止日期传统上是基于业务生命周期的。税务软件必须在4月15日之前提供。下一个会计年度的报告可能需要在7月之前完成。

在敏捷宣言指出：

流程和工具上的个人和互动

通过综合文档工作软件

通过合同谈判进行客户协作

响应变更按照计划

截止日期是合同。他们是一个计划。他们不响应您团队的速度。如果您失去了三个最好的开发人员，它们不会改变。

期限不是敏捷的，但敏捷可以为我们提供有关期限的反馈。敏捷让我们知道，如果我们的速度不让我们在不削减功能的情况下做出最后期限。这也让我们知道我们是否需要聘请才能截止。在某些情况下，这让我们知道，如果没有要削减的功能，那么最后期限是不可能的。

敏捷团队可以做的最好的事情就是让他们的速度和优先的积压决定最后期限。这将给出估计的交货日期。如果这些时间超出了期限，则需要与客户进行认真的交谈并确定期限是否可行。

我想说每个冲刺的交付是不可谈判的。您评估工作，在卡片上放上卡片大小，然后进行足够的加载，以使团队保持忙碌，直到冲刺结束（冲刺应该很小-从一周到一个月不等）。“交货期限”应基于已完成工作相对于预期工作的历史趋势。敏捷没有从旧的“成本/时间/范围”约束思想中添加/删除任何内容，它只是将范围用作管理滑点的首选方法，因为相对于范围更好地确定优先级通常比花费更多的金钱或时间更可取。

有些人似乎将敏捷混淆为“狂野的西部”。敏捷并不意味着任何事情都会发生。敏捷意味着我们不再对一个合理的人能做出多好的评估而自欺欺人。基本上，我们可以估计大约2-4周后的软件开发。除此之外，还有各种程度的赃物和猜测。更糟糕的是，对事物进行估计的成本越来越接近将来所做工作的成本。无论出于何种原因，项目经理历来都不愿将这些绝对事实告知客户。敏捷通过断言我们对软件工程的未来的预测能力是有限的来简单地调整了这种想法，并对长期预测进行了微妙的“基于证据的估计”的转换。有能力进行估算，并且我们可以根据到目前为止的交付情况对长期未来交付提供相当合理的估算。

TL; DR

截止日期[a]是敏捷吗？... [D]截止日期被认为与[a]敏捷开发齐头并进。

这里的许多答案可能都集中在问题的工程方面。相反，我将从项目管理的角度解决这个问题。

最后期限意味着大量的前期计划，这与敏捷原则不符。取而代之的是，迭代开发模型依赖于包括即时计划在内的时间框，节奏和发布周期，而不是通常与传统项目管理期限相关联的“大型，前期计划”。

仍然可以使用敏捷方法来进行发布计划，但是计划通常基于对达到目标所需的迭代次数的估计，而不是根据法定机构设定的管理目标。这并不是说无法确定交付日期，也不能达到目标，但是定义和实现目标的方式与传统项目管理方法完全不同。

考虑时间框，而不是截止日期

但是，我参加过的每个项目都坚持设定截止日期。鉴于敏捷试图将重点放在适应性计划，灵活性和变更上；截止日期是敏捷的吗？

这是对敏捷原则的普遍误解。诸如Scrum和看板之类的敏捷框架并不关注截止日期，而是关注时间限制和可持续的交付节奏。

例如，在Scrum中，Sprint不是“最后期限”。它是一个时间框，其中充满了团队估计将适合该时间框的工作量，而不会溢出该时间框，然后在该时间框到期时“完成”或“未完成”。一旦走了，时间框就永远消失了。任何未完成的工作都必须在新的，同样短暂的时间范围内根据项目当时（而非历史）的需求进行重新计划和重新估算。

时间框的重要性在于，它既可以为利益相关者创建可预见的节奏来审查进度，也可以为团队提供可持续的节奏以交付可能实现的价值增长。工作是渐进的，遵循节奏。因此，提前的大限期的概念不符合敏捷原则。

基于时间框的发布计划

人们在将敏捷过程映射到传统框架方面最困难的地方是发布计划。发布计划通常涉及固定范围或固定日期的可交付成果。在敏捷框架中，发布计划通常是通过估算过程完成的，其中范围明确定义为可变变量，而发布日期则通过迭代估算。

例如，一个项目可能承诺在20次迭代结束时发布该项目的v1.0。发布版本的范围可能会在项目的整个生命周期中发生变化（因为范围，功能和优先级可能会在每个Sprint的开始时发生变化），但是每个发布的目标日期在项目计划中都是固定的。团队努力为每个Sprint提供可能交付的增量，“完成的定义”包括质量检查，例如持续集成，以确保项目在每个Sprint结束时处于可释放状态。

有时，您会看到敏捷项目的范围是固定的，但是由于范围是敏捷项目中的可变变量，因此随着每次迭代的范围调整，更改或适应项目不断变化的需求，发布日期可能会随时间而变化。 。我当然不建议对敏捷团队（尤其是经验不足的团队）使用固定范围的方法，但是有时它是正确的方法。

也可以看看

• 如何执行敏捷发布计划

将截止日期视为承诺。项目敏捷的事实并不意味着您不应该在给定的日期交付给定的功能。

敏捷带来的是介于两者之间的情况。与其制定一个严格的软件需求规范文档来定义您应在给定日期交付功能A，该功能部件A必须由给定日期的子功能B，C，D和E组成，该文档没有定义要由子功能B，C，D和E组成的严格软件要求文档。在早期阶段，您和您的客户都不知道该功能的外观，或者该功能具有B，C，D和E子功能，或者可能具有B和C或其他十二个子功能。

想象一家公司以前只向小公司交付商品，而刚与大公司签定合同。这个大公司使用EDIFACT，看来您公司当前使用的会计软件无法处理EDIFACT。要求您创建一个插件，按照合同规定，您的公司应在4月15 ^日准备就绪。

敏捷性意味着中间步骤将逐步交付，并基于定期反馈。基本上，您将向会计师展示您的进度，他们会告诉您他们的想法，可能出现的问题等。这也意味着会计师最初可能有一个很棒的主意，他们认为可以改善实质上的用户体验。三个星期后，看来它不仅没有改善太多，而且还需要一个月的额外开发时间。有了Agile，您就可以将您的工作从该功能重定向到其他功能，确保按时交付。

您还应该了解客户的观点：

• 通常，企业需要特定的交货日期。例如，奥运会结束后，您将无法再提供奥运会在线流媒体服务。从业务角度来看，这仅仅是失败，会带来巨大的负面后果。

• 没有承诺，开发人员或分包商要么成为完美主义者，要么将项目置于低优先级。尽管冲刺的规律性有帮助，但并不能完全避免这种风险。

  我不喜欢这样的截止日期，特别是因为截止日期延误很容易发生，但是我仍然理解为什么很多公司都这样做。仅通过查看sprint并不总是很容易看出该项目是否落后于进度：在这种情况下，错过了最后期限可能会清楚地提醒我们，某些事情已经失控，应该立即进行处理。

eXtreme编程说明了发布计划：

发布计划的基本原理是，可以通过四个变量来量化项目：范围，资源，时间和质量。

看起来很公平。它还指出

没有人可以控制所有4个变量。当您更改一个时，您会无意间导致另一个更改。请注意，将质量降低到任何以下水平都会对其他3个变量产生不可预见的影响

就像br3w5所指出的那样，增加资源是有界的解决方案。如果派遣了其他人，您可能会添加已经属于团队的几个人。但是您不能简单快速地无限期地增加团队规模，至少没有团队重组需要很多时间。

因此，由于质量和资源都无法减少：截止日期是时间限制，这意味着您需要调整范围。使用敏捷性可以使您在可能的最高生产力范围内按时完成任务。但是，您通常可以保证范围的某些部分会及时完成。这是您可以放心地估计其时间限制在截止日期以下的部分。通常情况下，某些事情实际上与您已完成的工作非常接近，并且鲜为人知。

如果正确理解，则软件开发方法的目的是通过集中我们的思想来提高我们的生产力，并为典型情况提供一种通用语言。这是关于灵感和赋能，而不是精神控制和内。

遵循一种软件开发方法，字面上没有任何妥协，在任何情况下都与所谓的激进主义或原教旨主义相对应。这种像差的纯形式在实践中很少见，因为它通常会导致市场迅速失败。但是，当然，当开发人员在实施特定方法的艰巨任务中竞争时，自然而然就会超出标准。

传教士和传教士主要针对的是仍然需要说服性使用这些方法的人，这使问题更加恶化。即使他们宣讲节制，人性也能确保它不会引起人们的注意。

截止日期不是敏捷的，它们是：

1）瀑布，2）错。

软件和截止日期不能很好地协同工作，甚至永远无法协同工作。在许多方面，敏捷方法是对错过最后期限或软件的巨大问题的一种反应，当很明显无法满足最后期限时（也包括预算问题），该方法就被放弃了。

敏捷试图通过说“您知道截止日期或功能将要发生变化和/或更改，我们知道了，所以让我们以正确的态度站起来，甚至不要假装”将现实注入情况。

关键在于，截止日期只是该软件第一版的发布日期。那可能仍然是一成不变的-例如，该软件仅供学术使用，并且必须在学期开始之前就可以使用-但是您提供的不是。您有一个最低限度的可行产品，到那时每个人都可以确定该产品可以交付，并且您的负担是“想拥有”。而不是每个人都证明“最后期限”将无法交付整个清单，而是要确保将MVP拿到门外，并确保尽可能多的“想拥有”可能的话，然后评估剩余部分的成本/收益。

任何长时间玩过计算机游戏的人都知道这是如何工作的！如果第一个发行版达到Beta版标准，那么许多游戏玩家会感到高兴，而对“确定的，真正的截止日期”在现实生活中意味着什么的期望就太低了。

因此，截止日期并不是敏捷的，而是人们认为软件可以像硬件和钢铁工程一样被对待的日子的延期。我们已经知道，这既不可能也不希望，因为它抛弃了软件相对于硬件的最大优势：它是软的。

敏捷试图通过允许目标在项目过程中进行开发和更改，从而以一种桥梁设计无法做到的方式来利用这种软性。

回答“可能不会”

所述Project_management_triangle指出成本，时间和范围（以及质量）彼此依赖。（“选择两个并获得第三”）

Scrum冲刺选择固定的时间（即7天=冲刺的时间）和成本（即7个团队成员的预算），并估计范围（冲刺中要完成的故事数）

如果管理部门或销售部门试图定义这三个（成本，时间和范围），那么就混乱而言，它就不是敏捷的，因为团队无法承诺实现目标（不违反质量=完成定义）

专业管理人员试图确定成本和时间，并在有固定日期需要的情况下根据需要缩小范围。

不能简单直接地回答这个问题吗？

没有截止日期不是敏捷的。

关键是要以迭代的方式构建您可以学到的东西，并随身携带。

最后期限是“您必须按y交付x”，这在两个方面都失败了，因为您承诺在预定的时间范围内提供固定的可交付成果（敏捷表示我们不确定要交付的目标，并且从敏捷中学到的东西告诉我们，即使我们确实知道很难确定时间尺度-或其解决的问题，也不应该这样做。）

确定问题的答案是“不，最后期限不敏捷”-然后我们可以进行有趣的对话，讨论“如何在敏捷环境中解决最后期限”问题，并且有很多好处在其他答案中对此进行思考。

在我看来，对后者的合理回答是，我们将尽早并经常交付价值增量，并在适当的时候看到自己的处境-但没有一个适合所有人的规模。

工作所需的敏捷度与他们在组织结构图中的位置成反比。

“敏捷”是好的，因为它是什么。“敏捷”排序是指“思想开阔，加上足够的能力”。底部的咕unt声必须最敏捷。

如果在管理层面上，尖锐的上司足够敏捷，以至于知道将截止日期推迟一周可以使产品更好，或者可以使代码更清洁，更无bug，并且更具杠杆作用，从而使公司（或部门）在未来节省两周，这是一个灵活的截止日期。

但是，就像开明的自我利益一样，它实际上并不存在。