作为一名从事应用软件开发很多年头的IT老兵，从个人编程、开发小软件，到组织开发大大小小的各类应用系统，从最传统的瀑布模型开始入门，在实践中又接触、使用过不少的软件工程模型、开发过程方法、组织级成熟度模型、管理体系等等，近几年敏捷开发又成为热门??各种各样的新鲜名词和套路也是应接不暇。
面对层出不穷的新生事物，回顾自己多年来的开发经历，发现很多东西确实在不断变化着，而有些东西其实并没有发生根本的改变，而且各自有各自的适用场合。现将有关的观点归纳如下，抛砖引玉，与大家探讨：
1、不变的是工程过程，变化的是管理过程
在所有的软件开发活动中，各种活动可以被归为两大类，一类是工程类活动，一类是管理类活动。这是借用了美国项目管理学会(PMI)在PMBOK中的概念。工程类活动是指那些直接制造产品的活动，这类活动是受到产品生产工艺约束的，是产品制造中的“硬逻辑”，最典型的就是盖楼必须先打地基。管理类活动则是指其他那些辅助性活动，是用来保障工程类活动高效实施的，可以根据各方面因素的实际条件而灵活掌握的，是生产过程当中的“软逻辑”，比如施工工期和资源如何安排、是三人干两个月还是两人干三个月等等。
按照类似的概念，在软件开发当中也存在着这样两种不同的活动——具有硬逻辑特征的软件工程活动和具有软逻辑特征的软件开发管理活动。仔细推敲就会发现，虽然现在各种开发方法名目繁多，但其核心的工程过程并没有发生变化——就是最基本的瀑布式软件工程过程：
2、需求、设计、编码、测试、发布
无论是那种开发方法，无论开发的是大型软件还是一个小功能，无论开发项目组人数多与少，上述这个过程都是始终有效的，这个就是应用软件开发中的“硬逻辑”。但是，围绕这样一个工程过程，在具体实施过程的管理方式上，却可以是千差万别：
l按照上述这个工程过程，一步一个脚印的稳步前行，就是常说的“瀑布式”方法(瀑布式工程过程并不等同于瀑布式管理过程，不能混为一谈，必须加以区分);
l先根据粗略的需求快速实现一个原型系统，然后在此基础上进一步导出正式的需求，再严格按照上述的工程过程实现，就是所谓的“原型法”;
l将整体需求分成许多个部分，反复使用上述工程过程，每一次只实现一部分目标功能，使之能够快速投入使用，从而形成“快速迭代”;
l在互联网速度的推动下，进一步细分需求，并极力促成技术、业务等相关人员的密切沟通，进一步加速迭代，缩短开发周期，大幅提升应用开发的响应速度，这就是“敏捷”;
因此，纵观这些年来软件开发方法的变化，软件产品的制造工艺并没有发生根本性改变，更多的变化则是在制造过程的组织管理方式上不断寻求新的出路，以适应不断提高的快速响应的要求。
既然不同的是管理方式，那么不同的开发管理模式下，开发过程的组织方式自然也就应该有所不同。如果采用传统的瀑布式开发管理过程，那么软件工厂的管理方式可能较为合适，而如果采用敏捷方法，那么软件工作室的组织方式也许更适应(请参见《软件工厂、软件作坊、软件工作室》一文)。
这里顺便说一下对CMMI的看法。作为一个组织级的、系统化的模型，是许多专家的经验教训的结晶，具有非常高的参加价值。在这个模型中试图把各方面相关工作的实质、必须的关键点都识别出来并建立起有机的联系。但是它并没有给出在某个实际环境中的具体操