我们想开始一个新项目。我们的数据库将是 Cassandra；我们在一个基于敏捷的 Scrum 团队中完成我们的项目。
我的问题是，最重要的问题之一是变化，敏捷可以处理这个问题。
敏捷软件开发团队拥抱变化，接受需求将在整个项目中发展的想法。敏捷者明白，由于需求随着时间的推移而发展，任何早期对详细文档的投资只会被浪费。
但我们有：
仅对这些查询要求之一的更改将经常保证更改数据模型以实现最大效率。
在Cassandra 数据建模的基本规则一文中。
我们如何管理我们的项目，将这两个规则聚集在一起？第一个接受更改，但第二个希望我们知道将在我们的项目中回答的每个查询。新的需求，导致新的查询，这将改变我们的数据库，它会影响质量（吞吐量）。
我们如何管理我们的项目，将这两个规则聚集在一起？第一个很容易接受更改，但是第二个希望我们知道将在我们的项目中回答的每个查询。新的需求，导致新的查询，这将改变我们的数据库，它会影响质量
第一条规则并不建议您轻易接受更改，只是您接受对需求的更改将成为生活中的事实。即，您需要决定如何处理它，而不是试图忽略它或要求预先签署最终要求。
我建议您将“完成的定义”（您同意一段代码必须满足才能在 sprint 中被视为完整的内容）纳入您的“完成定义”的一部分，以包括更改数据库代码的要求。这可能意味着对此代码的更改会获得更高的估计，以允许您在 sprint 中完成工作。通过这种方式，您可以接受改变，并制定计划以确保它不会干扰您的工作。
考虑可以减少数据库更改影响的方法。
做到这一点的一种好方法是进行自动化回归测试，涵盖依赖于数据库的功能。作为持续集成的一部分，定期构建数据库模式也很有用。这有助于消除对重构数据模型的恐惧，并鼓励您根据需要经常进行更改。
那么工作周期就变成了：
开发人员提交新代码和新数据模型
持续集成拆除了测试数据库
持续集成基于新数据模型创建新数据库
持续集成添加了一些适当的虚拟数据
持续集成运行一套回归测试，以确保没有任何变化被破坏。
团队继续工作，充满信心，没有任何问题
您可能会觉得编写自动化测试和配置持续集成需要大量时间和资源。但是考虑一下你在项目期间和未来接受变化的容易程度。
这种为了使变更更容易而进行的前期投资是敏捷方法的基石。