这是一个问题.开发人员有某种任务(开发某些功能),这需要大约一个sprint的长度.因此,在sprint结束时,开发人员很高兴,因为他们刚刚完成了他们的部分.
但.该产品不是QAd,因此无法将其区分为"可能可交付",因为它很可能包含一些错误.
所以,问题是:如果没有自动化测试,只有人类QA工程师,那么计划我们冲刺的最佳方法是什么？有一个延迟的冲刺(QA测试在前一个冲刺中开发的项目)？
什么能帮助我们摆脱这种局面？开发人员在质量保证程序中应该做些什么？
Scrum的一个非常重要的方面是在Sprint期间完成"完成"以及完成的定义.如果某个功能在冲刺期间完成,但未经过测试,则仍然无法完成.
你应该不是如何解决这是增加你冲刺的长度.短期冲刺仍然主要是首选.我建议两件事.
第一个非常重要,但不一定容易实现.将QA集成到您的团队中.拥有一个单独的QA部门,在您完成"产品"之后验证您的产品,这真的是瀑布.您可能仍希望在产品发货之前进行质量检查验证,但是在冲刺期间应该完成并测试sprint中生成的内容.要做到这一点,您需要合格的QA人员加入您的团队 - 或者您需要培训开发人员尽可能地进行QA.在我的公司,我们的QA部门太小,所以我们无法为我们的团队获得一些.相反,我们了解了质量保证,并在我们的任务板上添加了一个标题为"准备验证"的栏目.每当一个功能完成时,它就会转移到"准备验证",其他一些开发人员会看到这个.尽管我们可能没有像专门的QA那样熟练,但我们总是以这种方式发现问题,将它们移回修复,然后再次进行验证.这个过程让我们对我们在sprint期间所分类的功能更加自信,以及后来发现的bug大幅下降.
其他的事情是开始定义较小的任务,或者在将功能分解为更小的部分方面做得更好.您不希望处理符合您的esimations的功能可能会占用整个sprint.如果你的"差不多完成"你在冲刺期间真的没有完成任何事情.代替; 将功能分解为更小的部分并逐一解决.当有人正在开发第2部分时,第1部分正在由其他团队成员进行验证,这使得整个开发过程和QA更加集成 - 在sprint结束时更好地调用新功能"完成".
祝好运!