显然，我们使用Scrum开发方法。通常是这样的：

开发人员四处奔波，试图完成他们的任务。通常，任务需要大部分的冲刺来完成。质量检查人员(QA)困扰开发人员(Dev)释放他们可以测试的东西，开发人员(Dev)最终在sprint结束前一两天向质量检查人员(QA)投放了一些错误代码，并花费其余时间修复质量检查人员(QA)发现的错误。质量检查人员永远无法按时完成任务，冲刺活动几乎无法按时发布，而开发人员和质量检查人员在冲刺活动结束时的日子很悲惨。

当可释放的Dev任务占据大部分冲刺时，scrum应该如何工作？

谢谢大家在讨论中的贡献。由于这是一个开放式的问题，因此似乎没有一个"答案"，下面有很多不错的建议。我将尝试总结一些"要点"并做出一些澄清。

(顺便说一句，这是放置此内容的最佳位置还是我应该将其放入"答案"？)

思考/采取行动的要点：

• 需要确保开发人员的任务尽可能小(粒度)。
• 冲刺长度应根据平均任务长度适当地确定(例如，具有1周任务的冲刺时间至少应为4周)
• 团队(包括质量检查人员)需要努力提高估算的准确性。
• 考虑并行执行单独的质量检查冲刺，但如果对团队最有效，则可以抵消
• 单元测试！

解决方案

将任务拆分为较小的任务。

同样，QA可以创建测试用例以供开发人员进行测试。

希望我们通过解决每个sprint中更少的开发任务来解决此问题。这就引出了一个问题：谁来设定开发人员的目标？开发人员为何始终未能实现这些目标？

如果开发人员没有设定自己的目标，那就是为什么他们总是迟到。那不是实践Scrum的理想方法。那只是增量开发，包含按时限驱动的大型交付项目，而开发人员则无利益相关方的实际责任。

如果开发人员由于对知识的了解不够而无法设定自己的目标，那么他们必须更加积极地参与进来。

Scrum依赖于《敏捷宣言》中概述的四个基本原则。

• 交互很重要-这意味着开发人员，质量保证，项目管理和最终用户需要更多地交谈和彼此交谈。软件是使用计算机的奥秘语言对知识进行编码的过程。要编码知识，开发人员必须拥有知识。 [我们为什么认为我们称其为"代码"？] Scrum不是"写规范-跨尾翻译"方法。这是ANTI-"编写规范-抛尾板"
• 正常工作的软件很重要-这意味着每个开发人员都需要付出一定的努力才能发布有效的版本。不是质量检查所要解决的一组错误修复程序，而是可以运行的软件。
• 客户协作-这意味着开发人员必须与业务分析师，最终用户，业务所有者以及可以帮助他们了解自己所构建内容的所有人进行合作。截止日期与移交给客户的事情无关紧要。如果客户需要X，则这是每个人要做的最高优先事项。如果项目计划说的是Y号建造，那就太累了。
• 响应变更-这意味着客户可以重新安排以下冲刺的优先级。他们无法重新安排进行中的sprint(这很疯狂)，但以下所有sprint都是更改优先级的候选对象。

如果客户开车，那么截止日期将变得不再是人为的"项目里程碑"，而更多的是"我们首先需要X，然后是Y，而Z部分中的东西不再需要。现在有了W，Z多余的。"

我的意见是我们有一个估计问题。似乎缺少测试每个功能的时间，并且在计划sprint时仅考虑构建部件。

我并不是说这是一个容易解决的问题，因为它比任何东西都更普遍。但是可能有帮助的是：

• 将质量检查人员视为开发团队的成员，并将其包括在冲刺计划中，并进行更紧密的估算。
• "可释放的开发任务"不应占用大部分的冲刺时间。完整的工作功能应。尝试收集有关每种任务的开发时间与质量检查时间的指标，并在估算未来的冲刺时使用这些指标。
• 我们可能需要查看待办事项，以查看是否具有非常粗糙的功能。尝试将它们划分为一些较小的任务，这些任务可以轻松估算和测试。

总而言之，团队似乎尚未发现其实际速度，因为在进行冲刺的估算和计划时，某些任务并未考虑在内。

但最后，估计不准确是我们在基于敏捷或者基于瀑布的项目中发现的一个棘手的项目管理问题。祝你好运。

听起来开发团队在发布质量检查之前可能没有自己进行足够的测试。如果我们所有的单元测试都通过了，那么质量检查周期应该相对平稳，不是吗？他们会发现一些集成错误，但其中应该没有太多，对吧？

我认为这里有几个问题。首先，我认为开发人员的任务可能不够细粒度，或者估计得不好，或者两者兼而有之。 Scrum中sprint的全部目的是能够在sprint的最后演示可行的代码。我提到的两个问题都可能导致错误的代码。

如果开发人员在sprint即将发布时发布了错误代码，我还将关注：

