显然，我们使用Scrum的开发方法。 这里的一般是怎么回事：
开发商鞭打周围试图完成他们的任务。 一般来说，任务承担了大部分的冲刺完成。 QA缠身开发释放的东西，他们可以测试，开发终于抛出了一些bug的代码出来QA一两天冲刺结束前和花费的时间固定为Qa查找错误的休息。 QA不可能完成的任务上的时间，冲刺的时间很少释放，以及开发和QA在冲刺的最后有一个悲惨的几天。
Scrum是应该如何时释放开发任务占用大部分冲刺的工作？
谢谢大家在讨论你的一部分。 由于这是一个相当开放式的问题，它似乎并不像有一个“答案” - 下面还有很多好的建议。 我会尝试总结我的一些“带回家”点，做出一些澄清。
（顺便说一句 - 这是把这个最好的地方或者我应该把它放在一个“答案”？）
考虑点/作用于：
我的看法是，你有一个估计问题。 看来，以测试每个功能的时候丢失的，只有规划冲刺时被认为是建筑的一部分。
我并不是说这是一个难以解决的问题，因为它是比什么都更常见。 但事情可以帮助有：
考虑QA作为开发团队的成员，包括他们在冲刺的规划和更密切地估计。
“释放的开发任务，”不应该占用大部分的冲刺。 完整的工作特点应该。 尽量收集有关开发时间指标VS QA时间为每类任务和预计未来冲刺时使用这些指标。
您可能需要检查您的积压，看看如果你有非常粗粒度的功能。 尝试他们在可以很容易地估计和测试更小的任务划分。
总之，似乎你的团队还没有找到其真正的速度是什么，因为有这样做的估计和准备冲刺时不被考虑的任务。
但最终，估计不准确是您在基于敏捷或瀑布为基础的项目找到一个艰难的项目管理问题。 祝好运。
有点晚了这里，但这里的聚会是基于你写我服食。
现在，Scrum是一个项目管理方法，而不是一个发展一个。 但它是关键，在我看来，有一个适当的发展过程。 如果没有一个，你花你的大部分时间的反应 ，而不是建立。
我是一个测试第一个男人。 在我的开发过程中，我先建强制执行的要求和设计决策的测试。 你的团队是如何执行这些？ 我想在这里指出的一点是，你根本无法“扔东西翻过栅栏”，并期待什么，但故障发生。 失败是要么将是测试团队（由不测试非常好，从而让问题由滑）或由开发商（按未建立解决该问题的产品）。 我不是说你必须先写测试-我不是一个好战或测试第一传道者-但我说你必须到位，以生产出优质的，经过测试，准备用于生产的代码有一个过程，当你达到迭代结束。
你在哪里，在这个开发方法，我称之为死亡缠绕法 ，我是正确的 。 我内置软件为政府（美国）多年来在这样的模式。 它不能很好地工作，它的成本大量资金，它产生下旬代码，代码很差，什么都不做的士气。 当你花你本来可以避免使摆在首位你所有的时间修正错误你不能取得任何进展。 我是绝对由婚外情打下来。
你不想QA找到你的问题。 你想放他们出去工作，真的。 我的目标是让QA目瞪口呆，因为一切都只是工作。 当然，这是一个目标。 在实践中，他们会找到的东西。 我不是超人。 我犯错了。
返回调度...
在我目前的工作我们做Scrum的，我们只是不称呼它。 我们不是到这里的标签，但我们进入时间生产高质量的代码。 每个人都在船上。 我们告诉QA我们必须准备好测试和时间。 如果他们走了，敲早两周的时间，他们可以倾诉的手。 每个人都知道的时间表，每个人都知道会在什么版本，每个人都知道，产品所标榜它去进行质量检查工作。 那么，是什么意思呢？ 你告诉QA“不打扰测试XYZ - 它坏了，不会被固定，直到释放C”，如果他们去测试，你点他们回到这句话，并告诉他们不要浪费你的时间。 苛刻，也许，但有时是必要的。 我不是粗鲁，但每个人都需要知道的“规矩”，什么应该被测试，什么是一个“已知的问题”。
你的管理必须是在船上。 如果不是，你将会有麻烦。 QA不能运行show和开发组不能完全要么运行它。 所有组（即使这些群体是每个组或身兼数职家伙只是一个人）必须在同一页上：客户，测试团队，开发，管理，和其他任何人。 超过一半是沟通，通常。
也许你贪多可以在冲刺中完成更多。 这可能是这种情况。 你为什么要那样做呢？ 为了满足一个时间表？ 如果是的话，那就是管理需要介入并解决问题。 如果你是给QA bug的代码，希望他们能折腾回来。 不如给他们3个事情，比8米的东西都是未完成的工作。 我们的目标是产生一些功能集是在每次迭代完全实现，而不是拼凑一堆半完成的东西。
我希望，因为它旨在此接收 - 作为鼓励而不是夸夸其谈。 就像我提到的，我一直在你在哪里，那就不好玩。 但是希望还是有的。 你可以得到的东西在冲刺转身，也许两个。 也许你不会在接下来的冲刺添加任何新功能，只是解决什么是坏了。 你必须决定，作为一个团队。
编写测试代码还有一个小插件：我一直以来采用“先写测试”的方式发现自己更轻松，更自信我的产品。 当我所有的测试都通过了，我有，我根本无法有没有他们的信心水平。
祝您好运！
在我看来，有在需要QA功能测试，以便对个别功能的方案的资源分配问题，要“做”冲刺之内。 似乎没有人在任何QA相关的Scrum讨论到目前为止，我已经找到了解决这一问题，这里原来的问题几乎是相同的（至少相关的），所以我想提供了部分答案和扩展问题的位。
至于有关服用全力冲刺开发任务的具体原来的问题 - 这似乎是对这些任务缓和的一般建议是有道理的，如果由QA功能测试是你的“完成”定义的一部分。 由于可以说，4周的冲刺，如果它需要一个星期左右，从多个开发人员测试多种功能，那么就好像服用约3周的开发任务，随后的测试任务花费约1个星期是应答滞后一周。 QA当然会为尽快我们认识到，从最后一组提供的功能，将有一个星期左右的滞后开始。 我意识到，我们想要得到功能QA尽快使您不必在冲刺这个瀑布般的场景，但现实情况是，发展通常不能得到真正的，有价值的交付功能，QA，直到1〜3周成冲刺。 当然也有在这里和那里的点点滴滴，但大部分工作是2-3周的发展，则约一周的测试剩。
因此，这里的资源分配问题，以及我的扩展问题 - 在上述情况下的质量保证有时间来测试冲刺计划中的功能（3个星期的价值的开发任务，剩下最后一周的测试最后提供的功能）。 也让我们假设QA开始得到1周的发展后，一些可测试功能 - 可是周＃1 QA，以及怎么样周＃4的发展？
如果QA功能测试是“做”在一个冲刺特征的定义的一部分，那么似乎这种低效率是不可避免的。 QA将周＃1和发展过程中基本空闲就会星期＃4中大部分闲置。 当然也有一些事情，在这个时候填补自然，像bug修复和验证，设计/计划等，但我们在75％的容量主要scheudling我们的资源。
答案很明显，似乎是重叠的开发和QA冲刺，因为现实情况是，QA总是滞后beind发展到一定程度。 演示产品的拥有者和其他人将跟随QA冲刺，因为我们想要功能被显示之前进行测试。 这似乎更有效地使用这两种开发利用策略和质量保证，因为我们没有太多时间浪费。 假设我们要保持开发人员在开发和测试人员的测试，我看不到更好的切实可行的解决方案。 也许我错过了一些东西，我希望有人能摆脱这对我来说一些轻 - 否则，看来这刚性方法Scrum是有缺陷的。 谢谢。
希望你在每个冲刺应对更少的开发任务，解决这个问题。 这导致了问题：谁的设置Dev的目标是什么？ 为什么开发未能达到这些目标一致？
如果开发没有设定自己的目标，这就是为什么他们总是迟到。 而这是不是练的Scrum的理想方式。 这只是大，截止驱动的交付以及部分开发商没有实际的利益攸关者的责任增量开发。
如果开发不能设置自己的目标，因为他们不知道够不够，那么他们必须更多地参与到了前面。
Scrum的取决于四个基本原则，在概述了敏捷宣言 。
互动关系 - 这意味着开发，QA，项目管理和最终用户需要更多的交谈，并与对方通话。 软件是电脑的神秘语言编码知识的过程。 为了编码知识，开发者必须掌握的知识。 [为什么你认为我们称之为“码”？] Scrum是不是“写规范 - 抛过来气窗”的方法。 这是反“写规范 - 抛过来气窗”
可工作的软件问题-这意味着每片开发截去已导致工作释放。 不是一套错误修复QA与搏斗，但工作的软件。
客户协作 - 这意味着开发与业务分析师，最终用户，企业主，大家谁可以帮助他们理解他们正在构建的工作。 截止时间并不重要尽可能移交给客户，接下来的事情。 如果客户需要X，这是最高优先级的事情给大家做。 如果该项目计划建造说Y，这是说大话的负载。
应对改变 - 这意味着客户可以重新排列以下冲刺的重点。 他们不能重新排列过程中的冲刺（这是疯了），但以下所有短跑是不断变化的重点候选人。
如果客户的驱动器，然后将最后期限变得不那么做作“的项目里程碑”，更“我们需要X，再Y，这个东西在部分Z，我们不需要任何更多。现在，我们有W，Z是多余的“。
Scrum的规则说，所有Sprint的项目需要“充分的测试，有可能实现的功能”，在冲刺年底被认为是完整的。 冲刺最后总是准时，而球队也无法获得信贷，并且不允许在Sprint的审查，是不完整的呈现任何东西 - 包括QA。
从技术上讲，这就是你应该需要。 以团队承诺一定量的工作，最后它得到QA冲刺结束前两天和QA未及时完成。 因此，从Sprint的输出为零，他们在客户面前去承认，他们什么都没有表现出了一个月的工作。
下一次轮，你敢打赌，他们会挑更少的工作，并找出如何得到它的质量检查，以便它能够按时完成。
说到谁有权敏捷项目的经验。5年这个QA是一个非常棘手的问题，我仍然不知道所有的答案。
我作为一个“三元”，我参与了任务了故事和以2周的迭代开始在规划会议估计（谁对程序+一个QA两个开发者）的一部分工作。 正如上面提到的adrianh是必不可少的质量检查，以获得在最初的规划冲刺他们的声音。 这是很困难的，特别是如果你正在与开发商有非常强烈的个性但质量检查必须是在这个词的真正意义上的自信（即没有攻击性或有力，但恭敬地试图了解真相/ PO和开发人员/技术专家，同时使自己理解）。 我主张计划鼓励测试驱动的心态在第一生产QA任务 - 在QA可能不得不从字面上把自己转发到得到这个采纳。 这是对有多少人认为软件开发工作，但支付的几个原因股息;
QA声并没有沦为被问“让你怎么测试呢？” 之后，开发员们说他们的作品（瀑布心态）。
它允许QA提出测试其想法，同时检查的验收标准的可测性，而真理/ PO存在（我没有说这是必不可少的他们存在于规划会议没有我？！）填写理解任何空隙。
它提供了一个测试驱动的方法的基础 - 测试方法已被阐明，并委托开发人员，可以考虑一下他们将如何产生的代码通过这些测试之后。
如果第1步 - 3是迭代的其余部分，你还在做比史蒂夫在第一篇文章假设情景好上千万倍你唯一的TDD活动; “开发商打白条试图完成他们的任务，一般任务承担了大部分的冲刺完成。QA缠身开发释放的东西，他们可以测试，开发终于抛出了一些bug的代码出来QA一两天冲刺结束前和花的时间来修复的bug QA是寻找”休息
不用说，这带有一些警告的QA;
他们必须准备让他们的测试由离散事件和真相/ PO，并达成妥协的挑战的想法; 在“QA警察”的态度不会在敏捷团队洗。
QA任务必须取得一个艰难的平衡既不过于详细，也太普通了（任务可以写一张卡片去了“辐射板”上，并讨论了在每日站立会议 - 他们需要从“进行中”迁“已完成”的迭代过程中）。
质量检查的需要为规划/评估会议作准备。 不要指望能够只是转起来并产生看不见的用户故事的测试方法把你的头顶！ 开发者似乎确实能够做到这一点，因为他们的任务往往更为明确的 - 例如，“改变X模块Z分量接口”或“重构Ÿ法”。 作为一个QA你需要熟悉的功能引入/变更前的规划，让你知道的可能应用的测试和考什么设计技术的范围。
这几乎是必备的自动化您的测试，并拥有这些书面和迭代或至少共同与前前后后时，开发员们的代码准备的前两三天之内“失败”。 然后，您可以运行测试/ S，看看他们是否通过预期（QA适当TDD）。 这是你如何避免一个小型瀑布在迭代结束。 你真的应该试玩测试的离散事件之前或之时，他们开始编码，让他们知道什么瞄准。
我说4是“几乎是必备的”，因为同样的有时可以成功地与手动清单实现（我敢说脚本！）预期行为 - 关键是要提前与离散事件分享这一点; 保持与他们谈话！
至于点2任务的主题上面，我曾尝试创建任务颗粒在大小1/2小时至2小时分别对应于论证的作品例如“添加检查不正确的密码自动测试 - 2小时”。 虽然这有助于我安排我的工作就一直被人诟病其他团队成员为过于详细，有我的立场起坐的效果无论是跨移动多任务之前从一天完成，否则不能够，因为在所有移动任何任务我没有到他们没有。 人们真的想看到的稳步前进感在每日站立起坐，因此更有助于在半天或1天块创建任务（但你可能会保持自己的“微任务”列表向完成做那您使用通信中的站起整体进度）更大的任务。
至于分4和5之上; 你早做准备的自动化测试或手工核对表应真正涵盖只是幸福的路径或关键验收标准。 一旦这些传给你可以有计划朝迭代结束最后一轮“探索性测试”，以检查边缘的情况下的额外任务。 因为据他们担心，除非和直到你发现了错误，他们是“代码完成”是什么在这段时间的离散事件做是有问题的。 有些敏捷实践者主张去为边缘的情况下第一，虽然这也可能是有问题的，因为如果你用完的时候你可能没有保证，验收标准已经交付。 这是那些依赖于用户故事的背景和你的经验QA微妙平衡的决定之一！
正如我在开始时说，我仍然不知道所有的答案，但希望以上提供脱胎于的艰辛经历一些指点！
听起来像是你的开发团队可能不会做对自己足够的测试，发布进行质量检查。 如果你所有的单元测试都通过，则QA周期应该是比较一帆风顺，不是吗？ 他们会发现一些整合的错误，但不应该有非常多的，对不对？
我认为，这里有几个问题。 首先，我想，也许开发任务也不细粒度不够，或者也许不是很好估计，或者两者兼而有之。 在Scrum的短跑的全部目的是为了能够在冲刺的最后证明可行的代码。 这两个我提到的可能导致bug的代码的问题。
如果开发者对冲刺年底发布bug的代码，我也想看看：
我已经在过去听到反复讨论的一个想法是使用一个QA人作为ScrumMaster的。 他们将是本作的日常standups和可以得到的东西在哪里，在与开发商的意义。 他们可以用PO（假设PO可以充分地做好自己的工作）解决问题。
我不禁觉得你需要QA和你的Scrum团队之间更coorporation。 这听起来像只测试发生在年底，这是一个问题。 获得QA成为球队的一部分，将有助于确定的东西，可以更早和更好的测试。
我也觉得你有与产品负责人的问题。 他们必须在那里确保每个人都正在推动正确的方向。 他们应该确保有良好的合作，不仅QA和开发者之间，但开发者本身之间。
“如何在争球时应该释放的开发任务占用大部分冲刺的工作？”
正如你已经发现了 - 它不:-)你描述听起来并不像Scrum来我工作的过程非常顺利 - 或至少不喜欢的Scrum做得很好。
我从你描述一下QA民间是否是团队的一部分不确定 - 或者一个单独的组。
如果他们是一个独立的组，然后这可能是问题的一个重要组成部分。 他们将不参与球队的承诺，完成工作任务 - 与产品所有者相关联的范围内协商。 我从来没有见过的雅居乐集团成功以及没有在球队中他们是QA技能。 无论是通过使开发人员提供了大量的测试/ QA技能 - 或有对球队的嵌入式QA人或三个。
如果他们对球队那么他们需要得到他们的声音在最初的冲刺规划听到更多。 现在，你应该是清楚明了的产品所有者和团队，你过量使用。
我想尝试一些东西，如果它是我的：
您可能还会发现这些有关平滑下来混战燃尽的提示非常有用。
我们解决了这个问题，如下所示： - 在产品积压必须有合适的标准或验收标准的每一项，如果没有这些，我们不开始冲刺 - 一个测试仪是我们团队的一部分，每一个产品积压的项目，他创建测试任务（1或更多，根据验收标准）与估计在一起，并且链接到项测试 - 在日常Scrum，那些完成了所有的任务都放在一个“来测试”列 - 我们从来没有完成的任务称取超过16小时长; 被估计更长的任务，都分手了
拆分任务分解成更小的任务。
此外，QA可以创建测试用例开发测试反对。
一个想法要考虑的是有质量保证工作的主要发展背后的一个迭代。 这在我们的环境效果很好。
在这里我要说的是，一个尺寸不适合所有。 每支球队都涉及不同的QA。 这与其说取决于你正在从事的项目，要么它是一个小的或大的。 它需要广泛的回归，用户的认可和探索性测试，或者你有比较少的情况下进行测试。 让我重申，在雅居乐，多面手的首选专科。 那是什么？ 因为当你没有什么测试，所以这时候你可能会做别的项目过程中的时间。 你也可能会做测试，即使你是一个硬核程序员。
我们该如何处理呢？ 我们有定期的2周冲刺。 就在本周由开发商完成了任务一个星期后，测试开始。 现在，测试人员不断增加的问题，以我们的问题跟踪和开发商谁正在开始采摘这些错误与他们的冲刺任务完成。 到了冲刺的最后，我们大多得到与我们的冲刺任务和所有关键和重大的错误做。
那么，是什么测试器两个冲刺的第一个星期？
那么，总有一些东西进行测试。 我们测试的积压的任务，这可能包括一些探索性测试。 很多人不重视探索性测试但这是非常重要的打造优质产品。 好的测试为自己创造任务，并找到出问题并对其进行测试的可能性。
希望帮助！
