错误只有冲刺?

错误是有正式的流程只冲刺呢?

它的工作还有待完成,因此应该占产品待办事项列表。没有什么能阻止一个团队有一个Sprint目标工作的类型是减轻。

显然要在项目没有错误,但我没有明确的论点,为什么我们需要达到这个状态。

缺陷不发生通过机会或不幸,他们出现,因为“完成”的定义是无效的。

开发人员负责确保工作的完成和可用的质量。我建议,没有论点是:这是一个专业的问责的问题。

团队在做改善国防部,当开发人员满足它每个Sprint“bug”不了?

任何人都有一个错误只冲刺呢?已经有人做出这样的产品负责人成功?

产品负责人不负责质量、开发人员,和阿宝应该尊重这一论点。开发者对他们来说应该足够的时间到每个Sprint计划来保证完成的质量标准。剩下的计划在新工作能力将反映这一承诺。

产品所有者负责”产生的产品工作的价值最大化的Scrum团队”。只关注bug修复可能是也可能不是最好的使用Scrum团队的时间和精力,对在每个Sprint交付的价值最大化。

你不需要解决50报道和开放的bug报告到一个国家,所有确认之前解决下一个版本的bug。为此,您可以与团队合作,增强“完成”的定义。自“完成”的定义是“一个正式的描述的状态增量开会时所需的质量度量产品”,你可以声明一个质量措施是“不知道新引入的缺陷存在于产品增量”。有些团队称之为zero-bug政策。然而,它可以追溯到最大化价值——有些错误是如此罕见,所以容易解决,或有轻微影响,修复的成本通常不超过提供其他功能的价值。

这将是一个好使用Sprint回顾花一些时间讨论如何防止释放增加,包含新的缺陷和产品所有者认为如何修复一个缺陷的价值。价值不仅仅是外部利益相关者,但Scrum团队,因此开发人员可能有机会表达修复一个缺陷的价值考虑。

一切@Ian @Thomas说《我的观点。你在这个位置,因为开发人员专注于完成故事而不是交付质量。

我要分享产品待办事项列表管理技术,我的团队如果他们发现自己在这个位置。Scrum指南定义产品待办事项列表中的待办项。它不区分类型的物品。只是一个项目列表。所以我建议你停止观看缺陷、特性,故事,任务等。看看所有的工作必须做为了提高产品。我甚至就放弃使用不同的项目类型在您所使用的软件来跟踪这些事情,只是让一切相同的类型。来证明这个我解释一切产品待办事项列表有两个值。负值只要是积压,正值时的增量。这适用于功能或错误。想法是,团队应该添加尽可能多的产品价值。 Take a group of items from the Product Backlog into a Sprint Backlog that will support the Developers in reaching the Sprint Goal. And the Sprint Goal should be stated in the value that is being incorporated into the increment. Not something like "Finish feature A" or "Fix these 12 bugs". What value is added to the product when the selected items are turned into positive value?

没有什么比“错误只有冲刺”。正如丹尼尔提到的,虫子只是项目特定的春天。Scrum团队决定冲刺的项目基于速度(衡量一个团队的工作量可以解决在一个Sprint)。我有一些冲刺过去,我们只处理错误交付的版本解决错误。所以,这不是一个un-usual场景。

我非常感谢所有提供的反馈。我已经从我的团队中的开发人员得到一些反馈,他们不会只爱一个bug sprint和我可以尊重这一观点。我将提出以下两个概念我的团队在接下来的冲刺复古:

1)每个sprint计划都有至少2错误从一开始。喜欢哪两个产品所有者的最高优先级。我认为这将提供有价值的输入错误的产品负责人,他们相信项目将提供最高的价值。

2)我们有每周待办事项列表的时间。通常我们只是谈论任何新的bug添加简单的评论。典型的时间是非常低效的随意交谈。有时我们会进一步进入机票、调试或团队编程解决方案。我要建议我们总是最大化通过审查所有新的bug,然后共同致力于一个或两个。我怀疑这将有额外的好处为团队成员创造一个机会向别人学习项目知识和开发方式。

谢谢你的反馈和额外的观点在这个主意!