显然我们使用Scrum开发方法。通常是这样的：
开发人员试图完成他们的任务。通常，任务需要完成大部分sprint。 QA讨厌Dev发布他们可以测试的内容，Dev在sprint结束前一两天将Qam的一些错误代码抛出到QA，并花费其余的时间修复QA发现的bug。 QA永远无法按时完成任务，冲刺很少能按时发布，而Sp和QA在冲刺结束时几天都很糟糕。
当可释放的Dev任务占用大部分冲刺时，scrum应该如何工作？
感谢大家参与讨论。由于这是一个相当开放的问题，似乎没有一个“答案” - 下面有很多好的建议。我将尝试总结一些“带回家”的观点，并做出一些澄清。
（顺便说一句 - 这是放置这个的最好的地方还是我应该把它放在'回答'？）
值得思考/采取行动：
答案 0 :(得分：40)
我的意见是你有一个估计问题。似乎缺少测试每个功能的时间，并且在规划sprint时仅考虑构建部件。
我不是说这是一个容易解决的问题，因为它比任何事情都更常见。但可能有用的事情是：
将QA视为开发团队的成员，并将其纳入sprint计划并进行更密切的估算。
'可释放的开发任务'不应该占用大部分冲刺。完整的工作功能应该。尝试收集有关每种任务的开发时间与QA时间的指标，并在估计未来冲刺时使用这些指标。
您可能需要查看待办事项，看看是否有非常粗糙的功能。尝试将它们分成可以轻松估算和测试的较小任务。
总之，您的团队似乎还没有找到真正的速度，因为在进行sprint的估算和规划时，有些任务没有被考虑。
但最终，估算不准确是一个棘手的项目管理问题，您可以在基于敏捷或基于瀑布的项目中找到它。祝你好运。
答案 1 :(得分：35)
这里的派对有点晚了，但这是基于你所写的内容。
现在，Scrum是一种项目管理方法，而不是开发方法。但在我看来，关键是要有适当的发展过程。没有一个，你花费大部分时间做出反应而不是建设。
我是测试第一的人。在我的开发过程中，我首先构建测试以强制执行需求和设计决策。 您的团队如何执行这些操作？我想在这里提出的观点是，你根本无法“把东西扔到篱笆上”并期待任何事情，但不会发生。这种失败要么是由测试团队进行的（通过不是很好地测试，从而让问题漏掉），要么是由开发人员（通过不构建解决问题的产品）。我不是说你必须首先编写测试 - 我不是激进分子或测试优先的传播者 - 但我说你必须有一个流程到位当你到达迭代结束时，生成质量，测试，准备生产的代码。
我在死亡螺旋方法这种开发方法中一直正确。我在这样的模型中为政府（美国）建立了多年的软件。它不能很好地工作，它花费了很多钱，它产生了晚期的代码，糟糕的代码，并没有为士气做任何事情。当你花费所有时间修复你本可以避免的错误时，你无法取得任何进展。我完全被这件事打败了。
您不希望QA发现您的问题。你想让他们失业，真的。我的目标是让QA大吃一惊，因为一切正常。当然，这是一个目标。在实践中，他们会找到东西。我不是超级人类。我犯了错误。
回到安排......
在我目前的工作中，我们做Scrum，我们只是不称之为。我们不是这里的标签，但我们正按时生产高质量的代码。每个人都在船上。我们告诉QA我们准备好测试什么以及什么时候测试。如果他们提前两周来敲门，他们就可以说话了。每个人都知道时间表，每个人都知道发布中会有什么，每个人都知道产品必须像宣传之前一样工作才能进入QA。那是什么意思呢？你告诉QA“不要打扰测试XYZ - 它已经坏了，在发布C之前不会修复”，如果他们进行测试，你会将它们指回到那个声明并告诉他们不要浪费你的时间。苛刻，也许，但有时是必要的。我不是要粗鲁，但每个人都需要知道“规则”，应该测试什么以及什么是“已知问题”。
您的管理层必须在船上。如果他们不是你会遇到麻烦。 QA无法运行该节目，开发组也无法完全运行它。所有组（即使这些组只是每组一个人或戴着几顶帽子的人）都需要在同一页面上：客户，测试团队，开发人员，管理人员和其他任何人。通常，一半以上的战斗都是沟通。
也许你在冲刺期间所做的事情远不止于此。情况可能就是这样。你为什么这样做？要满足时间表？如果是这样，那就是管理层需要介入并解决问题的地方。如果您要提供QA错误代码，请期待他们将其丢回。最好给他们3件有用的东西，而不是8件未完成的东西。目标是生成一些在每次迭代时完全实现的功能集，而不是将一堆半完成的东西放在一起。
我希望这是收到的，因为它是 - 作为一种鼓励而不是咆哮。就像我提到的那样，我一直在你身边，这并不好玩。但是有希望。你可以在冲刺中扭转局面，也许两个。也许您不会在下一个sprint中添加任何新功能，只需修复损坏的内容即可。你必须作为一个团队来决定。
另一个用于编写测试代码的小插件：自从采用“先编写测试”方法以来，我发现自己对自己的产品更加轻松自信。当我的所有测试都通过时，我有一定程度的信心，如果没有它们，我就无法拥有它。
祝你好运！
答案 2 :(得分：14)
在我看来，在需要QA功能测试的场景中存在资源分配问题，以便在sprint中“完成”给定功能。在我迄今为止发现的任何QA相关的scrum讨论中似乎没有人解决这个问题，这里的原始问题几乎是相同的（至少是相关的），所以我想提供一个部分答案并稍微扩展一下这个问题。
关于完全冲刺的开发任务的具体原始问题 - 如果QA的功能测试是您对'完成'的定义的一部分，那么放宽这些任务的一般建议似乎是有意义的。假设让我们说4周冲刺，如果需要大约一周的时间来测试来自多个开发人员的多个功能，那么看起来开发任务需要大约3周，然后是大约1周的测试任务延迟一周就是答案。 QA当然会尽快开始我们认识到，从最后一组交付的功能中，将会有大约一周的延迟。我意识到我们希望尽快获得QA的功能，因此您不会在sprint中拥有这种类似瀑布的场景，但实际情况是开发通常无法实现真正的，有价值的QA功能，直到1到3周之后冲刺。当然，这里和那里都有点点滴滴，但大部分工作是2-3周的开发，然后大约一周的测试剩余。
所以这里是资源分配问题，我对问题的扩展 - 在上面的场景中QA有时间测试sprint的计划功能（3周的开发任务，留下最后一周用于测试交付的功能）持续）。另外，让我们假设QA在开发一周后开始获得一些可测试的功能 - 但QA的第一周是什么，以及第四周的开发是什么？
如果QA功能测试是sprint中某个功能的'done'定义的一部分，那么这种低效率似乎是不可避免的。 QA将在第1周期间基本闲置，并且在第4周期间开发将基本闲置。当然，有些事情自然会填补这些时间，例如错误修复和验证，设计/计划等，但我们基本上以75％的容量来策划我们的资源。
显而易见的答案似乎是发展和质量保证的重叠冲刺，因为现实是质量保证总是在一定程度上落后于发展。产品所有者和其他人的演示将遵循QA冲刺，因为我们希望在显示之前测试功能。这似乎可以更有效地利用开发和QA，因为我们没有浪费太多时间。假设我们想让开发人员继续开发和测试测试，我看不到更好的实用解决方案。也许我错过了一些东西，我希望有人可以为我揭示这一点 - 否则看起来这种僵硬的scrum方法是有缺陷的。感谢。
答案 3 :(得分：12)
希望你通过在每个sprint中处理更少的开发任务来解决这个问题。这引出了一些问题：谁设定了开发人员的目标？为什么Dev一直没有达到这些目标？
如果开发者没有设定自己的目标，那就是他们总是迟到的原因。这不是练习Scrum的理想方式。这只是增量开发，具有大的，截止日期驱动的可交付成果，并且开发人员没有实际的利益相关者责任。
如果开发人员因为不了解而无法设定自己的目标，那么他们必须更多地参与其中。
Scrum取决于Agile Manifesto中列出的四个基本原则。
交互很重要 - 这意味着开发，质量保证，项目管理和最终用户需要更多地交谈并相互交谈。软件是用计算机的神秘语言编码知识的过程。要对知识进行编码，开发人员必须具备相关知识。 [为什么你认为我们把它称为“代码”？] Scrum不是“写规范 - 抛出横向”方法。这是ANTI-“写规范 - 抛出横梁”
工作软件至关重要 - 这意味着每件作品都必须导致正在运行版本。没有一套错误修复QA来解决，但工作软件。
客户协作 - 这意味着开发人员必须与业务分析师，最终用户，业务所有者以及能够帮助他们了解他们正在构建的内容的每个人合作。最后期限与下一件交给客户的事情无关。如果客户需要X，那么每个人都可以做到最优先考虑。如果项目计划说构建Y，那就是malarkey的负载。
响应变化 - 这意味着客户可以重新安排以下冲刺的优先级。他们无法在进程中重新安排冲刺（这很疯狂）但是所有以下冲刺都是改变优先级的候选者。
如果客户开车，则截止日期变得不那么人为“项目里程碑”，而且“我们首先需要X，然后是Y，而Z部分中的这个东西，我们不再需要它了。现在我们有了W ，Z是多余的。“
答案 4 :(得分：10)
Scrum规则指出，所有Sprint项目都需要在Sprint结束时进行“全面测试，可能实现的功能”才能被视为完成。 Sprint总是按时结束，并且团队没有得到信任，并且不允许在Sprint评论中提供任何未完成的内容 - 包括QA。
从技术上讲，这就是你应该需要的。一个团队承诺一定数量的工作，最终在Sprint结束前两天进入QA并且QA没有及时完成。所以Sprint的输出是零，他们必须走在客户面前，并承认他们没有任何东西可以展示一个月的工作。
下一次，你会打赌他们会选择更少的工作，并找出如何让它到QA，以便它能够按时完成。
答案 5 :(得分：6)
作为一名从事敏捷项目工作2。5年的QA，这是一个非常棘手的问题，我仍然没有得到所有答案。
我作为＆＃34;三胞胎＆＃34;的一部分工作。 （两个开发人员配对计划+一个质量保证），我参与了在两周迭代开始时计划会议的故事和估算。正如上面提到的adrianh一样，QAs必须在最初的sprint计划中听到他们的声音。这可能很难，特别是如果你与具有非常强烈个性的开发人员合作，但QAs必须在真正意义上的主张（即不具有侵略性或有力，但尊重地寻求理解真理/ PO和开发人员/技术专家同时使自己理解）。我主张在计划鼓励测试驱动的心态时首先制定质量保证任务 - 质量保证可能必须真正地将自己推进以实现这一目标。与有多少人认为软件开发有效但由于多种原因支付红利相反;
QA被听到并且没有被降级为被问及＆＃34;所以你打算怎么测试？＆＃34;在Devs说出他们的作品（瀑布心态）之后。
它允许QA提出测试的想法，同时检查验收标准的可测试性，同时存在真理/ PO（我确实说他们必须出现在规划会议中＃39; t I ?!）填补理解上的空白。
它为测试驱动的方法提供了基础 - 在发布测试方法并负责任务后，Devs可以考虑如何生成代码以通过这些测试。
如果步骤1 - 3是您在迭代的其余部分中唯一的TDD活动，那么您仍然比第一篇文章中Steve所假设的情景好一百万倍; ＆＃34;开发人员试图完成他们的任务。通常，任务需要完成大部分sprint。 QA讨厌Dev发布他们可以测试的内容，Dev在sprint结束前一两天将一些错误的代码抛给QA，并花费其余的时间修复QA发现的错误＆＃34;
毋庸置疑，这可以为QA提供一些警告;
他们必须准备好让Devs and Truth / PO挑战他们的测试想法并达成妥协; ＆＃34; QA警察＆＃34;态度不会在敏捷团队中洗漱。
质量保证任务必须达到难以平衡，既不太详细也不太通用（任务可写在卡片上以便放在散热器板上＃34;并在每日站立会议上讨论 - 他们需要从＆＃34;正在进行＆＃34;到＃34;完成＆＃34;在迭代期间）。
QAs需要为规划/评估会议做准备。不要只是为了看不见的用户故事，不要只是出现在头顶并制作测试方法！开发人员似乎能够做到这一点，因为他们的任务往往更明确 - 例如＆＃34;将x模块更改为与z组件接口＆＃34;或＆＃34;重构方法＆＃34;。作为QA，您需要熟悉计划之前引入/更改的功能，以便了解测试范围以及可能适用的测试设计技术。
自动化测试几乎是必不可少的，并将这些写入和＃34;失败＆＃34;在迭代的前两三天内，或者至少与开发人员准备好代码时共同进行。然后，您可以运行test / s并查看它们是否按预期通过（正确的QA TDD）。这就是你在迭代结束时避开迷你瀑布的方法。您应该在开始编码之前或开始编码时向Devs演示测试，以便他们知道目标是什么。
我说4是＆＃34;几乎是必不可少的＆＃34;因为有时可以通过预期行为的手动清单（我敢说脚本！）成功实现同样的目标 - 关键是提前与Devs分享;跟他们说话！
关于上述关于任务主题的第2点，我尝试创建粒度为1/2小时到2小时的任务，每个任务对应于可证明的工作，例如： ＆＃34;将错误密码的检查添加到自动测试 - 2小时＆＃34;。虽然这有助于我组织我的工作，但是其他团队成员一直批评它过于详细，并且对我的立场产生影响，要么将多个任务从前一天完成，要么完全不能移动任何任务，因为我还没有进入他们。人们真的希望在每日站立时看到稳定的进步感，因此在半天或一天的时间内创建任务更有帮助（但你可能会保留自己的＆＃34;微任务列表＆＃34;完成你用于在站立时传达整体进展的更大任务。
关于上述第4点和第5点;您提前准备的自动化测试或手动检查清单应该只涵盖快乐路径或关键验收标准。一旦这些通过，你可以计划一个额外的任务进行最后一轮的探索性测试＆＃34;在迭代结束时检查边缘情况。 Devs在那段时间所做的事情是有问题的，因为就他们而言，他们是＆＃34;代码完整＆＃34;除非你找到一个bug。一些敏捷从业者提倡首先考虑边缘案例，尽管这也可能有问题，因为如果你没时间用完，你可能无法保证已经提供了验收标准。这是一个非常平衡的决策之一，取决于用户故事的背景和您作为QA的经验！
正如我在开始时所说的那样，我仍然没有得到所有的答案，但希望上面的内容提供了一些经验丰富的指针！
答案 6 :(得分：4)
在发布到QA之前，听起来您的开发团队可能没有对自己进行足够的测试。如果你的所有单元测试都通过了，QA周期应该相对平稳，不是吗？他们会发现一些集成错误，但不应该有很多这样的错误，对吧？
答案 7 :(得分：4)
我认为这里有几个问题。首先，我认为开发人员的任务可能不是很好，或者估计不好，或者两者都不是。 Scrum中sprint的全部目的是能够在sprint结束时演示可行的代码。我提到的两个问题都可能导致错误的代码。
如果开发人员在sprint结束时发布了错误代码，我也会看一下：
我过去听过的一个想法是使用QA人作为scrummaster。他们将出席每日站立，并了解开发人员的工作场所。他们可以解决PO的问题（假设PO可以充分地完成他们的工作）。
我不禁觉得你需要QA和你的scrum团队之间更多的合作。听起来测试只发生在最后，这是一个问题。让QA成为团队的一员将有助于识别可以更早，更好地测试的内容。
我也觉得您对产品所有者有疑问。他们必须在那里确保每个人都在朝着正确的方向前进。他们应该确保不仅在质量保证和开发者之间，而且在开发者之间进行良好的合作。
答案 8 :(得分：4)
“当可释放的Dev时，scrum应该如何工作？ 任务占据了sprint的大部分时间？“
正如你发现的那样 - 它的效果不是很好:-)你所描述的过程对我来说听起来不像Scrum - 或者至少不像Scrum做得好。
我不确定你所描述的QA人是否是团队的一部分 - 或者是一个单独的团体。
如果他们是一个单独的小组，那么这可能是问题的一个重要部分。他们不参与团队完成任务的承诺 - 以及与产品所有者的相关范围协商。如果没有他们在团队中的QA技能，我从未见过敏捷团队成功。通过让开发人员具备大量测试/ QA技能 - 或者让团队中有一个或三个嵌入式QA人员。
如果团队 ，那么他们需要在最初的sprint计划中更多地听到他们的声音。到目前为止，产品所有者和团队应该清楚您过度使用。
如果是我，我会尝试一些事情：
您可能还会发现这些tips about smoothing down a scrum burndown很有用。
答案 9 :(得分：4)
我们解决了这个问题如下： - 产品待办事项中的每个项目都必须符合适用标准或验收标准， 没有那些，我们不会开始冲刺 - 测试人员是我们团队的一部分，对于每个产品积压项目，他创建测试任务（一个或多个，基于验收标准）以及估计，以及要测试的项目的链接 - 在每日Scrum期间，完成的所有任务都放在“To Test”列中 - 我们从不做超过16小时的任务;估计更长的任务被拆分
答案 10 :(得分：3)
将任务拆分为较小的任务。
此外，QA可以为Dev创建测试用例以进行测试。
答案 11 :(得分：2)
要考虑的一个想法是让QA在主要开发之后进行一次迭代。这在我们的环境中运作良好。
答案 12 :(得分：0)
在这里我要说的是，一种尺寸并不适合所有人。每个团队以不同方式处理QA。这在很大程度上取决于您正在进行的项目，无论是小型还是大型项目。它是否需要广泛的回归，用户接受和探索性测试，或者您需要测试的场景很少。 让我重申，在敏捷中，通才是专家的首选。那是什么？因为在项目期间有时间你没有任何东西需要测试，所以当时你可能正在做其他事情。即使你是一个核心程序员，你也可能正在进行测试。
我们如何处理？ 我们定期进行为期2周的冲刺。在本周开发人员完成任务一周后开始测试。现在测试人员不断向我们的问题跟踪器添加问题，完成他们的sprint任务的开发人员开始挑选这些错误。在sprint结束时，我们主要完成了sprint任务以及所有关键和主要错误。
那么在短跑的第一周，测试人员2会怎样？
嗯，总有一些东西需要测试。我们在积压中有测试任务，可能包括一些探索性测试。许多人不重视探索性测试，但这对于构建优质产品极为重要。优秀的测试人员为自己创造任务，找到出错的可能性并对其进行测试。
希望有所帮助！