一个常见的开发挑战是在创建新的应用程序时准确地确定所需的工作量。这可能发生在应用程序的需求刚开始设计的时候，甚至之前。由于服务虚拟化最经常被忽视的能力之一是直接从初始用户故事中快速原型化和测试新服务影响的能力，我今天要解决这个问题。
“没有所谓的范围蠕变，只有范围驰骋。”
——Cornelius Fitchner
在应用程序的生命周期之初，团队就会开会讨论代码应该做什么。通常情况下，围绕着一个新应用的可行性会有很多问题，而开发者的负担就落在了指明某事是否可能，并确定所需努力的范围。
当处理新技术或全新的想法时，这可能非常困难或几乎不可能。开发者必须凭空拉出一些（希望是准确的）努力程度。服务虚拟化在这里可以提供帮助的方式是，让任何人都有能力快速开发服务的原型，甚至不需要那么多的服务合同。基本上，开发人员可以从头开始构建服务，以简单地回答“如果”问题。
利用服务虚拟化，开发人员可以通过建模来实现这一目标。通过Parasoft Virtualize，开发人员可以选择在什么类型的协议上部署服务，基本上是以功能上的空白画布开始。在实际开发中，开发人员必须建立一个框架，这甚至需要许多行代码才能开始以所需的方式运行。相比之下，服务虚拟化允许任何人在没有代码的情况下快速地对预期的应用行为进行原型设计，根据需要建立起小片的功能行为。
例如，您可以通过向响应中添加元素来创建服务，然后选择性地添加额外的数据来响应。然后，您可以添加逻辑，其中某些类型的请求将从服务中接收特定的响应，并将其扩展以产生所需的应用行为。通常在几分钟内，用户就可以创建一个服务，呈现实际应用所需的功能，并即时评估价值和环境影响。这节省了大量的时间，而且，在Parasoft Virtualize中，不需要编写脚本。
这种能力极大地扩展了开发团队交付技术需求的能力，并准确地按期确定努力程度的范围，这对于敏捷团队来说尤其重要，因为产品所有者和scrum团队之间会产生固有的生产力债务。scrum团队需要根据自己的能力，交付适当数量的故事点，他们可以承诺。产品所有者需要传达他们对所需功能的愿景。然后团队将开始根据他们对期望的理解来确定交付所需的努力程度。但如果团队交付的功能与客户的愿景不一致怎么办？他们必须重新开始这个过程。提前对应用程序的功能进行原型设计，可以让他们减少获得正确功能所需的周期数。
例如，当任务是创建一个将返回用户信息的API时，通过在模拟中使用原型设计，开发人员可以快速决定他们在开始与API集成时，希望他们的响应模式是什么样子的。如果他们注意到这给下游带来了开发挑战，并且有必要改变元素的顺序，他们就不必为此重新编写代码。他们可以简单地将元素拖动到正确的顺序，然后自己重新部署虚拟服务。
此外，开发人员还可以通过在虚拟服务中设置现实的性能配置文件来评估这个新服务将给环境带来的性能影响。
通过对服务进行原型设计，开发团队甚至在编写一行代码之前就能指出应用将引入复杂性的领域，从而快速、持续地向利益相关者提供真实的信息。它们还为测试团队铺平了道路，让他们在服务存在之前就开始设计针对服务的测试。