我们正在尝试遵循我工作的软件开发的敏捷方法。到目前为止它运行良好,但是,在迭代结束时,我们遇到了构建问题,并且花费了一天的时间来修复:应该专门用于测试的时间。
结果,我们的 QA 没有足够的时间在迭代结束之前完成测试。您如何处理这种情况——在迭代过程中不可预见的问题会影响任务?
这取决于您的 QA 的安排——您是否可以让他们在开发人员已经在进行下一次迭代时继续测试?
如果是,我会让他们完成测试。
只需使用您已经拥有的数据继续下一次迭代。您真的不想因为一个瓶颈而阻止许多人。您可以在下一次迭代中增加一点额外的时间来修复尚未报告的错误,方法是为每个开发人员分配比完整迭代的价值略少的工作。
如果不是,只需像任何正常迭代一样计划下一次迭代,并像以前一样在迭代结束时进行测试。
如果您无法以约定的方式测试迭代输出,我们通常会为 sprint 取零分(或任何可以测试的点)。当时感觉很艰难,但事实证明这是一件明智的事情。
(项目的最后一个 sprint 显然是不同的)
通过在您的开发和 QA 之间进行一次切换,您已经在迭代中创建了一个单点故障。由于没有及时交付给 QA,您已经让这个迭代溜走了一天。通过匆忙进行质量检查来弥补时间并不是解决办法。
您可以通过更频繁地向 QA 交付来改善这种情况,理想情况下,您应该在每次完成功能时都这样做。如果最后一次构建失败,QA 可以只测试以前的构建,您必须将自那时以来实现的功能移动到下一次迭代。
敏捷规范是您仅将那些已完成的故事/积压项目计为已完成 - 通常您对已完成的定义应包括“正在测试”。因此,您根本不会因为尚未测试的故事而受到赞誉。毕竟,下一次迭代也可能出现类似的问题。
您对质量检查如何集成到您的流程中的问题并不完全清楚。一般来说,您应该确保错误无法逃脱 sprint,否则您的速度会变得非常不可靠。