显然我们使用 Scrum 开发方法。一般情况下是这样的:
开发人员努力尝试完成他们的任务。通常，任务需要花费大部分冲刺时间才能完成。 QA 缠着 Dev 发布一些可以测试的东西，Dev 最终在 sprint 结束前一两天向 QA 抛出了一些有缺陷的代码，并用剩下的时间修复 QA 发现的 bug。 QA 永远无法按时完成任务，冲刺很少能按时发布，开发人员和 QA 在冲刺结束时度过了悲惨的几天。
当可发布的开发任务占据了冲刺的大部分时间时，scrum 应该如何工作？
感谢大家参与讨论。由于这是一个非常开放式的问题，似乎没有一个“答案”——下面有很多好的建议。我将尝试总结一些“值得带回家”的观点并做出一些澄清。
(顺便说一句 - 这是放置此内容的最佳位置还是我应该将其放在“答案”中？)
需要思考/采取行动的要点:
- 需要确保开发人员的任务尽可能小(粒度)。
- 冲刺长度应根据平均任务长度适当调整(例如，包含 1 周任务的冲刺长度应至少为 4 周)
- 团队(包括质量检查)需要努力提高估算的准确性。
- 如果最适合团队，请考虑并行但偏移地进行单独的 QA 冲刺
- 单元测试!
最佳答案
我的观点是你有一个估计问题。似乎缺少测试每个功能的时间，并且在规划冲刺时只考虑了构建部分。
我并不是说这是一个容易解决的问题，因为它比任何问题都更常见。但可能有帮助的是:
将 QA 视为开发团队的成员，并将他们更密切地纳入冲刺计划和评估中。
“可发布的开发任务”不应占用大部分冲刺时间。完整的工作功能应该。尝试收集每种任务的开发时间与 QA 时间的指标，并在估计 future 的冲刺时使用这些指标。
您可能需要检查积压工作，看看是否有非常粗粒度的功能。尝试将它们划分为易于估计和测试的较小任务。
总而言之，您的团队似乎还没有找到其真正的速度，因为在进行冲刺的估计和规划时没有考虑到一些任务。
但最终，估算不准确是您在基于敏捷或基于瀑布的项目中发现的一个棘手的项目管理问题。祝你好运。
关于agile - 帮助我了解 QA 在 Scrum 中的工作原理，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/155250/