• 产品所有者是否真的要求开发人员对完成任务负责？这就是采购订单的工作，如果没有发生，那么开发人员就会懈怠。
• 开发人员是否在使用任何种类的TDD。如果没有，那可能会帮助很大。使开发人员养成测试其代码的习惯。我们在工作时遇到了这个问题，我们的团队专注于在重要领域中进行TDD，因此我们以后不必再由其他人来做
• 任务/用户故事是否过于笼统？任务分解中的摆动空间将导致开发人员草率。同样，这在某种程度上是一个PO问题。

我过去听到的一个想法是使用QA人员担任Scrummaster。他们将出席日常站立会议，并可以了解开发人员的状况。他们可以解决PO的问题(假设PO可以充分发挥作用)。

我不禁感到，我们需要质量保证和Scrum团队之间的更多合作。听起来测试仅在最后进行，这是一个问题。将QA纳入团队将有助于确定可以更早更好地进行测试的事物。

我也觉得我们对产品负责人有疑问。他们必须在那里确保每个人都在朝着正确的方向前进。他们应该确保不仅在质量检查人员和开发人员之间，而且在开发人员本身之间也存在良好的合作。

要考虑的一个想法是让质量保证工作在主要开发工作之后进行一次迭代。在我们的环境中效果很好。

参加聚会的时间有点晚，但这是我根据我们所写内容所采取的措施。

现在，Scrum是一种项目管理方法，而不是开发方法。但是，我认为关键是要有适当的开发流程。没有一个人，我们将花费大部分时间进行反应，而不是进行建设。

我是考试第一人。在开发过程中，我首先构建测试以执行需求和设计决策。团队如何执行这些任务？我要在这里说明的要点是，我们根本无法"将东西扔在篱笆上"，并且期望除了失败之外什么都不会发生。失败将由测试团队(通过不很好的测试，从而使问题溜走)或者由开发人员(通过不构建解决问题的产品)实现。我并不是说我们必须先编写测试，我不是好战分子或者测试先行者，但我是说我们必须具备适当的流程，才能在达到目标时就生成高质量的，经过测试的，可立即生产的代码迭代结束。

在我们称之为"死亡螺旋方法"的这种开发方法论中，我一直是对的。我以这种模式为政府(美国)开发软件多年。它不能很好地工作，要花费很多钱，它会产生较晚的代码，较差的代码，并且没有任何士气。当我们花费所有时间来修复原本可以避免的错误时，我们将无法取得任何进展。我绝对被这件事打倒了。

我们不希望质量检查发现问题。我们确实要使它们停止工作。我的目标是让质量检查员大吃一惊，因为一切都可以正常进行。当然，这是一个目标。在实践中，他们会找到东西。我不是超人。我犯错了。

返回计划...

在我目前的工作中，我们做Scrum，我们只是不这么称呼。我们这里没有标签，但是我们会准时生产高质量的代码。每个人都在机上。我们告诉质量检查人员我们将要准备什么以及何时进行测试。如果他们提早两周来敲门，他们可以和他说话。每个人都知道时间表，每个人都知道发行版中的内容，每个人都知道产品必须经过广告宣传才能进行质量检查。那是什么意思呢？我们告诉质量检查人员"不要麻烦测试XYZ，它不会被破坏，直到发布C才会被修复"，如果他们进行测试，则将它们指向该语句，并告诉他们不要浪费时间。严厉，也许，但有时是必要的。我并不是在无礼，但是每个人都需要知道"规则"，应该测试什么，什么是"已知问题"。

管理层必须任职。如果不是，我们将遇到麻烦。质量检查无法运行该节目，而开发人员小组也无法完全运行该节目。所有组(即使这些组每个组只有一个人或者戴着几个帽子的人)也必须位于同一页面上：客户，测试团队，开发人员，管理人员以及其他任何人。通常，一半以上的战斗是交流。

也许我们在冲刺期间所能完成的工作比其他人要多得多。可能是这种情况。你为什么要那样做？满足时间表？如果是这样，那就是管理层需要介入并解决问题的地方。如果我们要提供质量检查错误代码，请期待他们将其扔回去。最好给他们3件事，而不是8未完成的事情。目标是产生一些在每次迭代中完全实现的功能，而不是将一堆半成品混在一起。

我希望收到此消息是因为它是一种鼓励而不是怒。就像我提到的那样，我去过你那里，很不好玩。但是有希望。我们可以一次冲刺，甚至两次冲刺。也许我们不需要在下一个sprint中添加任何新功能，而只需修复已损坏的内容即可。我们必须作为一个团队来决定。

还有一个用于编写测试代码的小插件：自从采用"先编写测试"方法以来，我对自己的产品更加放松，也更加自信。当我所有的测试通过时，我就会有信心，如果没有它们，我简直无法拥有。

祝你好运！

