Cassandra项目中的敏捷方法和查询驱动方法？

Question

我们想要开始一个新项目。我们的DB将是Cassandra;我们在一个基于敏捷的Scrum团队中完成我们的项目 我的问题是，最重要的问题之一是变化，敏捷可以解决这个问题。

  

敏捷软件开发团队接受变革，接受需求将在整个项目中发展的想法。敏捷专家了解，因为需求随着时间的推移不断变化，所以任何对详细文档的早期投资都将被浪费掉。

但我们有：

  

对这些查询要求之一的更改通常会保证更改数据模型以实现最高效率。

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

Answer 1

  

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

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

我建议您参与“完成的定义”（您同意一段代码必须满足以在sprint中被认为是完整的）以包含更改数据库代码的要求。这可能意味着对此代码的更改会获得更高的估计值，以便您完成sprint中的工作。通过这种方式，您可以随时改变，并制定计划确保不会破坏您的工作。

Answer 2

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

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

然后工作周期变为：

  

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

     

持续集成摧毁了测试数据库

     

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

     

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

     

持续集成会运行一系列回归测试，以确保更改不会破坏任何内容。

     

团队继续努力，确保没有任何事情被打破

您可能会觉得编写自动化测试和配置持续集成是时间和资源的重要贡献。但想想在项目期间和将来接受变革的容易程度的回报。

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