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

EN

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

第一条规则并不建议您轻松地接受更改，，只是您接受对需求的更改将是生活中的一个事实。Ie，你需要决定如何处理这个问题，而不是试图忽略它-)

我建议您将“完成的定义”(您同意的代码必须满足在sprint中被认为是完整的代码)的一部分包含在对DB代码进行更改的要求中。这可能意味着对此代码的更改将获得更高的估计值，从而使您能够在sprint中完成工作。以这种方式，你是开放的改变，并有一个计划，以确保它不会干扰你的工作。

考虑如何减少数据库更改的影响。

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

然后，工作周期变成：

开发人员提交新代码和新数据模型。 持续集成摧毁了测试数据库。 持续集成基于新的数据模型创建新的数据库。 连续集成添加了一些适当的虚拟数据。 连续集成运行一组回归测试，以确保没有任何变化破坏。 团队继续充满信心地工作，相信没有任何事情会被打破。

您可能会觉得编写自动化测试和配置持续集成是对时间和资源的大量投入。但是考虑到回报，你可以很容易地接受项目期间和未来的变化。

这种预先投资以使变更变得更容易，是敏捷方法的基石。