在我的上一份工作中，我与一家公司合作，该公司从没有方法学转向使用Scrum / Agile方法。遇到了许多问题，包括Scrum的“专家”确实不知道如何有效地实施Scrum。
他们使用的计划相对简单：
1.开始Sprint计划会议，其中QA和Dev时间的估计是一个估计-不是一个QA时间和一个Dev时间。
2.当估计的时间达到Sprint的总数时，不再向该Sprint添加任何功能。
主要问题是质量检查人员通常不知道开发人员如何编写代码……毕竟，他们不是编码人员！因此，质量检查团队确实没有任何依据可以对时间进行合理的估算。相反，99.9％的开发人员不知道健全性测试，功能测试，回归测试和UAT测试之间的区别...。因此，他们也无法准确估计某些功能所需的QA时间。
最终，我为QA团队采取了行动，并把这种担忧带到了管理层。在那儿，我因无法在Scrum环境中工作而被立即解雇，但这实际上不存在。
但这确实使我想知道这里的错误是什么。是我的问题很刻板，想让事情变得艰难，还是期望质量检查人员天生就知道应该花多长时间编写代码？
最佳答案
我去过QA和Dev。在任何一个世界中，这个过程实际上并没有太大的不同，因为它可以归结为一个简单的事情：所有估计都是猜测。它们是基于经验，预感以及对一系列特定问题的复杂性和风险的评估，但充其量只能是一个很好的猜测。
您可以通过分析围绕特定功能区域的一组已知任务来使它们更有用。在质量检查中，这意味着要从可用的角度看问题：分析任何可能的用户故事中的变化，如果您有屏幕模型，则分析可能的输入，等等。根据对手动或自动运行这些变体要花费多长时间的更好猜测来进行一些基本的算术运算。制作一个二维矩阵，显示一些基于粗糙等效类的关键方案，弄清楚将要花费多少时间：a）根据先前的经验为每个项目编写自动化测试，以及b）进行手动烟雾测试（如果需要） 。
找出您需要在预定时间范围内运行这些测试的频率。根据判断中的错误概率（1.5倍，2.0倍，有时是3.0倍）以及正确纠正错误的相对重要性来运行乘法器。如果对一个功能进行良好的测试确实很重要，而对另一个功能进行良好的测试不太重要，则可以相应地调整估计值，但请在估计中确定该假设。
计划是关于管理风险，而不是消除风险。这是为了让您全面了解需要做什么。详细信息永远都不正确，没关系。我无法想到在我从事的项目中，有一次一切都按计划进行，尤其是在开发方面。
敏捷并没有太大地改变方程式。它确实改变了时间线。尽管存在一些教条，但这是一个好主意，即使在周期结束时也要确保有一点测试空间，因为您还需要开发时间来解决不可避免地会出现的问题。但是您不必将其转变为“小瀑布”。开发人员可以在所有功能均正常运行的情况下继续工作，因为他们总是可以开始挑选迭代中优先级较低的任务。
我想知道，对于您而言，开发团队是否代表您进行质量检查时间估算？让其他人打电话通常不是一个好主意。游戏中皮肤最多的人应该拥有最重的观点。但是许多开发人员可以做出很好的风险评估，因此值得一听。在敏捷开发周期中，理想情况下，角色排他性应该比瀑布团队小，但是我相当相信，有些人在质量保证任务上干得更好，即使在一个试图做到这一点的团队中，他们也自然会接手大部分工作。走敏捷的思想。如果您的问题是在不知道实现细节的情况下不愿进行估算，那么我可以说这是您需要克服的问题；即使在老式的方法论中，我也很少拥有完整的知识。
我要补充的一件事是：具有质量检查才能的人员应该与开发人员处于同一团队中。如果他们的专业发展由不同的经理来管理是可以的，但是如果他们是不同的冲刺团队的成员则可以。因此，以我的拙见，如果您有一个“测试团队冲刺”和一个“开发团队冲刺”，那么您将削弱以开发人员和质量保证为重点的资源之间进行协作和交流的潜力。
关于methodology - 质量检查人员应如何准确得出估算结果？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/3144805/