项目中的敏捷方法和 Cassandra 中的查询驱动方法？ [关闭]

Question

我们想开始一个新项目。我们的数据库将是 Cassandra；我们在一个基于敏捷的 Scrum 团队中开展我们的项目。
我的问题是，最重要的问题之一是变化，敏捷可以处理这个问题。

敏捷软件开发团队拥抱变化，接受需求将在整个项目中不断发展的想法。敏捷者明白，由于需求随着时间的推移而发展，任何早期对详细文档的投资只会被浪费。

但我们有：

仅更改其中一项查询要求通常需要更改数据模型以实现最大效率。

在Basic Rules of Cassandra Data Modeling 文章中。
我们如何管理我们的项目，将这两个规则聚集在一起？第一个接受更改，但第二个希望我们知道将在我们的项目中回答的每个查询。 新要求，导致新查询，这将改变我们的数据库，并影响质量（吞吐量）。

Answer 1

我们如何管理我们的项目，同时收集这两个规则？第一个很容易接受更改，但是第二个希望我们知道将在我们的项目中回答的每个查询。新的需求，导致新的查询，这将改变我们的数据库，它会影响质量

第一条规则并不建议您轻易地接受更改，只是您接受对需求的更改将成为现实。即，您需要决定如何处理它，而不是试图忽略它或要求预先签署最终要求。

我建议您在“完成的定义”（您同意一段代码必须满足的条件才能在 sprint 中被认为是完整的）中包含更改数据库代码的要求。这可能意味着对此代码的更改会获得更高的估计，以允许您在 sprint 中完成工作。通过这种方式，您可以接受改变，并制定计划以确保它不会干扰您的工作。

Answer 2

考虑可以减少数据库更改影响的方法。

实现此目的的一个好方法是进行自动化回归测试，涵盖依赖于数据库的功能。作为持续集成的一部分，定期构建数据库模式也很有用。这有助于消除对重构数据模型的恐惧，并鼓励您根据需要经常进行更改。

工作周期就变成了：

开发者提交新代码和新数据模型

持续集成拆除测试数据库

持续集成基于新数据模型创建新数据库

持续集成添加了一些适当的虚拟数据

持续集成运行一套回归测试，以确保更改没有破坏任何内容。

团队继续努力，没有任何问题

您可能会觉得编写自动化测试和配置持续集成需要耗费大量时间和资源。但是考虑一下您在项目期间和未来接受变化的难易程度。

这种为了使变更更容易而进行的前期投资是敏捷方法的基石。