工作了几年也参加了多个项目开发，经历了好几种的开发模式；有传统的瀑布式，有螺旋式，有迭代式等等开发模式。最近在研究敏捷开发里的XP开发模式并针对这几年的项目开发总结出项目管理的四个持续：持续集成、持续测试、持续重构和持续沟通。
一、 持续集成
持续集成是XP里面的概念，在此我不想将XP里面的Copy出来，要是这样的话就浪费读者的时间了，要是想看的话可以到google上go下。这里我就用我的观点来阐述下持续集成。
持续集成，顾名思义就是一直集成、不间断的集成，一天可能要集成上十次甚至更多，或者说，只要有组员更新代码就要集成。目的就是项目组的成员能很快的知道项目变化。但是你可能会说，这样做不是很浪费时间吗？那是你用手工来做，而必须做到输入一个命令，或者点一下鼠标就能完成代码下载、集成和编译过程，并且编译结果不能出现任何错误和警告。此时，你可能就想到“自动集成”，没错，你可以设定每天的某个时间；像我就是每天7点半自动开机，开机后进行“自动集成”。网上有好几种工具，如：Java的Ant, MS平台的FinalBuilder等等。
持续集成就会使你的项目持续的走向成功，持续远离风险。
二、 持续测试
持续测试和持续集成差不多，也是一直测试、不间断的测试，也是要“自动测试”。程序的每次更新都要自动运行所有测试用例（也叫回归测试），将运行测试用例的结果用Mail形式或其他形式自动的发给项目组成员。目的在于让组员对更新代码的正确性充满信心，而不用担心更新的代码会不会对原来代码产生什么影响，当然了前题是你要有写测试用例。
编写测试用例少不了工具，有JUnit、DUnit等。但是这些工具要嵌入到你的项目开发工具里，并且要有测试用例的模板如：项目工程测试用例模板、单元测试用例模板，不能写个测试用例从头开始吧。
三、 持续重构
持续重构就是持续的对你或组员里的代码进行调整从而改善软件的质量、性能，提高软件的扩展性和维护性。为什么要重构呢？因为要知道一个完美得可以预见未来任何变化的设计，或一个灵活得可以容纳任何扩展的设计是不存在的，现在是一个高速发展的社会，计划是永远赶不上变化的。
需求变更是我们要持续重构的原因。一个软件总是为解决某种特定的需求而产生，时代在发展，客户的业务也在发生变化。有的需求相对稳定一些，有的需求变化的比较剧烈，还有的需求已经消失了，或者转化成了别的需求。在这种情况下，软件必须相应的改变。有一本四个老外写的《设计模式》书，是经典中的经典（作者认为）。写到这里让我想起了以前给程序员培训设计模式说的一句话：设计模式可以让你的生活更美好、身体更健康，是程序员的必备“良药”。
四、 持续沟通
沟通是现在所有软件公司一直提倡，是的，一个项目没有沟通的话，后果“外星人”都知道。而我这里的持续沟通不仅仅是软件工程里面讲的客户沟通、组员沟通等等，而是持续沟通。中国的很多软件企业都存在这样的一种情况就是项目经理不能确切的知道项目的进度和组员的工作情况，持续沟通就是为了解决这种情况。持续沟通是每天、每周、每月直到项目验收为至的沟通会议。（以下是对敏捷方法的Scrum开发模式进行更详细的阐述）
．每天用10~15分钟时间对昨天工作完成情况及今天工作内容进行组员的交流，提出相关问题；
．每周用30~60分钟时间审核项目计划及进度，讨论项目的任务及相关问题；
．每月用1~2个小时来跟踪项目是否按原定的目标进度，使每个组员都了解整体项目的进展情况，
讨论下个月（因为一般来说将一个月作为一个周期）项目进程。
这些沟通会议要以文档的形式放入配置
库，以便以后查阅。
持续沟通也可以作为绩效管理的一种依据。
上面写的几种技术我也会陆陆续续的写在我的Blog上的，如：《用FinalBuilder来构造“自动集成”》（作者是用delphi），《将DUnit嵌入Delphi中并如何设置测试用例模板》，《我对设计模式的一些看法》等等。
文来自CSDN博客，转载请标明出处：http://blog.csdn.net/Oer/archive/2006/09/04/1175236.aspx