在决定产品开发的软件设计/架构方面需要帮助吗？

Question

关于基于在线网络的软件应用程序，我们在决定产品开发方法时遇到了困难。

我们正在开发有可能作为SAAS服务提供的在线Web应用程序的系统设计。我们在决定以下系统设计和实施相关决策方面遇到了困难，也有很多成本考虑。

方法A：

我们设计和开发所有内容以考虑满足基本要求的非常基本的要求，并解决手头的问题并启动它。一个足够好的系统，可以支持几百个用户，而不必过多地关注微优化一切。

我们通过添加新模块在客户端请求时添加新功能。

因此，简单的设计，单一的开发，在必要时通过升级基础设施或在需要时进行优化来扩展，并且可能在将来根据需要用全新系统替换系统。

我们保留相同的服务器，但客户帐户的数据库不同。同样，为每个客户端托管不同的应用程序访问单独的数据库等。当需要时，我们可能会添加新服务器。虽然很难管理/维护和升级。

方法B：

我们研究完整的要求，可能添加的功能可能会增加额外的价值（虽然我们仍然不确定哪些附加功能会增加多少价值？）并设计支持大量用户的系统（重量级）一套硬件）从一开始。

我们推出功能齐全的应用程序，从一开始就进行了非常优化。

我们将其设计为支持单个数据库和应用程序托管中的多个客户端帐户，并在云服务器/负载平衡服务器上实现它，其架构就像成熟的SAAS应用程序。虽然这使得编码和维护变得非常困难。绝对需要更多时间来实施。

请注意，

我们准备了我们可能正在使用的功能列表，UI和可能的技术设置。我想了解解决这种情况的最佳方法是什么。

正如之前我所看到的另一个产品开发项目，所有功能的集合，花了太长时间才完成，甚至它有这样的功能，根本没有被使用。这些项目的成本考虑非常高，我更倾向于采用方法A，因为这是快速，简单和可预测的。此外，与第二种方法相比，我很快就会收到用户反馈，这可能有助于我决定要关注哪些功能以及原因。此外，当需要时，我们可能会重写整个应用程序，重点关注类似于方法B的系统。

我想了解其他公司如何处理这种情况，以及实施此类项目的最佳方式是什么？

Answer 1

这是经典Big Design Up Front (BDUF)辩论的新版本：我们应该在实施之前完成并完善设计，还是应该逐步设计？

我见过很好的论据pro-BDUF和against-BDUF。就个人而言，我更喜欢中间点：有必要做一些前期设计 - 否则你的设计会通过迭代进行彻底改变 - 但这个阶段不应该花太长时间，否则你只会有一个架构文档和无聊的程序员经过数月的工作。

所以，我会用方法B做一些方法A.

Answer 2

取决于。

经验法则：

• “没什么”比“破碎”好。
• 80％的解决方案总比没有好。
• 前80％将消耗80％的资源。
• 以下20％将占用您资源的80％。
• 如果您没有以80％的价格发货，则其他人会。
• 在达到80％之前，你不知道剩余的20％。
• 环境和要求的变化超出您的想象。即使在应用此规则之后。

不要让他们等待很长时间，运送破损或不可维护的产品，吓跑客户。不要在基础设施上扣钱你不需要（还）。

Answer 3

方法听起来很明智......如果你也可以采用敏捷SCRUM，那就意味着你可以在Sprint中与客户迭代合作，你可以在每个sprint之后开发并交付产品版本和功能。客户可以看到正在交付的软件的较小单元....通常，客户会改变他们想要的新功能的想法。

因此，您总是有机会回应客户需求，并且只构建客户需要的东西。