期限是敏捷的吗？

#1 楼

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


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



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

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


确保每个人始终可以看到在截止日期之前要完成多少工作
确保最重要的功能先完成
确保已完成的功能在不依赖于尚未使用的功能的意义上可用尚未完成
确保开发以可持续的速度继续

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

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

#2 楼

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


我们需要Comdex提供的软件


或


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


之类。不能推迟Comdex或黑色星期五-世界其他地方不能那样工作。

敏捷的目标是无法满足截止日期的事情会更快地失败（这就是好东西），或者可以更快地重新检查范围，以便可以将资源集中在更及时的正确ROI上。

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

敏捷寻求的透明性是在周期的早期显示问题和进展。典型的瀑布式交付失败是您在关门后花了几个月的时间，在截止日期前一周交付产品，并被告知您做错了所有事情，浪费了数月的时间（现在已经完全超过了截止日期） 。另一个经典的瀑布式失败是在您还有数月的最后期限之前一周找到。敏捷试图在流程的早期阶段就使这些问题变得众所周知。原因），则该软件的当前版本是有用且可部署的。


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

#3 楼

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

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

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

如果您要不断开发最好的软件，并且每个阶段都可以满足当前的要求，那么从理论上讲，任何sprint的最后期限都是一个问题。实际上，通常不是这种情况，但最后期限也不是凭空出现的。我所获得的最重要的最后期限是很久以前就传达给我的，这是对质量和功能的期望。我能想到的所有截止日期都是无稽之谈。销售人员要么告诉客户该功能在那里，要么可以不咨询而添加，有时甚至不通知工程人员，或者有人告诉他们的老板它已经完成了。

#4 楼

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

最后期限并不总是错误的。正如我们从欧比万中学到的：


“只有西斯绝对交易”


可以说，在大多数情况下，最后期限是愚蠢的，不必要的，而且当然不是敏捷的，但是要愚蠢地说这总是事实。大宗案例是时间敏感型应用所需的软件，例如选举跟踪软件。如果该软件没有及时准备好进行大选，则推迟大选就不会变得明智或不切实际，而且似乎不太面向客户，只是说“对不起，看来我们花了太长时间。我知道您要向我们付款的软件完全一文不值，但是截止日期并不敏捷，所以您怎么能因不满足要求而对我们持反对态度？'客户由于想要一些对时间敏感的东西而推销它，而到了一天结束时，有人将不得不建造这些东西。那么，如何才能使客户满意并仍然为时间敏感的事物提供看似合理的解决方案呢？好吧，如果开发软件花费的时间不确定，并且截止日期没有变化，那么处理此不确定性还需要其他一些变化...

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

#5 楼

如果有人要设置一个截止日期，那很好，并且可以确定截止日期，但是他们必须了解的是，如果截止日期是固定的，则范围必须保持灵活。
tl; dr
在一个理想的世界，我们没有最后期限，只能在准备就绪时交付东西。但是，现实是人们通常会想知道何时付款。敏捷方法论确实认识到了这一点，但同时也认识到并不是所有东西都可以束缚。如果您确定了截止日期和范围（以及预算），那么事情就会变得很匆忙，最终您将回到旧的瀑布世界，而在项目结束时却陷入了疯狂的紧缩时期。通常，增加预算并不是解决问题的办法，因为增加更多的开发人员和测试人员并不能更快地解决问题。这是一个众所周知的观点（我从经验中也同意这一观点），即您添加的人（每个人都有自己的缺点）越多，花费的时间就越多。购买该软件的人不喜欢被告知，我们可以按时完成任务，但是我们不能做您想做的所有事情。这可以通过优先考虑组成软件的功能来进行管理。您的优先级讨论可能会像这样：

开发团队（D）：“请问您可以优先考虑要交付的功能，最重要的是第一个吗？”
客户（C）：“一切都是优先级1-我希望它们在下个月末之前全部完成。” 。”
C：“好吧，如果我给你更多的钱怎么办？”
C：“好吧，我想要大按钮，但要使其真正大一点，然后... etc”。

