您如何应对过于迅速的变更带来的成本？

像大多数现代开发人员一样，我非常重视敏捷原则，例如客户协作和对变更的响应，但是当产品所有者（或由谁决定需求和优先级的人）过于频繁地改变需求和优先级时会发生什么呢？喜欢一天几次？

我最近继承了一个很小的代码库，该代码库有错误，不完整，甚至无法处理它应该想到的最简单的情况。我可以处理技术问题，但每天都会收到几封电子邮件，短信或电话，说：“天哪，您现在就必须努力！最重要的事情！这是一个人！”（这只是一点点夸张）更糟糕的是，大多数事情都是次要细节，甚至与该软件实际上应做的事情都不相关，反正要花几天的时间才能实现。我试图解释的是，时间太短了，我们应该首先专注于最重要的事情，但是翻译中似乎会丢失一些东西，因为同一件事会在一两天后发生。

是否有某种产品所有者负责人的角色，深入的研究，隐喻或报价可以帮助我减少浪费的精力或至少解释这种混乱行为的代价？

这就是积压的目的。新请求将被积压，并且优先级只能在迭代边界上更改。平均延迟一个星期（短短两周的冲刺）足够敏捷，足以应付除最严重的紧急情况以外的所有紧急情况。

这就是我处理类似问题的方式..早在我们敏捷之前的敏捷时代。

对于任何更改请求，客户均设置优先级。开发人员只能并且必须停止执行任务才能执行更高优先级的任务。优先级相等的任务是按到达顺序进行的计划。（工作开始后便无法更改任务优先级。）

当您告诉客户您无法执行他的任务时会很受伤，因为您正在执行的重要性不重要的任务X与他的最新请求具有相同的优先级。然后，您告诉他，在该优先级上，在他的最新请求之前，有50个琐​​碎且不重要的任务。现在真正的收获是-所有这些任务都位于... HIM ...设置的优先级1（最高）上，因此他无法让您脱离正在执行的任务。现在，当您完成将窗框向左移动3个像素时，可以在很少使用的配置选项上为冰岛语翻译中的较长单词腾出空间.....

我还关闭了SD办公室的门，将其锁好，然后将电话摘了下来。直到上午10点，中午12点和下午2点才忽略电子邮件。尽管人们有什么想法和感觉，但是世界仍然在阳光下运转，我们完成了工作，“客户”获得了比过去更快，更好的软件交付给他们。

优先事项花了几周时间才能解决一些更切合实际的事情，我们能够打开门等。但是，该系统保留了相当长的时间。您可能不需要太极端（我们做到了），并且需要高级管理层的支持。但这会起作用....

SOP。标准操作程序（或至少由您的管理团队签署的宽松协议）。您的部门需要开发一个，或者与您的管理团队一起开发一个。您需要与之交谈的人员位于产品所有者/客户经理上方。

您的SOP应该定义的一些示例。

• 客户或内部实体请求更改时应遵循的程序
• 对产品质量控制或验证有什么影响和/或影响？
• 合理确定交付时间表的方法是什么？这个迭代？下一个版本？

如果没有这样的程序，每个人都会像僵尸一样追赶着您，并且希望现在一切都现在。这样的人不会尊重您的礼貌“不”或“请稍等”。有了坚定的政策，这些渴望代码的变体就会明白，在如此宽松的条件下索要东西时，他们是错的。

最终结果使您不满意，这与您公司的最大利益无关。

附带一提，您可能继承了某人因如此公然不尊重自己的位置和职责而造成的混乱。在那种情况下，人们往往很难生产出优质的产品。有什么奇怪的吗？软件工程101。

在这些“准备，开火，瞄准”条件下工作非常困难。在我看来，您是从一个非常不安全的人那里收到要求的，每当一个更高的人提出一个概念性想法时，他的观点就会改变。

在这种情况下，我发现在回复电子邮件之前至少等待一个小时很有价值。（除非文本已被整个组织广泛取代电子邮件，否则我将不理会这些文本。）也许可以阅读，但不能回复。这样，您可以将时间花在专注于需要做的实际工作上，而不用讨论明天可能变得无关紧要的随机性紧急情况，甚至以后也不会发送两三封电子邮件。在我的上一份工作中，如果真的很紧急，有人会过来与我交谈，假设我还没有看到电子邮件（如果您是远程工作，则可能会进行实际的双向通话当量）。

