我正在尝试采用敏捷概念，并且已经进行了大量研究，但我还没有找到一个问题的答案。我知道，当开发人员最初对迭代的任务进行编码时，测试人员可以准备他们的测试计划和测试用例，但是当测试开始时，如果没有发现需要进一步编码和重新测试的错误，应该怎么做？开发人员当时正在努力吗？在我当前的瀑布式 SDLC 中，开发人员将开始处理下一个版本的内容，但对于敏捷来说，似乎只能在当前迭代/冲刺上完成工作，直到它完全完成。
问问题
190 次
2 回答
1
@user3329073 - 所以，出于好奇，您目前是在计划冲刺和发布 - 还是您仍在使用瀑布？还是混合方法？
无论如何，在规划周期中，您的开发人员似乎完成了他们应该处理的所有任务，并将这些任务交给您的 QA 团队进行测试。根据缺陷或更改的数量，他们可能正在修复这些缺陷或对更改进行编码 - 或者 - 正在等待分配给他们的新工作。这似乎有些奇怪-但这可能是由于我没有完全了解您的情况。
通常，我希望（尤其是在敏捷环境中），开发人员可能会执行以下一项或多项操作 -
- 他们可能正在编写测试自动化脚本，以便您的测试自动化套件涵盖每个新功能。（您目前正在做测试自动化吗？）
- 他们可以在同一个 sprint 中找到下一个任务/用户故事/需求——并开始着手处理。
- 他们可以承担一些工程任务——例如出于性能或其他常见原因的代码重构，以及其他重要（但通常不紧急）的任务——甚至是文档。
这一切都取决于您的团队运作的整体环境。代码质量、稳定性、性能、文档的组织目标是什么？什么是测试自动化策略？有哪些工具可以让开发人员和测试人员充分完成他们的工作？
例如，在我们的工程组织中，我们更多地遵循看板方法来实现敏捷，我们几乎没有测试人员。我们进行测试驱动开发，开发人员必须在开始编码之前编写测试用例。一旦完成编码，他们必须自动化他们编写的测试用例，并测试代码以确保其工作。完成后，我们会根据需要由首席架构师和其他工程负责人进行代码审查。与此同时，开发人员继续处理下一个用户故事或可处理的缺陷。下面显示的是我们整个产品开发板中的开发通道。
此外，我们有一个单独的通道来跟踪重要的工程任务和需要完成的工作——如果开发人员有时间，他们将从那个通道中提取工作——并一直工作直到完成。
我们确实有 1-2 名手动 QA 人员，他们与产品管理人员一起对确定在下一个版本中发布的一组特定功能进行全面审查。
因此，就像我说的，这取决于您管理团队以及产品部署和交付的总体方法。看板在帮助您变得敏捷方面的优势在于，它可以帮助您从您所在的位置开始并从那里改进您的流程。
以下是一些关于我们的做法的额外阅读，可能会有所帮助 -
看板开发者的一天 - http://bit.ly/1h7kBcH
看板的好处 - 周期时间减少 300% - http://bit.ly/1bmuYLy
希望这可以帮助！
于 2014-02-19T20:40:10.233 回答
1
听起来确实，在您向敏捷过渡期间，您还没有实现团队成员的完全整合。考虑将日常构建扩展到测试环境（或持续部署，如果可以的话），以便测试人员可以在工作进行时审查工作。
此外，正如@Mahesh Singh 所提到的，开发人员也可以帮助进行测试，并且可能会与测试团队进行沟通，以指导他们完成测试，因为新版本正在接受审查。
无论您如何设置它，在 sprint 中总会有一个点，当 sprint 中没有更多故事可以开始时，团队需要结束迭代。这是您希望拥有“跨职能”团队成员的地方，以便他们可以帮助解决可能留下的任何问题：
- 准备演示脚本
- 建筑安装包
- 文档
- 培训准备
- 自动化测试
- 为下一次迭代回顾即将到来的故事
- 帮助完善估算
- 打乒乓球！！
于 2014-02-20T03:23:01.357 回答