现在您可以按优先级顺序开始使用这些功能了。确实也有助于与您的团队一起按照优先顺序降低那些项目，并进行一些早期估计，因为知道更多的信息后，您可能会在开发时进行更改。如果您还没有路线图，可以使用它来重新定义或创建路线图。这样便构成了发布计划的基础。可以与客户讨论该路线图，并承认范围可能会发生变化，但是您确实有交付的顺序。像他们一样调整。与更传统的方法相反，此原理与常规的sprint交付品以及与客户的持续沟通相结合，意味着您自然会被迫对进度更加透明，这是一件好事。
有时客户不会他们不喜欢在某个日期之前不会得到想要的东西，但是他们会理解为什么以及得到的东西将是高质量的。在交付功能6个月后，客户将不会在乎或记得您在某个日期之前交付了产品，他们会记住他们仍在使用的产品质量。

#6 楼

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

敏捷宣言指出：


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

综合文档上的工作软件br />通过合同谈判进行客户协作

响应变更按照计划进行


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

期限不是敏捷的，但是敏捷可以为我们提供有关期限的反馈。敏捷让我们知道，如果我们的速度不让我们在不削减功能的情况下做出最后期限。这也让我们知道我们是否需要聘请才能完成截止日期。在某些情况下，这让我们知道，当没有任何功能需要削减时，最后期限是不可能的。截止日期。这将给出估计的交货日期。如果这些时间超出了期限，则需要与客户进行认真讨论并确定期限是否可行。

#7 楼

我想说每个冲刺的交付都是不可谈判的。您对工作进行评估，在卡片上放上卡片大小，然后进行足够的加载，以使团队保持忙碌，直到冲刺结束（冲刺应该很小-从一周到一个月不等）。 “交货期限”应基于已完成工作相对于预期工作的历史趋势。敏捷没有从旧的“成本/时间/范围”约束思想中添加/删除任何内容，它只是将范围作为管理滑点的首选方法，因为相对于范围而言，更好地确定优先级通常比花费更多的金钱或时间更可取。 >
有些人似乎因为“狂野的西部”而混淆了敏捷。敏捷并不意味着任何事情都会发生。敏捷意味着我们不再对一个合理的人能做出多好的评估而自欺欺人。基本上，我们可以估计大约2-4周后的软件开发。除此之外，还存在各种程度的赃物和猜测。更糟糕的是，为将来提供更进一步的估算的成本接近完成工作的成本。无论出于何种原因，项目经理历来都不愿向客户承认这些绝对的事实。敏捷通过断言我们对软件工程的未来的预测能力有一个局限性来简单地调整了这种想法，并对长期预测进行了微妙的“基于证据的估计”切换。通过一小部分地给死者一定数量的交付，以及长期物资的循证交付，我们得到了接近两全其美的东西-我们对我们实际有能力估算的内容做到诚实，并且我们可以提供合理根据到目前为止的交付量，对长期未来交付量进行估算。

#8 楼

TL; DR


截止日期[a]是敏捷吗？... [D]截止日期被认为与[a]敏捷开发息息相关。


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

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

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

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


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


这是对敏捷原则的普遍误解。诸如Scrum和看板之类的敏捷框架并不专注于截止日期，而是着眼于时间限制和可持续的交付节奏。例如，在Scrum中，Sprint并不是“截止日期”。它是一个时间框，其中充满了团队估计将适合该时间框的工作量，而不会溢出该时间框，然后在时间框到期时“完成”或“未完成”。一旦消失，时间框就永远消失了。任何未完成的工作都必须根据项目的当时（而不是历史）需求在一个新的，短暂的时间内重新计划和重新评估。

时间框的重要性在于，它既可以为利益相关者创建可预见的节奏来审查进度，也可以为团队提供可持续的节奏以交付可能实现的价值增长。工作是渐进的，遵循节奏。因此，提前的大限期的概念与敏捷原则不符。将敏捷过程映射到传统框架的最大困难在于发布计划。发布计划通常涉及固定范围或固定日期的可交付成果。在敏捷框架中，发布计划通常是通过估算过程完成的，其中将范围明确定义为可变变量，而发布日期则是通过迭代估算的。 .0项目在20次迭代结束时；发布版本的范围可能会在项目的整个生命周期中发生变化（因为范围，功能和优先级可能会在每个Sprint的开始时发生变化），但是每个发布的目标日期在项目计划中都是固定的。团队努力为每个Sprint提供可能交付的增量，“完成的定义”包括质量检查，例如持续集成，以确保每个Sprint结束时项目处于可发布状态。有时，您会看到敏捷项目的范围是固定的，但是由于范围是敏捷项目中的可变变量，因此随着每次迭代的范围调整，更改或适应项目不断变化的需求，发布日期可能会随时间而变化。 。我当然不建议对敏捷团队（尤其是经验不足的团队）使用固定范围的方法，但是有时候它是正确的方法。

