质量检查在冲刺结束时完成所有工作

#1 楼

让整个团队来解决问题。
鉴于您已经清楚地讨论了安排，团队需要寻找解决方案。在与我合作的所有组织中，问题本身似乎都是地方性的。除非采取积极措施来解决这个问题，否则似乎是不可避免的。
一个常见的问题是，没有“一个团队”。有“开发人员”团队和“质量检查”团队。与不同的经理。这会导致优先级冲突，并产生您正在描述的问题。
当“ QA”是法规遵从性的一部分时，通常会发生这种情况。它实际上不是开发的一部分，被视为一个独立的过程。
对于组织中要追究个人责任（而不是团队）的组织，这会造成严重的问题。当问责制是在个人级别而不是团队级别时，就会有指责和指责。这并不是说人是坏人还是消极人，这仅仅是他们工作的奖励系统的必然结果。要明确“团队责任制”实际上是很难做到的，这意味着对传统做法的改变，例如每年进行一次个人审查
为了改变文化，这非常困难，我建议您看一下：


积压的提炼-确保问题“我们将如何在单元，集成和用户界面级别对此进行有效测试？”要求每张票。这是一个巨大的变化，需要开发经理正式引入和支持。它简单但令人惊讶，但功能强大且有效。
故事更小-是的，这是一种很好的方法
沟通和尊重。确保质量检查人员和开发人员经理密切合作并互相尊重。确保每个经理都会捍卫其他经理的工作。
物理和虚拟平等。确保整个团队位于同一地点。如果是远程工作，请确保在开发过程中他们的声音被认为是平等的，从而确保QA不被视为二等公民。
每天都要站起来。确保质量检查人员在日常工作中寻求与开发人员结对，以便他们参与正在发生的事情，而不仅仅是“验证阻止程序”（传统的质量检查人员）。

减少了周期时间。这很难，主要是因为它违反直觉。 “我们需要更多的时间，而不是更少！”是自然反应。但是，业界已经了解到-您发布的频率越多，测试就越容易和更好。因为必须如此。别无选择。幸运的是，频繁的练习（在测试和发布时）使它变得更好。必须每天进行发布时，您必须进行有效的测试以保持正常运转。
主动监视剩余的测试时间-确保测试团队在发现剩余的工作时间不足后立即将其状态报告为“红色”。如果测试团队在冲刺的后半段一直保持红色状态，则很快就会变得非常明显，因为要完成有效的工作还很多。已经为在这种情况下每个人提供帮助的程序达成了一致。否则，开发人员可能会破产并承担更多债务！ （未经测试的代码）。

这是一个管理问题，要求开发人员和质量检查经理讨论并达成拥护者的方法。每个经理都需要倡导并促进团队工作方式的变化。反过来，他们将需要促进和倡导这种管理方式，他们可能会同意所有敏捷的东西……但是还没有得到真正支持它所需的真正组织变革和文化的反馈。 />

#2 楼

出色的沟通带来了出色的结果
质量保证部门一直保持最后的立场。质量检查人员应主动向利益相关者传达延误和相应的风险。
我从未见过任何敏捷项目能够按时完成每个冲刺。首先要找出造成延迟的原因。造成延迟的原因可能有多种：

估计不是很准确
对需求的研究还不够深入
环境不稳定
单个资源的工作负荷不当
资源不足
优先级/依赖项冲突

处理此类情况的可能方法：

保持实际估算的缓冲水平
重新计划您的冲刺
尽早与利益相关者沟通延迟
逐小片段地讲故事（以提高估算准确性）
开始尽早进行测试
确定故事的优先顺序，并在可能的情况下相应移至积压
限制测试范围

尝试查找一个/多个常见的延迟原因。确定原因后，请召集您的团队并开始研究并立即解决。

#3 楼

本着跨学科团队工作的精神，我认为如果存在积压的工作（甚至没有积压的工作），则开发人员应参与质量检查流程。
我认为这对开发来说是不好的做法和质量检查团队不要紧密结合-尽可能地，他们应该是同一团队，这使得开发人员可以在需要时更轻松地将上下文切换为进行手动测试。

#4 楼

解决此问题的方法有几种。
从Scrum的角度来看，您的开发团队没有子团队。您可能有专家，例如专门从事测试的人员，但整个团队都应参与其中。并非让质量检查专家处于必须在Sprint结束时测试所有内容的位置，而是只要测试发生，整个团队就应该参与测试。质量保证专家可以帮助团队的其他成员进行良好的测试实践培训。
不是专门针对Scrum的，在Sprint中逐步交付工作，并不断进行集成和测试也可以缓解一些压力。在工作完成时进行测试，而不是在Sprint结束时进行测试。如果您要等到Sprint结束集成工作，请尝试更快地集成它。如果看起来像您做不到，则可能表明您的作品尺寸或切片不正确。
最后，在某些环境中，有充分的理由进行独立的质量检查。前两点仍然适用，开发团队应该生产高质量的产品。但是，任何独立的集成和测试都应移至Sprint之外，并移至单独的团队中。如果开发团队做得很好，则该团队可能会有反馈，但不应定期发现会阻止Sprint的输出发布到下一个下游流程的问题。
因为这个问题是该问题交叉发布到项目管理堆栈交换中，此答案也在那里交叉发布，因为它同样适用。

