Agile 如何打破敏捷项目开发和QA之间的障碍？

我已经为我的项目申请了几个月了。然而，我们看到了一个稳定的问题与我们的迭代烧毁。我们并不是每次迭代都达到零

剩下的任务是QA任务。比如写测试，测试等等

现在，对于敏捷的“跨职能团队”理念，存在一些组织阻力。开发人员为单个项目开发，但测试人员为多个项目共享。这与开发人员和QA合作的敏捷思想完全相反

事实上，我的测试人员的时间被分散在许多其他项目中，这是导致我们速度缓慢的原因。开发人员正在进行测试，以尽可能多地利用空闲时间，但有些任务仍然没有完成

据我所见，我可以做两件事：

说服组织采取行动 “每个项目都有一个 “专职质量保证人员”

将我对“完成”的定义更改为 不包括QA/测试工作。东西 但仍将进行单元测试

我宁愿避免做#2，因为我重视我们正在进行的测试协作

---

你对我的困境有什么建议

我认为，除非每个人都参与进来，否则你不能称你正在做的事情为敏捷。让测试人员坐在离开发人员很近的地方（至少在测试人员为他们的项目做任务的时候，比如创建测试计划），这可能会增加沟通，让QA来参与其中。

这是一个艰难的局面，不幸的是，很多试图遵循敏捷的公司都没有意识到这一点。 您不必有一个专门的QA人员——即使使用敏捷资源，也可以在不同的任务之间分配。您确实需要在进度跟踪中包含QA

是的，你的进度会慢一些。这有一个很好的理由（你没有足够的QA资源），你应该用手头的数字向你的组织管理层解释。这将有助于你说服他们必须做出一些改变

---

此外，您还可以转向更自动化的测试，并使用开发人员帮助测试人员实现测试自动化。这将更均匀地分配负载，并将提高您项目中QA的质量

< P>您可以将QA视为DEVS的客户。因此，当开发人员在迭代结束时发布到QA时，迭代就完成了

---

来自客户的反馈（需要修复的bug）可以进入下一次迭代的工作中。

要使这项工作起作用，您必须让QA为项目投入足够的时间。您可能需要与他们的管理层合作，以便为他们留出一定的时间来完成您的项目。通过这种方式，您将能够安排他们的时间，并确切地知道您的开发人员可以做多少工作，QA团队将有时间进行测试。这可能需要您缩减开发规模，以补偿QA减少的支持

---

你没有提到你的测试有多少是自动化的。您可以提高测试自动化程度，以减少QA团队认证项目所需的时间。您可以使用部分开发时间来准备QA测试，以供QA团队运行。虽然不是最理想的，但它可能会有所帮助。

短期内，停止使用不适合您流程的QA资源，并根据需要使用那些可以专用的资源来完成这些任务。我意识到这并不理想，但存在次优情况，即组织结构与流程不匹配。您可能会发现它会很好地工作（并在过程中学习测试）

从长远来看，你的选择是

• 找到一种方法使其与给定的组织结构/流程协同工作
• 改变组织结构，使之与流程相适应
• 更改开发过程以适合组织

---

我认为QA在敏捷环境中提供的不仅仅是测试工作。如果QA对工作流和工作流的不同分支有足够的了解，那么就可以驾驶scrum流程的其余部分。QA可以与开发人员一起设计最终驱动测试用例的逻辑工作流。通过这种方式，可以在开发过程中消除许多与设计和工作流相关的错误，然后再进入QA环境

这就是我们一直在做的，但我觉得这是在逃避责任。这就是我在第2部分中试图从问题中描述的。这种方法似乎兼有瀑布式和敏捷的所有缺点。作为一名测试人员，我会讨厌它，它真的是“把代码扔到墙外”。@testerab。嗯，我想我们做的比描述的要多。我们遵循这样一种方法，但在冲刺过程中，我们有几天时间进行信心测试。这些都是由一名测试人员运行的，他每天都控制着开发团队，我们都是为他/她工作的测试人员。因此，当我们到达sprint的末尾，并按照您的描述“将构建抛到墙边”时，我们都很高兴质量足够好，可以让测试团队运行一些深入的测试。如果他们正在测试一个候选版本，我们会立即修复关键问题。@testerab。我认为并不是每个项目都能像大多数敏捷书籍所描述的那样理想地敏捷，因为如果你为许多客户开发产品，而不是为单个客户定制解决方案，那么你很可能会大量地向现实世界发布——尽管你可以在客户愿意的情况下与他们一起运行测试版。在这种情况下，旧瀑布过程中的一些遗留问题仍然有效，尽管尝试将工作尽可能分为保持高质量的sprint会很好地工作。如果您在sprint中使用测试人员进行一些测试，那么这比您最初的回答中听起来的“过关”要少很多-communic