Answers:
传达的概念绝对是敏捷和相关的一部分，是将事情推到最后负责任时刻的想法。
但是，所采用的示例实际上是基于一个完全错误的假设开始的：
与使用RDBMS相比，实现平面文件数据库要容易/省力。- 通常完全错误
该示例应为：将持久层保留为最简单的可能实现，直到做出不足的决定。
对于许多开发团队来说，让数据库站起来进行此操作大约需要一两个小时（对于使用ORM的小型数据库而言，则需要15分钟），而他们不需要继续使用的平面文件数据库可能只是一个小问题。巨大的痛苦和烦恼，因为当数据库可能像在UI中创建表，添加几列然后让ORM生成所有内容一样简单时，它们必须手动手写所有寻求和数据表构造类型代码否则你需要。
此外，如果您不知道持久层是如何开始的，那么从团队熟悉的通用RDBMS开始，这是更合适的举动，因为以后从平面文件到RDBMS的更改要大得多。从一个RDBMS更改为另一个。有很多工具可以将大多数常见的RDBMS转换为其他类似的工具，技巧和提示，因为这是一条行之有效的路径。从平面文件转换为任何给定的RDBMS的工具很少，在这些文件中，平面文件具有某些专有格式，而除了您自己的库以外，以前还没有编写过该工具。
总结： 这个概念是正确和准确的，但是该示例基于一个非常大且经常（几乎总是）不正确的假设。
既然您知道您将使用数据库，那么编写代码来处理平面文件并没有多大意义。您可能会使用一些只读CSV进行几次迭代，但是您会很快发现自己编写了知道会扔掉的代码。
您可以通过使用SQLite之类的东西来简化初始复杂性，SQLite是一种类似SQLite的库，它使您可以将无服务器的SQL数据库存储在文件中。它具有灵活的类型系统，因此您不必认真地提交架构，没有服务器可以配置/连接并重建数据库，就像删除文件一样简单。如果需要，它还允许您简单地将DB映像以及代码包含在版本控制中。
这是一个示例，用于演示概念，而不是概念本身。
这个概念是，您直到最后一个负责任的时刻才做出架构决定，但不要迟到。但是，实际上，您经常会对要在很早使用的数据库做出决定。那可能并不完美，但这是事实。
一旦做出决定，您就不会积极回避它。在现有数据库中存储内容通常与将其存储在平面文件中一样容易。
但是，从Linux上的MySql更改为Windows上的SQL Server可能不像从任何地方的平面文件更改为Windows上的SQL Server一样简单。这才是真正的重点。因此，尽管对最终解决方案存有疑问，但应采取最简单的选择，以应对变化。做出决定后，请坚持下去。
什么是你坚持？
我在一个敏捷团队中，对于一个应用程序，我们几乎将所有内容都保存到数据库中。请注意，如果不这样做的话，此应用程序将无法做很多事情-将事情持久化到数据库是其存在的很大一部分。
所以：您坚持什么，您的应用程序做什么？如果应用程序实际上并不关心其数据在何处持久化，那么您可以编写一小层来决定平面文件与数据库的决定（该决定可以存储在某个配置文件中的某个位置）。我认为你需要评估你的应用程序和数据，并决定是否让您的特定情况下，感数据库持久投入时间，或者只是读/写平面文件（这将可能是更快的开发时间方面）。
许多人将敏捷性这一方面误解为意味着他们不应该为未来的功能提前计划。没有东西会离事实很远。您不需要做的就是允许计划将来的功能，以延迟现在为客户提供价值。
它如何适用于诸如持久性之类的东西在很大程度上取决于您的应用程序。我目前的爱好项目之一是计算器。最终，我希望能够存储用户定义的常量和函数，并在关闭程序时保存状态。这需要持久性，但我什至还没有开始考虑采用哪种形式。我的程序在没有持久性的情况下将非常有用，并且现在添加它会大大延迟我的第一个发行版。我希望有一个工作正常的计算器，其功能比根本没有的功能少，而我等待它变得完美。
我的另一个爱好项目是视频和照片色彩校正。如果无法保存正在进行的工作，此应用程序将完全无法使用，并且这样做所需的代码遍及整个程序。如果我从一开始就做不好，那么更改它可能会非常困难，因此我在持久性方面花了很多精力。
大多数项目都介于两者之间，但是如果您现在几乎不需要付出额外的努力，就永远不要为将来的功能计划而感到沮丧。数据库可能很复杂，但是大多数复杂性都隐藏在可靠的，经过良好测试的界面后面。对于数据库来说，您要做的工作可能要比平面文件少得多，因为数据库免费为您提供了所有功能。如果您还不想处理数据库服务器的麻烦，可以使用像SQLite这样的“混合”选项。
我认为您正在将重点放在错误的价值观上。在敏捷中，业务价值是重点。您创建产品是为了向某些最终用户提供业务价值。
如果您创建持久层或在后期进行创建，那么这就是向客户交付业务价值的策略。我认为，“敏捷”一词本身并不能决定您应该选择其中一项。
罗伯特·C·马丁（敏捷宣言的作者之一）在本演讲中提出了关于推迟数据存储策略的观点。
这是一个很好的演示，我建议您观看。
但我不同意！至少在一定程度上。
我不认为您可以将用户故事称为“完成”，如果该用户故事涉及应保留的数据，并且您实际上没有实现任何类型的持久性。
如果产品负责人认为现在该上线了，那您将无法这样做。而且，如果您直到项目后期才开始实施持久性，那么您也将没有有关实现持久性层所需时间的信息，这将给项目带来重大风险。
我从事的敏捷项目并未推迟数据访问策略。但是它已经解耦了，允许我们在此过程中进行更改。整个数据库架构并不是预先设计的。为了实现用户存储的表和列，它们将按照需要的方式进行创建，最终实现业务价值。
平面文件并不简单！
它们允许存储，仅此而已。数据的结构，访问路径等全由您决定，并且有很多方法可以解决此问题。
存在数据库的原因有一个，其中之一就是使开发人员更轻松。
我的大部分开发工作都是为大型公司的大型系统完成的。在进行任何进一步的设计或开发之前，我们始终拥有完整且经过深思熟虑的数据模型。数据模型可帮助您了解问题并允许执行整洁。
通过提前生成数据模型，可以避免遗忘的数据项，不匹配的数据结构和其他噩梦。
您可以保留数据库技术的实际选择，直到出现数据模型为止。但是大多数“持久性”技术都是紧密结合的编程甚至设计风格。如果您为关系数据库编写代码，后来又决定切换到多云键值，那么您将需要完全重新编写一半的代码。
如果您从平面文件开始并切换到关系数据库，您可能最终会丢掉一半的代码，因为开发人员会浪费时间来实现糟糕的数据库。