谁在敏捷开发任务中进行估算？ [关闭]答案

【问题标题】：Who make estimations on Agile for Developement tasks? [closed]谁在敏捷开发任务中进行估算？ [关闭]
【发布时间】：2018-10-11 12:54:30
【问题描述】：

我们应该在我的团队中遵循敏捷方法。我们有一个 Scrum 主管、产品负责人、代理产品负责人和开发团队，我是一名开发人员。

在扑克期间，我们需要对开发任务进行估算。根据我对敏捷的了解，只有开发人员可以给出估计，在我们的例子中，Scrum master 和产品负责人希望我们遵循他们的估计（他们对客户有一些压力）所以当我们将任务估计为 5 天时，他们不喜欢它，即使我们解释了为什么是 5。一般来说（99% 的时间）他们会要求重新估计，并且有点“强迫”我们将估计更改为 2。

最糟糕的是他们甚至不知道他们在说什么，有时我们甚至有一半的规格！

我的问题是：根据 Agile 的说法，Dev 任务估计是否真的只能由 devs 完成，对吗？

【问题讨论】：

这可能更适合软件工程或工作场所。话虽如此，我同意估计只能公平地来自那些从事这项工作的人——否则你就会犯猪和鸡的问题（猪和鸡同意做早餐。“太好了！”鸡说，“你带培根，我带鸡蛋”。）
任何对工作主体做出贡献的人都会对估算做出贡献。例如，开发人员可能会说更改页面上的措辞是一项微不足道的工作，并且可能只需要几分钟的努力。但是产品负责人可能会预见到很多会议，并与企业所有权和法律顾问来回来定义文本。总体而言，尽管开发工作量很小，但工作量很大。现在，话虽如此，您所描述的并不是敏捷。甚至是职业行为。只是人们提出要求。
作为敏捷的旁注......当你说“有时我们甚至有一半的规范”时，这是完全合理和普遍的。是敏捷是接受这样一个事实，即根据已知不完整的信息进行估算。随着更多信息的了解，估计值可能会发生变化。
我投票结束这个问题，因为它是关于软件开发方法，而不是编程。

标签： agile scrum estimation

【解决方案1】：

你是对的。 Scrum master 的角色是促进会议，而不是通过估算参与会议。你是对的。估算仅由开发团队完成。

我不会与敏捷原则争论，而是通过写下两个估计来做一个更有建设性的方法来解决这个问题：开发团队的估计和 Scrum 主管和产品负责人的另一个估计，当票证完成时，看看有多少实际花费的时间。开发团队也可以从中学到东西，但 Scrum master 和产品负责人可以学到更多东西。

听起来压力很大。

【讨论】：

不知道为什么对这个答案投了反对票。它回答了问题（并且正确），然后提供了一些额外的建议。很好的答案。

【解决方案2】：

根据 Scrum，最终的估算是由从事这项工作的人做出的：

开发团队负责所有估算。产品所有者可以通过帮助开发团队了解和影响开发团队选择权衡，但执行工作的人会做出最终估计。

https://www.scrumguides.org/scrum-guide.html#events-planning

也许可以将您的 Scrum Master 指向 Scrum 指南；-)

工作的好处是它需要花费大量时间，无论是 2 还是 5 都无关紧要。如果它们对所有工作的影响相同，您可能会有一个稳定的速度。只是不要将天数估计为工作需要多少天，建议以相对大小而不是天数来估计。

【讨论】：

【解决方案3】：

我的问题是：根据 Agile 的说法，Dev 任务估计是否真的只能由 devs 完成，对吗？

如果您阅读经典 Scrum 的文献，那么 Scrum 计划会议就会被一分为二（被一把强大的剑）。

在上半年，产品负责人为团队提供待办事项，这些项目是即将到来的 sprint 的候选人。在提炼/待办事项梳理会议期间，整个团队（不仅是产品所有者）对待办事项项目进行了估计（以故事点为单位）。团队通过查看以前冲刺的速度并咨询他们的直觉来决定要投入多少工作。

在会议的后半部分，团队将积压的项目分解为任务，并在适当的时候设定各个任务的时间估计。

这是否是一个好的过程是非常具体的上下文，所以我让你来决定......

估算的目的是对未来版本的独家新闻进行良好的预测。它是产品所有者在优先考虑和管理对利益相关者的期望时的工具。如果您的 PO 认为他/她可以通过操纵估计来获得更多功能，那么他们可能会大吃一惊。

【讨论】：