#5 楼

我们有一个问题

问题是谁？冲刺是一个完全人为的时间单位，通常由不做您的工作的经理设置。如果您要突破这个人为的最后期限，但客户和客户对产品感到满意，也许是时候改变您的团队合作方式了。
现在看来您的工作方式存在一个问题是流程最终会造成瓶颈，而这主要是您作为测试人员的问题。这不是最佳选择，因为当开发人员最终将工作扔到篱笆上到您的花园进行测试时，整个团队会变得很慢。
一种更好的解决方法是最大程度地减少正在进行的工作并专注于快速交付少量内容。这样一来，您作为一个团队就只有几个/小的功能正在进行中。理想情况下，您一次可以得到一个，然后对其进行测试，一旦完成，就可以投入生产。流程更流畅，瓶颈更少。这些是通常用看板方法描述的想法，您可以检查一下，或者与您的团队一起考虑。在您的情况下，它可能会更好。

我们是否应该将PBI分解为更小的故事？无论您如何工作，小故事通常更易于管理。如果您的故事很大，并且需要几天的时间才能发展，是的，它们应该更小。在Scrum中，您估计需要花费多少时间，您无法真正估计巨大的任务，错误将是巨大的，只会在以后时间不够时才为您和团队带来更多的问题（这令人惊讶地发生了经常）。
这里要讨论的另一个主题可能是您和团队的测试方式？您执行TDD，有人编写单元测试，API测试，还是通过用户界面测试所有内容？您对开发人员有关缺陷和问题的反馈有多快和专注？他们是否需要花费数小时的调试时间？
可能的解决方案将是这些主题的交集，但是至少您可以想到一些想法。

#6 楼

告诉您的开发人员和管理人员，积压项目只有经过测试才能“完成”。因此，PBI在冲刺结束时不会“完成”，它们仍未完成，因为团队“忘记了”安排必要的质量检查。
整个Scrum团队都应该有“完成”的定义，并且质量检查属于其中。
如果您能处理讽刺或讽刺，请问开发人员为什么他们对这种冲刺表现不佳...

#7 楼

并不是真正的敏捷
通常，人们在不敏捷的情况下采取了瀑布处理并在上面贴上了敏捷标签。经典的敏捷模型根本没有单独的质量检查团队。有一个小团队，向产品负责人报告。产品负责人负责验收，开发人员负责部署前测试。通常通过自动化。

#8 楼

QA可以通过不接受sprint中的“新工作”来进行回退，这实际上意味着测试任务将在下一个sprint增量中完成。迫使开发人员将测试计划更好地集成到开发过程中。
这是开发组织的结果，需要将它塞入敏捷过程中，但这并不是您可以做的最糟糕的工作结构。
/>但是，如果QA验证碰巧需要大量返工，则还需要在整个测试过程中向左移动。

#9 楼

就像其他海报所说的那样：一起工作。
要确保您说的是同一语言。
我们在团队中采用了BDD，这使我们的产品所有者，开发人员和测试人员能够做到。相同的语言，它使操作变得更加容易。
这也意味着我们的测试人员可以在sprint的开始就开始编写测试方案！ （即使还没有实现）

#10 楼

阅读https://www.google.com/search?gs_ssp=eJzj4tDP1TdIMUpPNmD04i9ILMrOzCvOz1MvVshshJLAcAclYIyw&q=parkinson%27s+law&rlz=1C5CHFA_enGB779GB779&oq=Parkinson%27s+Lawiiij1i0ji0j1i0j1j0j1j0j1j0j1jj0cj1c0jj1c0jj0j1j0j1j0j1a0jj0jj0jj0jj0jj0j -开玩笑，直到我读完这本书为止。
根本没有开玩笑，帕金森定律基本上说，工作正在扩展以填补可用的时间。
实际上，这意味着人员，团体或团队需要在较短的时间范围内分配较小的任务，以便整体按计划进行。
这不是项目管理的主要目的吗？
（对不起，我不知道如何让SE接受链接…）

#11 楼

质量检查在以下冲刺中进行。
冲刺并不意味着必须在冲刺结束时准备好向客户提供该功能。冲刺只是一个连贯的工作包。
人们普遍认为测试与开发大约需要相同的时间。开发人员在一个冲刺中完成一项功能（以他们满意的质量为准），然后由质量检查人员在下一个冲刺中测试该功能，这是完全正常的。这将交付分解为连贯的工作包。对于较小的更改，可能在与QA相同的sprint中进行修复，或者对于更严重的错误，可能需要另一轮专门的开发和QA sprint。当然，对于尚未进行充分检查的QA，这是任何将开发和QA分开的组织中普遍存在的问题，并且不是敏捷开发所独有的。敏捷的好处是，在下一次冲刺的回顾中，质量保证可以立即将其提高为项目风险，并且开发人员可以承担未来做得更好的任务。