我们应该在团队中遵循敏捷方法。我们有一个Scrum主管,产品负责人,代理产品负责人和开发人员团队,我是一名开发人员。
在扑克期间,我们需要对发展任务进行估算。根据我对敏捷的了解,只有开发人员才能提供估算,在我们的案例中,Scrum主管和产品负责人希望我们遵循他们的估算(他们对客户有一定的压力),因此当我们估算5天的任务时,他们不喜欢即使我们有解释为什么5的原因。通常(99%的时间),他们要求重新估算和某种“强迫”我们将估算值更改为2的方法。
最糟糕的是,他们甚至不知道他们在说什么,有时我们甚至只有一半的规格!
我的问题是:根据敏捷,开发任务估计仅由开发人员完成,对吗?
答案 0 :(得分:3)
你是对的。 Scrum管理员的角色是为了促进会议,而不是通过估计参与会议。你是对的。估算仅由开发团队完成。
我将通过记录两个估算值而不是使用敏捷性原理来采取更具建设性的方法:写下两个估算值:开发团队的估算值,以及Scrum管理员和产品所有者的另一个估算值,以及何时完成工作才能查看多少实际花费的时间。开发团队也可以从中学到东西,但是Scrum管理员和产品负责人则可以学到更多东西。
听起来压力很大。
答案 1 :(得分:1)
根据Scrum的最终估算是由从事这项工作的人做出的:
开发团队负责所有估算。产品 所有者可以通过帮助开发团队理解和影响开发团队 选择权衡,但执行工作的人员会 最终估算。
https://www.scrumguides.org/scrum-guide.html#events-planning
也许将您的Scrum Master指向Scrum指南;-)
工作的好处是花费时间,而不是2还是5并不重要。如果它们对所有工作都产生相同的影响,则您可能会保持稳定的速度。只是不要估计工作量需要多少天,建议是以相对大小而不是天数来估计。
答案 2 :(得分:-1)
我的问题是:根据敏捷,开发任务估计仅由开发人员完成,对吗?
如果您去阅读经典Scrum的文献,Scrum计划会议就变成一半了(用大剑)。
在上半年中,产品负责人向团队介绍了待办事项,这些待办事项是即将开始的冲刺的候选人。在优化/积压整理会议上,积压项已经对整个团队(不仅是产品所有者)产生的估计(以故事点为单位)。团队通过查看先前冲刺的速度并咨询他们的直觉来决定要承担多少工作。
在会议的下半年,团队将待办事项分解为任务,并在适当时设置相应任务的时间估计。
这是否是一个很好的过程是特定于上下文的,所以我让您决定...
估计的目的是为以后的发布获得良好的预后。它是产品所有者确定优先级和管理对利益相关者的期望时的工具。如果您的采购订单认为他/她可以通过操纵估计来获得更多功能,那么他们将为您带来惊喜。