我应该先构建一个功能齐全的应用程序，还是一个简单的应用程序，然后慢慢添加功能？

我在一家制造工厂工作，该工厂负责IT部门创建车间调度程序（非常需要）。根据其他经验，最好花更少的时间来构建可用的基本框架，然后在基础上通过添加功能或通过立即创建完全实现的解决方案来开始构建。我只从事开发工作大约一年，对于最初创建这种大小的应用程序没有太多经验。我一直倾向于这样一种想法：准系统应用程序是第一种应运而生的方法，这是由于对某种类型的数字时间表的极端需求，但我担心在事实之后添加随机功能可能会有些混乱。如果您处在相同的情况下，您会选择哪条路？

经验肯定会导致构建小而简单的东西，并尽早将其提供给用户。根据用户要求添加功能部件。

机会非常好（在某些情况下处于边界），他们想要/要求的东西与您自己（如果有的话）建立的东西很不相似。

至于您添加到原始应用程序时变得一团糟的事情：嗯，这就是为什么敏捷（和大多数类似的方法论）非常重视测试和重构的原因。重构意味着在进行更改时清理代码，并且可靠的测试套件（您每次进行更改都会运行）确保当/当您引入错误时（几乎）立即了解错误，以便在发布某些内容时您向用户保证它确实有效。

您是否知道他们是否认真对待应用程序，然后可能不想构建框架等？

但是，您需要找到一个平衡点。敏捷开发建议您在此阶段专注于应用程序所需要的内容，但这并不意味着您必须通过忽略基本设计来限制自己。有些事情很容易被视为即将到来（是的，经验在这里发挥着作用），而有些事情在此阶段您是无法想象的（我很确定，要求该应用程序的人也无法想象它们）。

我不知道调度应用程序的详细信息，但我可以想象到，“约会类型”很快就会出现。也许人们现在不要求这样做了，否则期望这种功能是不合理的。

我将按以下方式处理这种情况：我将通过在数据库中创建一个表来容纳约会类型来构建基础结构（您提到的框架），但是我不会费心创建接口来添加或选择类型。我将对基本类型进行硬编码，然后继续实际功能。毕竟，没有人要求包括不同类型的约会。

然后，在将来，如果有人找您要求该功能，那么您就拥有了结构，您只需构建中/前端即可。

通常，您没有足够的信息来构建最初完整的程序。测试和客户反馈几乎总是会揭示出初始设计中不如理论上好的部分。

就是说，如果问题得到了很好的理解，并且您能够最初编写完整的程序，那么这样做会更好，因为否则您将不断重构代码，并且结果很少像从一开始就遵循的可靠设计那样干净。

至少，我认为认真考虑程序可能需要的功能类型非常重要。这样，您可以对其进行设计，以便可以轻松地将这些功能添加到现有结构中。

根据个人经验：构建MVP（最低可行产品），然后根据收到的反馈为其添加功能。很容易获得大量功能，而没有任何人使用它们。

解决问题所用的用户体验也很重要。与您的实际用户一起验证您创建的工作流程，然后添加更多功能。通过这种方式，您可以专注于正在建立的核心价值。