SAR*_*VAN 14 agile scrum process
我一直在使用瀑布模型作为.net开发人员.在工作时,比如12个月的项目,我的团队通常会遵循分析,设计,编码和测试阶段.但是当谈到Scrum流程时,我并不真正理解我需要如何处理它.
考虑冲刺4周,积压有10个项目.让冲刺现在开始.如果开发人员在前10天处理一些积压项目,我不知道测试(SIT和UAT)是否需要在剩余的10天内完成工作.现在我们的sprint没有时间做最后一分钟的错误修复,只有少数错误可以在PLANNED SPRINT中修复.
当我们进行开发时,我们如何才能确保我们让测试团队忙于准备测试用例并等待我们提供功能？
如果我们需要在sprint的前3天内提供第一个任务/功能,这就提出了一个问题,以便测试人员可以准备好测试用例来测试该部分.
我还需要教育我的客户帮助调整Scrum流程.
我需要一些指导原则,参考资料或案例研究,以确保我们的团队遵循适当的Scrum流程.任何帮助,将不胜感激.
Pas*_*ent 14
在理想的Scrum团队中,测试人员和开发人员是团队的一部分,测试应该与开发并行进行,阶段是重叠的,而不是顺序的(在Sprint中按顺序执行是一种称为Scrumerfall的反模式).顺便说一下,与此处表达的一些观点相反,最终的Scrum实现会产生DONE DONE故事,所以测试 - 包括IST,UAT - 应该在Sprint期间完成.
不,测试人员不必等待产品积压项目(PBI)完全实现以开始他们的工作,他们可以开始编写验收测试scenarii,自动化它们(例如使用FitNess),设置测试数据集等(一旦Sprint启动,这需要一些时间,特别是如果业务复杂).
当然,这需要非常密切的协作,并且尽早释放界面或UI骨架将有助于测试人员的工作,但是,测试人员仍然不必等待PBI完全实现.实际上,开发人员应该使用验收测试作为DONEness指标("我知道我在接受测试时已经完成了")1.
我并不是说这很容易,但这就是成熟(即精益)Scrum实施和成熟的Scrum团队正在做的事情.
我建议Henrik Kniberg 从Trenches阅读Scrum和XP,这是非常好的实用指南.
1正如Mary Poppendieck所写,测试人员的工作应该是防止缺陷(必要),而不是发现缺陷(浪费).
你绝对不希望在sprint的前半部分进行所有开发,在下半部分进行所有测试.那只是一个较小的瀑布.
您的故事和任务应该分解成非常小的,独立的功能.(可能需要一段时间才能习惯这样做,特别是如果您正在使用的软件是像我之前使用scrum的工作那样的整体野兽.)在sprint开始时,测试人员正在开发他们的测试和开发人员正在开发他们的代码,并在整个sprint中完成和测试任务和故事.他们之间应该有相当不断的互动.
当你习惯了这种方法时,冲刺的结束可能会让你感到有些忙乱.开发人员在处理其余代码时会感到负担,同时还会被测试人员修复.测试人员会变得不耐烦,因为他们看到sprint的结束迫在眉睫,而且还有尚未经过测试的代码.有一个学习曲线,需要一些习惯,业务需要意识到这一点.
重要的是开发人员和测试人员真正合作创建他们的估计,而不仅仅是添加彼此的数字以形成总数.开发人员需要意识到他们不能计划在最后一刻之前编写新功能,因为这会让测试人员在周末离开他们的工作,这将最终落后于开发人员在和修理东西等
有些任务需要在此过程中重新定义.一些故事将在冲刺结束时失败.没关系,你会在下一个冲刺中得到它.每个sprint开始时的计划会议将定义这些故事/任务.记住要彼此保持耐心,并确保业务对过程中的变化耐心.从长远来看,它将获得回报,而不是第一次冲刺.
sprint不会以完美的代码结束; 如果还有剩余的错误,他们可以进入下一个冲刺阶段,并且需要将下一个冲刺中的其他一些项目取出.你不是用一些完美的东西来阻止冲刺,但理想情况下,你可以用稳定的东西来阻止冲刺.
(具有讽刺意味的是)你对这个过程施加了过多的严谨性.像scrum这样的敏捷过程的重点是时间表是动态的.在第一次sprint之后,您将与用户/测试团队一起评估进度.此时,他们会要求您更改第一个sprint中提供的详细信息和功能,否则他们会要求您执行更多工作.这取决于他们.
只有最终,一旦你确定了团队的速度(即,在sprint中可以合理完成的故事数量),你就可以开始为大型项目估算日期和事物