简而言之，我正在尝试找到一个用于 Web 应用程序开发的流程/技术堆栈，它易于/快速/灵活地制作原型，但具有通往强大生产平台的清晰升级路径。
对于下面冗长的描述，我深表歉意，但问题在于技术和流程之间，我找不到任何简单/简短的方式来表达它。是的，我读了“主观好，主观不好”的文章。
目前，我们正在使用 Java EE，其中包含所有优点（敏捷、持续集成、问题跟踪、单元测试、hibernate/spring/stripes/jquery 堆栈......）。我们还使用灵活的项目定义/分析过程，与 GUI 模型（对 Balsamiq Mockups 的赞誉）创建和后来的 HTML 静态页面原型并行的特征收集。在开发过程中，我们会经常进行中间构建并进行客户评论。因此，一旦我们进入测试阶段，功能就达到了目标的 90%，所需要的只是一些错误修复和最终的健壮性抛光。
对于我们的传统客户（即银行和制药公司）而言，上述流程/技术堆栈就像是一种魅力。
不过最近，我们正在为互联网初创公司开发。在这种情况下，过程是完全不同的。我们从一些基本模型开始，然后制作第一个非常原始的原型（大量静态页面 + 一些涵盖核心场景的基本功能）。然后我们开始开发完整的应用程序。
关键步骤来了！当应用程序公开时，营销/业务人员会收到来自早期鸟类的反馈，观察竞争，他们做出结论并想要更改应用程序。很多！ 但是此时我们不再处于原型模式，我们有一个很好的健壮、生产质量的 Java EE 应用程序，其中内置了数百个单元测试。我们可以对其进行改进，但它肯定既不简单也不敏捷。
1）在流程方面，我们尝试使用所有可用的可视化和正式工具来确定规范，但徒劳无功；在市场说话之前，没有人能够修复规范。
2) 我们尝试了更“灵活”的环境，例如 RubyOnRails 和 PHP。
2.a) 对于生产级质量，与 Java EE 相比，这些似乎还差一些（是的，我知道一些最重要的服务/应用程序是用 PHP 编写的）
2.b）如果我们以“灵活”的方式使用它们，它们非常适合原型设计，但我们获得的代码很难提高到生产质量。
2.c) 如果我们实现所有最佳实践（分层、单元测试......），复杂性将与我们已经拥有的标准 Java EE 的复杂性相当。
3) 当应用程序上线时，它必须是完善的和健壮的，所以一个易于制作的原型是没有选择的。
4）如果我们提议做一个一次性的原型，客户拒绝将其视为一次性的并要求将其带到生产质量（不愿意从头开始开发）。
因此，基本上，我们将“质量”（预期结构、稳健性）置于流程中太早了，当它不是必需的并且它阻碍了变革和灵活性时。
有任何想法吗？