另请参见



如何执行敏捷发布计划

#9 楼

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

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

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

敏捷性意味着中介步骤将逐步实施，并且应基于常规反馈。基本上，您将向会计师展示您的进度，他们会告诉您他们的想法，可能出现的问题等。这也意味着会计师最初可能有一个很棒的主意，他们认为可以改善实质上的用户体验。三个星期后，看来它不仅没有改进太多，而且还会导致一个月的额外开发。借助Agile，您可以将您的工作从该功能重定向到其他功能，确保按时交付。 />
通常，企业需要特定的交货日期。例如，奥运会结束后，您将无法再提供奥运会在线流媒体服务。从业务角度来说，这只是一次失败，带来巨大的负面后果。尽管冲刺的定期性有所帮助，但并不能完全避免这种风险。

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

#10 楼

eXtreme Programming声明了发布计划：


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


这似乎很公平。它还指出


没有人可以控制所有4个变量。当您更改一个时，您会无意间使另一个更改。请注意，将质量降低到任何以下水平都会对其他3个变量产生不可预见的影响，正如br3w5所指出的那样，增加资源是有界的解决方案。如果派遣了其他人，您可能会添加已经属于团队的几个人。但是您不能简单快速地无限期地增加团队规模，至少没有团队重组需要很多时间。

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

#11 楼

如果正确理解，则软件开发方法的目的是通过集中我们的思想来提高我们的生产力，并为典型情况提供一种通用语言。

遵循字面意义上的软件开发方法，而没有妥协，这在任何情况下都与激进主义或原教旨主义相对应。这种像差的纯形式在实践中很少见，因为它通常会导致市场迅速失败。但是，当然，当开发人员在实施特定方法的艰巨任务中竞争时，超标是自然而然的事。完全使用该方法；即使他们宣讲节制，人性也能确保它不会引起人们的注意。

#12 楼

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

1）瀑布，以及
2）错误。在许多方面，敏捷方法是对错过最后期限或软件的巨大问题的一种反应，当很明显无法满足最后期限时（也包括预算问题），软件就被放弃了。

敏捷通过说“您知道截止日期或功能将要发生变化和/或更改，我们知道了，因此让我们从右脚站起来，甚至不要假装”来尝试将现实注入情况。
关键是截止日期仅是该软件第一版的发布日期。那可能仍然是一成不变的-例如，该软件仅供学术使用，并且必须在学期开始之前就可以使用-但是您提供的不是。您有一个最低限度的可行产品，到那时每个人都可以确信可以交付，并且您有很多“想拥有”的负担。而不是每个人都证明“最后期限”将不会交付整个清单，而是要确保将MVP拿到门外，并确保尽可能多的“想拥有”可能的话，然后评估其余的成本/收益。如果第一个发行版达到了Beta标准，那么许多游戏玩家会感到高兴，而对“确定的，真实的截止日期”在现实生活中的期望却低得多。人们认为软件可以像硬件和钢铁工程一样对待的时代。我们已经知道，这既不可能也不希望，因为它抛弃了软件相对于硬件的最大优势：它是软的。桥梁设计永远无法做到的项目过程。

#13 楼

回答“可能不会”

Project_management_triangle指出成本，时间和范围（以及质量）
相互依赖。 （“选择两次并获得第3名”）要在sprint中完成的故事的集合）

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

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

#14 楼

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

没有最后期限不是敏捷的。 。

截止日期是“您必须按y交付x”，这在两个方面都失败了，因为您承诺在预定的时间范围内提供固定的交付结果（敏捷表示我们不确定我们正在努力实现的目标，以及从敏捷中学到的东西告诉我们，即使我们确实知道很难确定时间表，或者它已经解决了问题，我们也不应该这样做。
已经确定问题的答案是“不，截止日期不是敏捷的”-然后我们可以进行有趣的对话，讨论“如何在敏捷环境中解决截止日期”的问题在其他答案中，对此有很多很好的思考。经常，我们会在适当的时候看到我们的位置-但没有一种适合所有人。

#15 楼

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

“敏捷”是好的。 “敏捷”排序的意思是“思想开阔，加上足够的能力”。最底层的抱怨是最敏捷的。产品，或者将使产品更清洁，更无缺陷且更具杠杆作用，以便公司（或部门）在未来节省两周的时间，这是一个灵活的期限。 -兴趣，它实际上并不存在。