主动触发需求迭代,给予足够的消化时间
导致Diapers项目的现状的主要原因是被动的进行需求迭代,迭代被动的由客户的反馈触发。每次需求迭代都可能打乱团队的开发计划,影响项目的发布,给团队带来更大的发布压力。因此,必须想方设法掌握需求迭代的主动权。
针对每次需求迭代给予充分的消化时间是一种有效的方式。从Diapers项目的情况来看,上一次需求还没有消化处理完毕,新的需求迭代又要开始了。项目发布迭代的速度根本就跟不上需求迭代的速度,新的需求一直步步进逼。在这种情况下,测试工程师压根儿就没有时间对项目进行全面的足够的测试。
找到问题的本质,Diapers项目团队开始调整发布节奏,加大人力资源投入,加快消化需求的速度;针对沟通不足的问题,项目经理集中精力与客户沟通,在双方时间交叉的部分尽量把有疑问的需求沟通清楚;发布节奏调整后,客户就有时间与项目团队同步开展测试工作,bug也能够在第一时间处理。调整后,项目团队有足够的时间来消化每次迭代的需求,也有足够的时间对项目进行测试。
尽早发布原型系统是主动触发需求迭代的另一种有效方式。原型系统通常快速构建,着重在界面的呈现和功能的模拟,通过虚拟数据模拟真实系统的运行情况。其能够在很大程度上模拟未来真实系统的呈现,在短时间内将抽象的客户需求表现出来,作为和客户进行沟通的有效媒介。相对于一堆抽象的文档,使用原型系统,客户更容易尽早发现真实系统与他们的需求之间的差距,减少未来需求迭代的次数。
因此,在需求抽象过程中,应该通过原型系统作为双方沟通的桥梁和媒介,双方应该先就原型系统的呈现展开讨论。另外,原型系统的发布时间也是比较重要的,在项目启动后应该尽早发布原型系统。
Claim项目则是一个商业意外险理赔平台,为北美客户提供商业意外险的在线申报、理赔服务。在项目启动的初期,项目团队在理解抽象需求的基础上,第一时间发布了原型系统,使用虚拟数据模拟真实系统的界面呈现。这个项目比较有利的是,客户自己聘请了需求分析人员,能够最大程度的理解业务需求,正确的表述客户的需求,并绘制详细的原型界面;这点在双方的沟通和系统开发过程中发挥了比较显著的作用。由于Claim项目的需求迭代节奏一直在项目团队的可接受范围,所以项目一直有条不紊的推进,虽然需求也经过了多次迭代,但终归还在可控的范围内。
文章来源于领测软件测试网 https://www.ltesting.net/