过去几年中，我们将敏捷方法应用于数据库设计，总结出一些技巧，使得当应用程序发展时，数据库也能够进化，这是敏捷方法的一个重要属性。我们的方法是通过持续集成以及自动重构，通过数据库管理人员（DBA）和应用开发人员的紧密合作来设计数据库。这些技巧在应用开发的各个时期都有效。

　　1 敏捷方法学

　　近年来，出现了一种新的软件开发方法学——敏捷方法学。这给数据库设计提出了一些新的、巨大的需求。这些需求的一个中心是进化设计。在一个敏捷项目中，需要假定我们并不能事先确定系统的需求，因此在项目的初期有一个详细设计阶段的想法是不现实的。系统的设计必须随着软件的变化而进化。敏捷方法，尤其是极限编程（XP），通过一些实践使这种进化设计成为可能。在数据库设计采用敏捷方法，反复迭代。

　　许多人会怀疑敏捷方法能否用于有大型数据库组件的系统，但我们的确使用了许多敏捷和XP技巧，用于解决基于大型数据库的项目中的进化与迭代问题。

　　本文将介绍一些在数据库设计采用敏捷方法的实践。当然，这并不是说我们已经完全解决了数据库进化的问题，但是我们想提供一些行之有效的方法。

　　2 积极应对变化

　　敏捷编程的一个显著特点是它面对变化的态度。对软件过程的一般解释是尽早理解需求，停止需求的变动，将这些需求作为设计的基础，停止设计的变动，然后开始构筑体系，这是瀑布方法——基于计划的生命周期。

　　这种方法通过大量的前期工作来减少变化，一旦前期工作完成，需求变化会引起很大的问题。当需求变化时，这样的方法会有很大的问题，因此需求变动是这种过程的一个很大的问题。

　　而敏捷编程却以另外一种方式来面对变化、拥抱变化，甚至允许在项目开发的后期发生变化。尽管变化会被控制，但是这种态度会允许尽可能多的变化。变化部分来自于项目需求的不稳定，部分来自于要支持变化的商业环境来面对竞争压力。

　　为了做到这样，必须采取不同的设计态度。设计不仅仅是一个阶段——在开始建筑之前大部分完成的一个阶段，设计是一个持续的过程，与编码、测试甚至发布相关，这是计划设计与进化设计的不同之处。敏捷方法的一个重要贡献是提出了在可控制方式下的进化设计，提供了控制进化设计和使其可行的技巧。

　　敏捷方法的一个重要特点是迭代式开发，即整个项目生命周期中运行多个完整的软件生命周期循环。敏捷过程在每次迭代中都会度过一个完整的生命周期，迭代可以完成终产品的需求子集中编码、测试以及集成代码。敏捷方法迭代时间较短，通常是一周到两个月之间，而且我们更倾向于更短的迭代周期。

　　当使用敏捷方法时，大的问题是数据库如何进行进化设计。许多人认为数据库设计是前期计划的工作，而在后期改变数据库设计计划会引起应用软件的崩溃；在配置以后改变数据库设计计划会导致数据迁移问题。

　　在过去三年我们参加了一个大型的项目，其中用到了切实可行的进化设计的方法。该项目包括100人的项目组，200多张表格，数据库在一年半的初开发中一直在进化，甚至在为多用户分发的过程中也在进化。一开始我们一个月迭代一次，过了几个月之后变为两周迭代一次。

　　随着我们将这些经验推广到项目中越来越多的部分，从越来越多的案例中获得经验。同时，我们也从其他敏捷项目中吸收了一些经验。

　　2.1 限制条件

　　在讲述实践方法之前，必须指出我们并没有解决所有的数据库进化设计问题，特别是：

　　(1) 我们是为单独的应用设计一个应用数据库，而不是试图集成多个数据库；

　　(2) 我们没有做到24*7的数据库更新。

　　虽然很多人认为我们无法解决这个问题，但其实这些问题是可以解决的。当然这需要进一步的工作，光说是不能解决问题的。

　　3 实践

　　我们有关于数据库进化设计的方法依赖于一些重要的实践。

　　3.1 数据库管理人员与开发人员紧密合作

　　敏捷方法的一个重要原则是拥有不同技能和背景的人能够紧密合作。正式的会议和文档不能达到充分交流的效果，因此他们需要一直一起工作、亲密合作。所有的项目组成员都需要紧密合作：系统分析人员、项目经理、行业专家、开发人员以及数据库管理人员（DBA）。

　　开发人员的每项工作可能都需要DBA的帮助，开发人员和DBA需要考虑是否需要对数据库计划做很大的改变。开发人员向DBA咨询如何应对变化：开发人员知道需要什么新的功能，而DBA对应用中的数据有全局的观念。

　　为了达到亲密合作的效果，DBA必须使自己易于接近。DBA需要留出几分钟的时间，让开发人员来提问。必须确保DBA和开发人员坐在一起，这样他们很容易沟通。同时必须确保应用设计会议是公开的，这样DBA可以随时加入进来。在很多情况下我们发现人们在DBA和应用开发人员之间建立屏障，这些屏障必须去除，这样进化数据库设计才有可能。