帮助我了解质量检查在Scrum中的工作方式
显然，我们使用Scrum开发方法。通常是这样的：
Apparently we use the Scrum development methodology. Here's generally how it goes:
开发人员四处奔波，试图完成任务。通常，任务需要大部分的冲刺来完成。质量检查人员（QA）困扰开发人员（Dev）发布他们可以测试的东西，开发人员（Dev）最终在冲刺结束前一两天向质量检查人员（QA）抛出了一些错误代码，并花费其余时间修复质量检查人员（QA）发现的错误。质量检查人员永远无法按时完成任务，冲刺活动几乎不能按时完成，开发人员和质量检查人员在冲刺活动结束时的日子很痛苦。
Developers thrash around trying to accomplish their tasks. Generally the tasks take most of the sprint to complete. QA pesters Dev to release something they can test, Dev finally throws some buggy code out to QA a day or two before the sprint ends and spends the rest of the time fixing bugs that QA is finding. QA can never complete the tasks on time, sprints are rarely releasable on time, and Dev and QA have a miserable few days at the end of the sprint.
Scrum怎么样应该在可释放的Dev任务占据大部分冲刺时工作？
How is scrum supposed to work when releasable Dev tasks take up most of the sprint?
感谢大家在讨论中的贡献。由于这是一个很开放的问题，因此似乎没有一个答案-以下提供了许多很好的建议。我将尝试总结一些要带回家的观点，并做出一些澄清。
Thank you everyone for your part in the discussion. As it's a pretty open-ended question, it doesn't seem like there is one "answer" - there are many good suggestions below. I'll attempt to summarize some of my "take home" points and make some clarifications.
（顺便说一句，这是最好的放置位置还是应该放置的位置？
(BTW - Is this the best place to put this or should I have put it in an 'answer'?)
要考虑或采取行动的要点：
Points to ponder / act on:
- 需要确保开发人员的任务尽可能的小（粒状）。
- Sprint长度应基于平均任务长度（例如，具有1周任务的Sprint至少应为4）
- 团队（包括质量检查人员）需要努力提高估算的准确性。
- 考虑同时进行单独的质量检查冲刺，但要关闭设置是否最适合团队
- 单元测试！
- Need to ensure that developer tasks are as small (granular) as possible.
- Sprint length should be appropriately based on average task length (e.g. sprint with 1 week tasks should be at least 4 weeks long)
- Team (including QA) needs to work on becoming more accurate at estimating.
- Consider doing a separate QA sprint in parallel but off-set if that works best for the team
- Unit testing!
我的观点是您有一个估计问题。似乎缺少测试每个功能的时间，并且在计划sprint时仅考虑构建部件。
My opinion is that you have an estimation problem. It seems that the time to test each feature is missing, and only the building part is being considered when planning the sprint.
我并不是说这是一个容易解决的问题，因为它比任何东西都更普遍。但是可能有帮助的事情是：
I'm not saying it is an easy problem to solve, because it is more common than anything. But things that could help are:
-
将质量检查视为开发团队的成员，并将其纳入Sprint计划和估算中
Consider QA as members of the dev team, and include them in the sprint planning and estimating more closely.
可释放的开发任务不应占用大部分的冲刺。完整的工作功能应。尝试收集有关每种任务的开发时间与质量检查时间的指标，并在估算未来的冲刺时使用这些指标。
'Releasable Dev tasks' should not take up most of the sprint. Complete working features should. Try to gather metrics about dev time vs QA time for each kind of task and use those metrics when estimating future sprints.
您可能需要检查积压的项目看看您是否具有非常粗糙的纹理特征。尝试将它们划分为一些容易估计和测试的较小任务。
You might need to review your backlog to see if you have very coarse grained features. Try to divide them in smaller tasks that could be easily estimated and tested.
总而言之，您的团队似乎尚未找到其实际速度，因为在进行冲刺的估算和规划时没有考虑某些任务。
In summary, it seems that your team hasn't found what its real velocity is because there are tasks that are not being considered when doing the estimation and planning for the sprint.
但是最后，估算的准确性在基于敏捷或基于瀑布的项目中，这是一个棘手的项目管理问题。祝你好运。
But in the end, estimation inaccuracy is a tough project management issue that you find in agile-based or waterfall-based projects. Good luck.