【发布时间】：2022-11-22 02:44:48
【问题描述】：
在我的团队中，我们有大约 5 名开发人员和 3 名 QA 测试人员。
我们的冲刺是 10 天的冲刺，但我们作为开发人员的工作在第 6 天到期，以便 QA 测试人员可以有 3 天的时间来测试我们每两周发布一次之前完成的工作。
我觉得这个系统效率很低，并且真的限制了我们作为开发人员可以做的工作，因为我们只有 6 天的开发时间，然后是几天的拇指摆弄，因为还没有更多的用户故事。
其他人是怎么做到的？
【问题讨论】：
【发布时间】：2022-11-22 02:44:48
【问题描述】：
如果可能的话，开发人员的任务应该足够精细，以便开发人员在大约 4 小时内完成。这有助于开发人员每天完成大约 2 个任务，从第 1 天开始，QA 将能够开始测试。
您可以根据自己的动态更改数字，但一般来说，细化任务有助于异步工作和利用率。
【讨论】：
-
你的团队是如何做到的？
-
我通常是一名顾问，我会向我的客户推荐我在答案中分享的数字。
您可能会尝试的一些事情：
- 尽可能小地分解故事
- 使用 stubbs 和 mocks 使功能可用，以便更快地开始测试准备
- 使用测试先行的方法并在开发工作开始之前编写自动化测试（QA 和开发人员都可以编写自动化测试）
【讨论】：
-
你的团队是这样做的吗？
-
我是一名教练，所以我与许多团队合作，每个团队的方法都略有不同。对于有专门 QA 的团队，最常见的方法是寻找更小的故事，并尝试在 sprint 中尽早将完成的功能提交给 QA。我工作的很多团队都没有专门的 QA，团队中的每个人都同时进行开发和测试。这大大减少了问题。
您描述 dev/qa 拆分的方式是 2 周内的“瀑布”！
其中一个敏捷框架 (DSDM) 具有“测试在整个生命周期中集成”的“测试实践”。
这意味着故事/PBI 是在开发时进行测试的，而不是在 Sprint 结束之前全部“保存”！
Nezih TINAS 对 PBI 大小的回答可用于故事恕我直言中的任务，但我更喜欢端到端的 PBI，开发人员需要 3 到 4 天的时间进行全面的验收测试；超过 4 或 5 个 AC 通常意味着拆分 PBI，仍然是端到端，而不是前端/后端。
当您的开发人员工作 6 天时，您的 3 个 QA 人员在做什么？
【讨论】：