当您进行面对面或电话交谈时，用您自己的话重复该人的要求，然后询问有关新要求和优先级的问题会很有帮助。“如果我理解正确，您是说我们应该停止处理当前的最高优先级X，而现在专注于分钟的优先级。这是一个很大的转变。您能解释一下业务的变化吗？我可能需要做更多的背景工作而不是仅更改UI。其他业务流程是否会发生变化，例如帐单或库存？（您是否希望这些新数据元素出现在所有月度报告中？” 说出以下效果也是很有用的：“您了解，如果我们继续进行这项新工作，将会使当前最高优先级X的发布至少延迟（一周，一个月，

如果是真正的紧急情况，请求者应该能够回答此类问题，或者立即将您转介给可能的人。如果这不是真正的紧急情况，则这种对话将迫使请求者放慢速度，并确定更改的真正重要性，因为他们需要为您提供更多信息。通常，他们会发现管道中已存在的内容更为重要，或者至少不值得停止，新请求可以列入列表。

如果确定有必要进行更改，则发现在电子邮件中写下请求的内容以及您对更改的理解，然后将其发送给原始请求者，询问他们是否同意更改范围，这很有用，再次澄清。这样，您就已经写了关于需要做什么以及为什么要求的文档，以防万一您为什么不再使用Current Top Priority X，或者需要解释为什么原来的截止日期还没有到位被满足。

这将有望改善您与请求者的关系，因为您正在展示自己的知识，并确保您正在研究他们想要的东西，但是您对进行更改需要诚实。通过详细询问请求，他们会看到您在想，并考虑了他们本来可能没有的事情。

似乎没有人提到Sprint及其用户案例ideally should be locked till the next sprint（典型的sprint需要2-4周）。通过锁定-我的意思是不应将其他任务添加到已启动的Sprint中。

如果用户故事足够大而不适合sprint，则在sprint期间将其制动为较小的可完成任务。另外，如前所述，即使是优先任务也需要保留在积压中，并且在下一个sprint计划期间，高优先级一旦获得标记就可以了:)

编辑：在春季期间只能引入较小的更改。如果他们带有紧急状态。但是，如果在sprint期间总是有几次紧急情况，则需要在Sprint计划本身中进行一些更改。

Scrum具有Scrum Master角色，应该是应该解决您提到的问题的人。

如果有人负责，例如团队负责人，项目经理，Scrum Master等，那么我会和那个人交谈。

我试图解释的是，时间太短了，我们应该首先专注于最重要的事情，但是翻译中似乎会丢失一些东西，因为同一件事会在一两天后发生。

我认为您将不得不不断地反复说明这一点。听起来您可能需要接受与之共事的某些人的生活没有帮助。如果幸运的话，您最终会看到一个变化。

敏捷宣言说，最基本的原则之一是：

即使在开发后期，也欢迎不断变化的需求。敏捷流程利用变更来获得客户的竞争优势。

但是，我不认为它们意味着每天都会变化。您可能需要一天多次更改产品的基本价格，而不必更改一天可能多次销售该产品的方式。相反，产品销售的工作流程可能会每周更改一次（在高度响应和动态的业务中）。

同样，虽然产品销售的工作流程可能每周都会更改，但我认为整体产品不会每周更改。我无法想象今天会给我们Office的Microsoft，但明天会给我们Offooose，一周后就会给Offasooooooooooos。

不，敏捷并不是变化所代表的意思。我确实相信这是由于愿景不佳以及对变革概念的深刻误解。

更不用说在冲刺中不欢迎更改了，在这种情况下，开发人员会去他们的洞穴，并且确实需要专注于自己的工作。相反，应将更改添加到产品待办事项列表，并在将更改交付给Scrum团队之前对其进行分析和确定优先级。换句话说，Sprint Backlog并非一成不变。应该使用较短的冲刺来寻求更大的敏捷性，而不是每天多次将更改直接注入开发人员房间。