"How is scrum supposed to work when releasable Dev 
  tasks take up most of the sprint?"

正如我们所发现的那样，它并不十分有效：-)对我来说，我们所描述的过程听起来并不像Scrum，或者至少不像Scrum做得很好。

从我们所描述的内容中，我无法确定QA人员是团队的一部分还是独立的团队。

如果他们是一个单独的小组，那么这可能是问题的很大一部分。他们将不会参与团队对完成任务的承诺以及与产品所有者的相关范围协商。如果没有敏捷团队的QA技能，我从未见过他们能取得成功。通过让开发人员具有大量测试/ QA技能，或者通过在团队中拥有一到三名嵌入式QA人员来解决问题。

如果他们在团队中，那么他们需要在初始sprint计划中获得更多的声音。到目前为止，对于产品负责人和团队来说，我们应该过度投入。

如果是我，我会尝试一些方法：

• 如果团队尚不存在，则请他们进行质量检查/测试人员
• 与产品负责人和团队进行了长时间的交谈，讨论什么才算是"完成"。听起来有些开发人员仍处于"移交给质量检查"的预乱式思维中。
• 将故事分成较小的部分-可以更轻松地发现估计错误
• 考虑运行较短的sprint-因为很少而且更多的频率更易于跟踪和学习。

我们可能还会发现有关平滑Scrum烧毁的这些技巧很有用。

在我看来，在要求QA功能测试以使给定功能在sprint中"完成"的情况下，存在资源分配问题。到目前为止，在我发现的任何与质量检查相关的Scrum讨论中似乎都没有人解决这个问题，这里的原始问题几乎是相同的(至少是相关的)，因此我想提供部分答案并扩大问题范围。

至于有关开发任务全面展开的特定原始问题，如果QA的功能测试是我们"完成"的定义的一部分，那么放松这些任务的一般建议似乎是有道理的。给定一个4周的冲刺，如果要花大约一个星期来测试来自多个开发人员的多个功能，那么似乎开发任务要花大约3周，然后是测试任务的滞后一周，要花大约1周才是答案。我们一定会尽快开始质量检查，因为我们认识到从交付的最后一组功能来看，会有大约一周的延迟。我意识到我们希望尽快进行质量检查，因此我们不会在冲刺中遇到这种瀑布般的情况，但现实情况是，开发通常要到1到3周后才能真正实现，值得向质量检查交付功能冲刺。当然到处都是零零碎碎的工作，但大部分工作是2-3周的开发工作，然后剩下大约一周的测试工作。

因此，这就是资源分配问题，在上述情况QA中，我对该问题的扩展有时间来测试sprint的计划功能(价值3周的开发任务，最后一周用于测试最后交付的功能)。还假设质量保证在开发1周后开始获得一些可测试的功能，但是质量保证的第1周和开发的第4周又如何呢？

如果QA功能测试是sprint中某个功能"完成"定义的一部分，那么这种低效率似乎是不可避免的。在第1周期间，质量检查在很大程度上将处于闲置状态，在第4周期间，开发将处于很大程度上处于空闲状态。当然，有些事情自然会在这个时候填补，例如错误修复和验证，设计/计划等，但是我们实质上是在以75％的容量来安排我们的资源。

显而易见的答案似乎是将开发和QA的冲刺重叠在一起，因为事实是QA总是在一定程度上滞后于开发。 QA冲刺将向产品负责人和其他人进行演示，因为我们希望在展示功能之前先对其进行测试。这似乎可以更有效地利用开发和质量检查，因为我们没有浪费太多时间。假设我们要让开发人员继续进行开发和测试人员测试，我看不到更好的实用解决方案。也许我错过了一些事情，希望我能为我提供一些启示，否则似乎这种僵化的Scrum方法是有缺陷的。谢谢。

Scrum规则说，在Sprint的末尾，所有Sprint项都必须经过"充分测试，可能实现的功能"才能被视为完整。 Sprint总是按时结束，并且团队无法获得信誉，也无法在Sprint审查中提供任何不完整的内容，包括质量检查。

从技术上讲，这就是我们所需要的。团队致力于一定数量的工作，最后在Sprint结束的前两天将其提交给质量检查人员，并且质量检查没有及时完成。因此，Sprint的输出为零，因此他们必须走在客户面前，并承认一个月的工作无可奉告。

下一轮，我们会打赌他们将减少工作量，并弄清楚如何进行质量检查，以便按时完成。

我们解决了以下问题：
产品待办事项中的每个项目都必须具有适合标准或者接受条件，
没有这些，我们就不会开始冲刺
测试人员是我们团队的一部分，对于每个积压的产品，他都会创建测试任务(基于验收标准，一项或者多项)，估算值以及指向要测试的项目的链接
在日常Scrum期间，所有完成的任务都放在"要测试"列中
我们绝不会执行超过16个小时的任务；估计更长的任务被拆分