显然，我们使用Scrum开发方法。它通常是这样的：
开发人员试图完成他们的任务。通常，任务需要大部分时间才能完成。QA团队催促开发人员发布一些可以测试的内容，开发人员最终在冲刺结束前的一两天发布了一些有缺陷的代码，然后花费其余时间修复QA团队发现的错误。QA团队永远无法按时完成任务，冲刺很少能按时发布可发布版本，开发和QA团队在冲刺结束前几天都过得很痛苦。
当可发布的开发任务占据大部分冲刺时间时，Scrum应该如何运作？
感谢大家参与讨论。由于这是一个比较开放的问题，似乎没有一个“答案” - 在下面有许多好的建议。我将尝试总结一些“要点”并进行一些澄清。
（顺便问一句 - 这是放置此类内容的最佳位置吗，还是应该放在“回答”中？）
值得思考/采取行动的要点：
我的意见是你们存在一个估算问题。似乎在规划冲刺时只考虑了构建部分而忽略了每个功能测试所需的时间。
我并不是说这是一个容易解决的问题，因为它比任何事情都更普遍。但可以帮助的事情包括：
将QA团队成员视为开发团队的一部分，并在冲刺计划和估算中更密切地包含他们。
“可发布的开发任务”不应占据大部分冲刺时间。应该完成工作功能。尝试收集有关每种任务的开发时间与测试时间的指标，并在估算未来冲刺时使用这些指标。
可能需要审查待办事项清单，看看是否存在非常粗糙的功能特性。尝试将其细分为易于估算和测试的较小任务。
总之，由于在估算和规划冲刺时存在未考虑的任务，因此你们的团队似乎还没有找到其真正的速度。
但最终，估算不准确是敏捷或瀑布项目中遇到的严峻的项目管理问题。祝你好运。
有点晚来参加这个聚会，但根据你的描述，这是我的看法。
现在，Scrum 是一个项目管理方法，不是一个开发方法。但我认为，建立开发流程非常重要。 如果没有流程，你会花费大部分的时间应对问题而不是构建产品。
我是一个测试驱动开发的支持者。在我的开发流程中，我首先编写测试以强制执行需求和设计决策。 你们的团队是如何实施这些要求的呢？ 我想说的是，你不能仅仅“把东西扔过去”并期望成功。 这种失败可能是由测试团队（未能很好地测试，从而让问题溜走）或由开发人员（未建造解决问题的产品）引起。 我并不是说你必须先编写测试 - 我不是一个狂热者或者测试驱动开发的鼓吹者 - 但我想说的是，在达到迭代结束时，你必须拥有一套生产质量、经过测试的、可以直接使用的代码流程。
我曾经处于你现在所处的状态，这种开发方法我称之为死亡螺旋法则。我曾经在美国政府为多年使用这种模型构建软件。 这种方法不好用，花费大量的金钱，产生延迟的代码、低质量的代码，对士气没有任何帮助。 当你花费所有时间纠正本可以一开始就避免的错误时，你无法取得任何进展。 我被这个过程彻底打败了。
你不想让 QA 发现你的问题。 你真的想让他们失业。我的目标是让 QA 大吃一惊，因为一切都正常工作。当然，这只是一个目标。实际上，他们还是会发现问题的。我不是超人，我也会犯错。
回到日程安排...
我现在的工作采用Scrum方法，但我们不这样称呼它。我们不注重标签，但我们注重按时生成高质量的代码。所有人都明白该做什么。我们会告诉QA何时测试我们准备好的内容。如果他们提前两周来要求测试，我们将拒绝。每个人都了解时间表，每个人都知道发布中将包含哪些内容，并且每个人都知道产品必须像广告宣传的那样正常工作才能交给QA进行测试。所以这意味着什么？你告诉QA“不要测XYZ - 它是坏的，直到发布C才会修复”，如果他们去测试，你可以指向这个声明并告诉他们不要浪费你的时间。有时可能有些严厉，但有时候是必要的。我不是想粗鲁，但所有人都需要知道“规则”，什么应该被测试和什么是“已知问题”。
你的管理层必须同意。如果他们不同意，你会遇到麻烦。QA不能主导，开发组也不能完全主导。所有小组(即使这些小组只有一个人或一个同时扮演多个角色的人)都需要在同一页上：客户、测试团队、开发人员、管理层和其他人。常常，沟通是超过一半的战斗。
也许你在一个迭代中尝试了太多，这可能是原因。为什么会这样？为了满足时间表吗？如果是这样，管理层需要介入解决问题。如果你给QA有问题的代码，他们会把它扔回来。最好给他们三个可以运行的东西而不是八个没完成的东西。目标是在每个迭代中生成完全实现的某些功能，而不是随意拼凑一堆未完成的东西。
我希望这篇文章被理解为一种鼓励而不是抱怨。就像我提到的，我曾经也处于你所处的位置，那并不好玩。但是还有希望。你可以在一个或两个迭代中扭转局面。也许你下一个迭代不会添加任何新功能，只是修复问题。这需要团队决定。
再提一下撰写测试代码的好处：自从采用“先编写测试然后编写代码”的方法后，我发现自己更加放松和自信地开发产品。当所有测试都通过时，我拥有一种信心，如果没有测试则无法达到。
祝您好运！
在需要进行QA功能测试以完成给定特性的情况下，我认为存在资源分配问题。到目前为止，我在任何与QA相关的Scrum讨论中都没有看到有人解决这个问题，而这里的原始问题几乎相同（至少相关），因此我想提供一个部分答案并扩展一下问题。
至于关于开发任务占用整个Sprint的具体原始问题-如果QA的功能测试是您定义“完成”的一部分，则似乎缓解这些任务的一般建议是有道理的。假设一个4周的Sprint，如果需要测试来自多个开发人员的多个特性大约需要一周时间，那么开发任务大约需要3周时间，然后是大约1周的测试任务。当然，QA会尽快开始，但我们意识到从上一组交付的特性中，将会有大约一周的滞后期。我意识到我们希望尽快将特性交付给QA，以便在Sprint中不出现类似瀑布式的情况，但现实情况是，在Sprint的1到3周内，开发通常无法将真正有价值的交付功能交付给QA。当然，这里有零散的部分，但大部分工作是2-3周的开发，然后剩下大约一周的测试。
所以这里就是资源分配问题，以及我对问题的扩展 - 在上述情况下，QA有时间测试一个sprint的计划功能（3周的开发任务，留下最后一周来测试上次交付的功能）。还假设在开发1周后QA开始获取一些可测试的功能 - 但是对于QA的第1周和对于开发的第4周呢？他们必须准备好接受开发人员、产品负责人的测试想法挑战，并达成妥协；在敏捷团队中，“QA警察”的态度行不通。
QA任务必须取得一个艰难的平衡，既不能太详细也不能太泛泛（任务可以写在卡片上放在“散热器板”上，在每日站立会议上进行讨论——它们需要在迭代期间从“正在进行”移动到“已完成”）。
QA需要为计划/估算会议做好准备。不要指望能够仅凭想象力就能产生一个测试方法来解决未知的用户故事！开发人员似乎能够做到这一点，因为他们的任务通常更加明确——例如“将x模块更改为与z组件接口”或“重构y方法”。作为QA，您需要在计划之前熟悉引入/更改的功能，以便了解测试的范围和可能应用的测试设计技术。
自动化测试几乎是必不可少的，必须在迭代的前两三天内编写并“失败”，或者至少与开发人员准备好代码的时间相一致。然后，您可以运行测试并查看它们是否按预期通过（正确的QA TDD）。这是避免迭代末尾出现小瀑布的方法。您应该在开发人员开始编码之前或同时向他们演示测试，以便他们知道目标。
我说4是“几乎必要”的，因为有时候可以通过手动检查预期行为的清单（敢于说脚本！）来成功完成同样的事情——关键是与开发人员提前共享；不断与他们交流！
关于上述第2点任务的问题，我试图创建每个任务粒度为1/2小时至2小时，对应于可演示的工作片段，例如“将自动测试的密码错误检查添加到2小时内”。虽然这有助于我组织我的工作，但其他团队成员批评它过于详细，并且在站立会议上的效果是我要么从前一天移动多个任务以完成，要么根本无法移动任何任务，因为我还没有开始。人们真的希望在每日站立会议上看到稳定的进展，因此更有帮助的是创建半天或一天的任务块（但您可能会保留自己的“微任务”列表，以便在站立会议上传达整体进展情况）。
关于上述第4和第5点；您早期准备的自动化测试或手动检查清单应该只涵盖“快乐路径”或关键验收标准。一旦这些通过了，您可以计划在迭代末尾进行额外的“探索性测试”以检查边缘情况。开发人员在此期间所做的事情是有问题的，因为他们认为除非您发现错误，否则他们已经“完成编码”。一些敏捷实践者主张首先处理边缘情况，尽管这也可能存在问题，因为如果时间不足，您可能无法保证已交付验收标准。这是一个依赖于用户故事背景和您作为QA的经验的微妙平衡决策之一！看起来你的开发团队在发布给QA之前可能没有进行足够的测试。如果所有的单元测试都通过了，那么QA周期应该相对顺利，是吗？他们会发现一些集成错误，但这样的错误不应该很多，对吧？
您可能还会发现这些有关平滑敏捷燃尽图的技巧有用。
