我已经在我的项目上申请agile几个月了。然而，我们看到我们的迭代burndowns存在稳定的问题。我们每次迭代都没有达到零。
剩下的任务是QA任务。比如编写测试，测试等等。
现在，对于敏捷的“跨职能团队”理念存在一些组织上的阻力。 Dev为单个项目开发，但测试人员共享多个项目。这与开发和QA协同工作的敏捷理念完全相反。
我的测试人员的时间与许多其他项目分开的事实是导致我们减速的原因。开发人员正在测试尽可能多的松弛，但有些任务仍未完成。
从我看来，我可以做两件事：
我宁愿避免做＃2，因为我重视我们正在进行的测试协作。
你对我的困境有什么建议？
答案 0 :(得分：3)
除非每个人都参与其中，否则我认为你不能称之为敏捷。让测试人员在物理上靠近开发人员（至少在测试人员正在为他们的项目开展任务时，例如创建测试计划），这可能会增加沟通并让QA购买。
答案 1 :(得分：3)
这是一个艰难的情况，不幸的是，很多试图关注敏捷的公司都不承认这一点。 您不必拥有专门的QA人员 - 即使Agile资源可以在不同的任务之间分配。您需要在进度跟踪中包含质量检查。
是的，你的进度会慢一点。这是有充分理由的（您没有足够的QA资源），您应该向您的组织管理层解释，并附上数据。它将帮助您说服他们必须发生一些变化。
此外，您可以转向更自动化的测试，并使用您的开发人员帮助测试人员进行测试自动化。这将更均匀地分配负载，并将提高项目质量保证的质量
答案 2 :(得分：2)
为此，您必须让QA为项目投入足够的时间。您可能需要与他们的管理层合作，以便为他们的项目留出一定的时间。通过这种方式，您可以安排时间，并确切了解开发人员可以做多少工作，QA团队将有时间进行测试。这可能需要您缩减开发时间以补偿QA减少的支持。
您没有提及您的测试有多少是自动化的。您可以增加测试自动化，以减少QA团队认证项目所需的时间。您可以使用部分开发时间为QA团队准备QA测试。不是最佳，但它可能有所帮助。
答案 3 :(得分：2)
我认为QA在敏捷环境中提供的功能远不止测试工作。如果QA对工作流程及其不同分支有足够的了解，那么可以在驾驶员座位上驾驶其余的Scrum流程。 QA可以与开发人员一起设计逻辑工作流程，最终将驱动测试用例。这样，在进入QA环境之前，可以在开发过程中消除大量与设计和工作流相关的错误。
答案 4 :(得分：0)
您可以将QA视为开发者的客户。因此，当Devs在迭代结束时释放到QA时，迭代就完成了。
来自客户的反馈（需要修复的错误）可以用于下一次迭代的工作。
答案 5 :(得分：-1)
在短期内，请停止使用无法适合您的流程的质量保证资源，并将这些任务与可根据需要专用的任务相结合。我意识到这并不理想，但是有一个次优的情况，你的组织结构与你的流程不匹配。您可能会发现它会很好（并在此过程中了解测试）。
从长远来看，您的选择是