《敏捷软件开发宣言》中有一条：
尽早地，持续地向客户交付有价值的软件对开发人员来说是最重要的。
这句说的是要很快的做出一些功能，然后先交付开发客户使用。
还有一条：
拥抱变化，即使在开发的后期。敏捷过程能够驾驭变化，保持客户的竞争力。
这条是说要拥抱变化，就不用多说了。
那么问题就来了，上一个版本的程序已经部署并且运行了一段时间（不管是
多长时间，一天也好，一个星期也好，一个月也好）。说明用户已经将一些
数据提交到系统中。这些数据对于用户来说，可能是重要的，也可能是不重
要的。但是，如果是重要的数据。敏捷会怎么办呢？
在上一版交付的软件和下一版交付的软件之间，用户提出了要变更数据的处
理方式的需求。这个需求可能涉及到数据结构的变动，以数据存放在数据库
为例，用户的这个需求可能需要在数据库中的某个表上添加或者删除一列。
总结：用户在使用上一版时提交给系统一些重要的数据，在下一版的部署过
程中不能删除这些数据，而数据的处理方式变化了。这样该怎么做？
如果直接将下一版的软件在不变动数据库的方式下部署在客户方，也许这一
版的软件就是不能动作的，极有可能成为废品。这样部署会极度影响公司形
象。
所以，要做到在不删除用户数据的情况下，去升级系统。那么需要做的工作
就会很多，需要先将数据导出用于备份和升级数据库时的数据源。然后再制
作一个数据格式转换程序，将数据转换成下一版本所需要的格式。
这样做，就多了一个程序：数据格式转换程序。也多了很多需要考虑的地方。
有可能拖延项目的进度，耗费人力，物力资源去做这件事情。
其实，数据库中的一列的变化影响并不是多大。但是如果是一个大型系统，
需要和其他系统进行并联。然后就会有很多问题出现。
例如：
1）本系统与其他系统共用一个数据库。那么本系统需要修改数据库应该要
通知并征求他人同意。
2）在大型系统中可能需要重新评估看系统那些功能受到影响。
综上，系统的部署不是次次都必须进行的。正如UP（统一过程）中描述的系
统应该在项目完成了某些实质性的工作后在进行部署，而要符合敏捷开发的
概念就应该尽快的将一些现在完成的功能让客户能看的见。
所以，应该在用户可以很好的了解项目进展的情况下进行，但并不一定必须
交付可用的软件产品。
阅读(1706) | 评论(1) | 转发(0) |
