scrum团队代码超过它可以测试

sprint估计根据测试能力,最终开发者致力于新卡利用时间和空闲。

新工作最后一件事开发人员应该做的。他们已经有了工作,未经测试,他们的承诺做的是创建一个增量。如果需要测试,专业承诺,他们会尽一切努力协助。

sprint结束时,我总是有一个大的用户故事平衡测试,我把他们移到下一个sprint。这最终产生积压,将当前的sprint妥协。

不,它比这更糟糕的是。你侵蚀Sprint边界和透明度的工作,而应该占的产品待办事项列表以及在开发人员的失败和荣誉共享承诺。

问题是,你开始而不是完成工作。而不是弄清楚开发人员可以做些什么来帮助工作全面完成,他们开始新工作和创建一个库存。库存的浪费。此外,他们可以建立这个新的工作上未测试(不完全)或许尚未稳定的工作,所以这是个无足轻重的风险就可以完成返工。

同样的问题,交接是浪费。当你把一个工作单元,把它从一个开发人员一个测试人员,你还需要传达信息除了工作产品。你可以预付,也移交相关文件或你可以即时通过回答问题或解决问题,因为他们出现。不过,无论哪种方式,你需要花更多的时间在确保所有人参与完成工作有相同的理解。

你在一个有趣的位置有相同数量的开发人员和测试人员。大多数组织,我见过更少比开发人员测试专家团队。拥有平等的数字可以打开配对的可能性。对于每个工作单元,一个开发人员和测试人员一起工作从头到尾了解需求,确保它是一个高质量的要求(完整的、一致的、明确的、可测试的),讨论设计和实现理解它如何满足要求,然后测试解决方案开发建设质量。

你可能还想准备组织规模。你会发现这是不可能的或期望的支持同等数量的开发专家和测试专家。有测试专家教basic-to-intermediate测试技能的开发人员可以允许单个开发人员的工作从开始到结束。测试专家可以支持最复杂的情况下,同时继续开发人员之间建立任何跟考试有关的技能。

不管你采取的方法,如果你开始思考或工作需要多少时间团队来完成这项工作,你可能会开始看到更好的Sprint计划事件让你更准确地预测实现Sprint目标所需的工作。

google的早晨,thanths你的帮助,我和我的团队将检查你的命题。