在Scrum评估中讨价还价和失败的尝试是否合法？

我在Scrum会议中注意到，开发人员通常会对故事进行现实的估计。但是，即使是相当简单的故事，也需要大量的精力进行配置，设置第三方组件，测试和最终构建，并且系统积累了相当多的技术债务，因此对于产品所有者或管理层来说，估算值通常显得过高。

PO经常尝试降低此类估计，例如：“什么，您想要这个故事要13个故事点（4天），这不可能！我无法向管理层解释，有人应该可以对此进行编码3 SP [在4小时内！！”。结果，开发人员不得不屈服于做出5或8个故事点（1.5至2天）的估计值（Scrum估计值仍被视为承诺，而不仅仅是预测）。

当然，如果没有任何降低期望的计划（主要是在测试和质量方面），则这些冲刺经常会失败。开发人员的估算是诚实，现实的估算，击败估算并不会降低实际的工作量。

可以说：“您不应该做出不可能的承诺，只是因为有人逼着您去做！” 但是我认为，开发人员的工作是软件设计和编码，而不是讨价还价或承受压力！可能有各种各样的交易，通常是直接与外部客户打交道的交易，但这并不是大多数Office开发人员！

对我而言，这种做法只会使程序员看起来像个混蛋，会导致不断出现的sprint故障，并阻止了实际的估算，同时也寻求了实际的改进。

Scrum准则对此主题有何看法，或者他们对此有何表述？

编辑：用故事点代替时间。我指的是规划扑克和故事点的初始估算阶段，而不是任务详细计划。我只是把日期/时间放在这里，因为有时是典型的对话，有时是用时间而不是时间。抱歉给您带来任何混乱！故事点示例比时间示例代表更长的时间段。

编辑2当前没有专门的Scrum主持人，而PO在评估会议时扮演着这个角色。因此，可能是角色冲突使这种不适当的讨价还价变得更糟，因为他是作为权威而不是中立或开发者的混乱大师出现的。也许，只要没有候选人，就可以将他作为有偏见的参与者而不是“大师”来解决。

您描述的情况是有毒的。这种讨价还价忽视了团队的现实和专业知识，故意掩盖了整个团队和整个组织的信息，并且阻碍了团队随着时间的推移而不断发展。

如果您想以http://www.scrumguides.org/scrum-guide.html作为授权机构，则需要强调：

只有开发团队才能评估在即将到来的Sprint中可以完成的工作。

和

Scrum依赖透明性。根据工件的感知状态做出优化价值和控制风险的决策。就透明性而言，这些决定具有良好的基础。如果工件不完全透明，则这些决策可能会出错，价值可能会减少，风险可能会增加。

您的产品所有者可能希望仅在4小时内完成一项任务。这甚至可能是一个合理的目标。一个健康的反应可能是接受团队的估计，对其进行评估是否准确，然后问“我们需要改变什么才能更快地完成此类任务？” 协商任务中涉及的工作范围也可能是合理的，并突出了开发人员和产品所有者在理解手头工作方面的重要区别。要求团队在没有新信息的情况下更改其估算值只能确保估算值不准确。

开发团队可以使用许多策略来尝试改变这种模式，但是当您给出示例示例“我无法向管理层解释”时，我会非常紧张。听起来您的产品所有者没有管理层的信任（他们产生的估计不准确可能无济于事），并且可能不愿意就当前的流程失败透明化。

我认为，SCRUM的最大成就之一就是发展了故事点，明确表达了避免这里提到的讨价还价问题的意图。故事要点的全部目的是避免任务与需要花费多少天之间的直接联系。取而代之的是，这两个概念通过速度的思想联系在一起。

如果我是一名开发人员，并且被扭曲成将13点故事称为8点故事，我会很乐意承担义务。它们正在影响其估计能力。我将简单地解决所有困难以进行匹配。最终，团队的速度将以每周的故事点数降低，以匹配管理层“淘汰”故事点的意愿。交付给管理层的数字应该匹配：“我们已成功地将完成里程碑所需的工作故事点数减少了50％。但是，我们看到速度相应减少了50％，因此净效果是将完全在需要的时间内完成我们要完成的工作。” 存在速度的概念是为了打击上层管理的一厢情愿。

现在，我认为有两个极端值得研究。一个是管理的完全失败，另一个实际上是管理层关心的非常有效的关注。第一个案例是SCRUM的死刑，当时开发人员被告知“您的生产力不足。您需要产生更多的故事点工作”。如果发生这种情况，则说明您实际上不是在使用SCRUM，而是Cookoo，他将SCRUM从巢中踢出，并试图由回到下一个的母鸟喂食。

现在有一种情况，我认为管理层应该能够像这样扭动手臂 如果客户愿意，应该说“如果您的速度为每周20个点，我将无法承担50个故事点的费用来完成此任务。我需要您在30个故事点中完成此任务”。重新协商这些故事的内容，以将其范围缩小40％。SCRUM并不是让开发人员去做他们想做的事的免费门票，它是一种可以帮助他们和管理层公开讨论需要做什么的沟通工具。如果客户愿意接受无法直接完成工作的内在风险，那么将客户挤在开发人员上并说“在30分内完成任务”也是有效的。如果错过了最后期限，开发人员可以说“ 然后接受实际完成的一切。我认为有更好的方法来衡量团队的生产力，但是我不得不承认这是一个有效的过程。然后接受实际完成的一切。我认为有更好的方法来衡量团队的生产力，但是我不得不承认这是一个有效的过程。

首先，采购订单不应将任务信息提供给管理层。任务估计完全是为了团队的利益。团队之外的任何人唯一需要知道的是他们正在从事哪些故事，他们的得分是多少以及团队的平均速度是多少。Ť

其次，除非采购总监是一位对软件有深入了解的高级开发人员，否则他们对任务估计的意见不应有太大的分量。开发人员是那些具有系统知识的人，也是从事这项工作的人。除非他们都是刚从学校毕业，但估计技能为零，否则应该排除他们的估计。

这并不是说有时不能质疑估计值。如果是这样，这需要以积极的方式发生。例如，“您是否认为我们已经为“ x”完成了一半的工作”，或者“您还记得包括做Y的时间吗？”。

底线：只要他们真诚地努力做到准确，开发人员就应该放心进行所需的估计。如果他们说要花四个小时，则必须接受。

Scrum准则对此主题有何看法，或者他们对此有何表述？

他们什么都没说。任务估计不是scrum的一部分。有了scrum，估算就停止在故事点上。任务估计仅仅是一种工具，可确保团队已经考虑完成故事所需的所有工作，从而帮助他们更好地估计故事点。

Scum Master的任务是确保遵循Scrum流程。这包括确保团队不会（一致地）过度投入他们可以在冲刺中完成的工作量。
一方面，这意味着要统治一支过于热情的团队，但另一方面，如果产品负责人对团队施加压力，也要推回产品负责人。

保持承诺/预测切合实际的一种好方法是查看在最后几个冲刺中实际实现的故事。这就是团队证明他们可以完成的事情，因此毫无意义的是将大量的工作拉入sprint，因为它不会完成。

正如其他答案所表明的那样，就团队给出的估算进行讨价还价不是 Scrum流程的一部分。团队最熟悉该软件，因此他们应该最清楚某件事情有多少工作。

什么可以讨价还价的就是范围的一个故事。如果产品负责人认为某个故事的估计值比其合理预期的大小要大或小，则他们可以要求团队进行澄清，以了解需要完成的工作的观点在各方之间是否相符。
如果该故事确实需要那么多工作，则产品负责人可以决定将其拆分为几个较小的故事，并在这些较小的故事上分配功能。

团队负责提供质量，绝不应该讨价还价。

是的，没有。

是的，冲刺团队应与有关产品负责人协商什么进入冲刺阶段。

不，产品负责人没有说要花多长时间。您是专家，而不是他们。

看，您不必处理这种垃圾-您的经理或团队负责人可以帮助您成功。这意味着与项目经理（或他们的老板）打交道，这样您就会成功。也就是说，这并不难。

“没有。”

他们将要做什么？自己写代码？

允许这种行为是Scrum Master的失败。她的首要任务是保护车队。由于上述原因，该PO是近视的。Scrum Master应该介入并以积极的方式重新组织讨论的范围。

当然，这样的压力会导致速度下降，这是OP已经引用的。如果团队始终没有完成冲刺，Scrum Master应该再次介入并询问为什么会这样。在真正有毒的环境中，团队成员可能不会在回顾中坦诚相待。但是在这种情况下，Scrum Master有责任指出不良行为并保护团队。

如果您发现自己的Scrum Master无法或不会做这些事情，那么您可能需要其他Scrum Master。PO响应典型压力。探洞团队也像人类经常做出的反应一样。Scrum Master的工作就是要看清它的本质并停止它。OP的职责是在追溯中提出，并在必要时与潜在客户和经理联系。如果仍然无法解决问题，请更新您的LinkedIn个人资料，并找到更好的合作伙伴。

一个产品开发团队（从产品所有者到开发人员再到测试人员的每个人）都可以遵循敏捷过程，并在具有合理能力的人员和切合实际的期望下获得良好的结果。

或者，他们可以遵循表面上类似于敏捷过程的过程。

该PO可能认为他可以通过尝试减少任务的时间估计来获得更好的结果。当然不行了。如果某件事情需要三天，您会给我很多现金，我估计我可以在一小时内完成。仍然需要三天。如果您来对我大喊，因为它没有像承诺的那样在一个小时内完成，那将需要五天。

他所取得的一切都打破了敏捷过程，放弃了他可能获得的所有积极成果。Scrum主管应该具有经验，力量和勇气来防止这种情况。如果管理层让没有经验的Scrum Master或没有赋予Scrum Master防止这种情况的能力，那么敏捷就会打破他们的错。如果Scrum主管没有勇气，那么他将与PM一起承担责任。

我会说这在很大程度上取决于动机。估算的总体目标是了解团队在任何给定的冲刺期间可以完成多少工作，然后可以基于该速度来预测未来的工作。例如，如果团队每个冲刺完成30个故事点，并且积压的X项之前有约60个故事点，那么产品负责人可以合理地说X项将在大约6周内完成（基于标准的两周冲刺）。

为了使此估计尽可能准确，对于特定项目有多少故事要点并不陌生。Scrum实际上鼓励它。这种分歧有时甚至会加剧。但是，最终目标应该是准确地估计PBI的复杂性，而不是人为地降低工作量，以便您可以尝试将更多的PBI塞入给定速度。

原则上，这实际上就是计划扑克的工作方式。每个人都列出他们的估计。然后，Scrum Master会估算出最高和最低值，并询问团队成员为何认为该值应该高/低。这使团队有机会听取有关工作的不同观点，并更好地了解任务的实际复杂程度。经过讨论，每个人都再次提出自己的估计。冲洗并重复此过程，直到对复杂性达成普遍共识。

换句话说，挑战者的估计是正确的，因为挑战者除了他们只是希望降低估计值之外，还有他们为什么会不同意的理由。因此，如果您认为自己的估计仍然正确，那是您有责任说服您的团队您的估计是正确的。