下面还有很多，如果你想接着比下去的话。不过上面的比较已经能够说明问题啦。

对于软件开发管理持有规范化方法和敏捷方法，究其根源大约是对软件系统开发的本质的认识：软件开发究竟是什么？是工程过程、艺术创造？或是两者兼而有之？如果是这样，在不同的项目中，他们所占的比例有多少，如何界定软件开发中哪些活动是工程过程，哪些却是艺术创造呢？如果都不是，那么会是其他的什么呢？

如果认为软件开发属于工程过程（或者工程过程的成分居多），多半会支持采用规范化的管理方法——已经被传统系统工程、质量控制领域所实践证明的行之有效的方法；如果认为软件开发属于艺术创造（或者艺术创造的成分居多），而艺术创造的管理是很困难的——几乎会采用所谓敏捷式的方法进行管理。但是软件系统的开发是如此的复杂，很难明确界定到底属于哪个范畴（比较实际或是折中的看法是两者兼有，并且在不同项目中比例不同），这决定了对软件开发所采取的管理方法不是一元的——敏捷和规范方式不是零和游戏中的双方，需要根据不同项目的特征来选择不同的方法，或是在一定程度上进行平衡和融合。

对于一个项目选择哪种开发方法，我认为首先需要考虑的因素是“人”：软件系统毕竟是由人开发的，其过程也是人去执行和改进的。谁来决策呢？项目经理、 SE、QA、项目成员采用民主集中制——投票选举、还是遵循公司规范的流程定义或是裁剪指南（如果有的话）？我的看法是谁能够清楚项目的特性、参与项目的开发团队等信息，并且对各种软件开发过程（敏捷式、规范式）、流程中各个活动对整个流程的意义都有充分的认识（基于实践的、而不是仅仅从书本上得来的），这样的人才有资格为即将启动的项目选择开发过程，并且这个人还需要主导（或是重点关注）这个项目的运作，在过程中动态取舍和调整流程活动。当然，他需要对业务有一定的了解，例如一个应用软件项目的主导者不清楚XML和UML的区别，我很介意他是否会将XP（Extreme Programming）方法与Windows XP的开发建立可笑的联系——这样的人不能主导你的项目，如果你期望项目成功的话。你会怀疑公司是否有这样的稀缺资源？我要反问一句：如果公司没有人对流程有透彻的理解，或是不屑于深入项目去了解那些“细枝末节”但是却至关重要的琐事，评什么认为你的项目所遵循流程的质量是合格的？如果向Watts S.Humphrey 所言“软件系统的质量取决于用于开发和改进它的过程的质量”，有问题的过程会指导未来的项目取得成功吗？难道执着追求的CMMI的等级会成为项目成功的倚天屠龙的利器？我看充其量只是不称职的主导者逃避责任的护身符！你可能会认为根据公司现有的流程定义或是裁剪指南、并结合项目的实际情况操作即可，但是我要说的是文档永远只是文档（许多公司的流程定义和裁剪指南自从通过认证那天起再没变过，这东西是否象人参一样时间越长越有疗效？），如果不真正理解它，不真正深入到项目中去，将规范指南看成一个神奇的专家系统：输入的是项目的特性，输出的是理想的项目过程（或者认为不懂流程而“懂”项目的项目经理配合不懂项目而“懂”流程的QA可以完成项目过程的定义——“合格”的零件没有润滑会紧密咬合在一起运作吗？！），我只能惊讶于你对软件系统开发的理解程度的肤浅，并确信项目即将成为死亡之旅！当然一个称职的流程负责人在制定项目流程时会遵循公司相关的原则规范，然而更加重要的是他的聪明才智：对流程和项目的洞察力和宝贵经验，并且对新鲜的方法持有积极的态度，因为对于软件这个领域我们需要知道的东西太多啦！如果你的公司还没有人具备这样的能力，快点培养或是招募吧！没时间？——有的是时间和金钱承受一次又一次失败，而不在培养人上面下功夫，实在佩服这种勇敢的本末倒置的管理！

两种方法——敏捷、规范，他们适用的范围的确不同，这是流程制定者需要考虑的重要因素。在kent beck的《Extreme Programming Explained》一书中提到XP对于10人以下的项目团队可以适用，但是超过20人可能运作困难，当然项目成员需要掌握XP的若干实践和原则，否则还是采用传统的规范方式吧（如果成员加上项目经理都是新手，新的连什么样的流程都不知道，我只能预先为项目默哀啦）。对于指定的项目，成员的技能水平也会影响到参与项目的人数，技能越高，需要的人数越少，那么可以支持的项目的系统规模会相对大一些——毕竟人数减少可以大幅度减少沟通的工作量的支出。小规模的项目中，采取“隐式”的方法进行项目信息的同步，削减工作量支出的好处是诱人的；但是无法想象数十人参与的项目也可以采用同样的方法——大量的变更信息、架构设计等等，毕竟头脑记忆的信息量是有限的，这时候文档会派得上用场。一般说来，系统规模越大，其安全性、稳定性（神州X号太空飞船的控制系统）等方面的要求也较高，用户对需求的认识相对深刻和稳定一些，寄希望于通过简单设计、持续重构和集成等方法保证系统的质量，风险较大；反之，敏捷的方法适用。至于处理需求的不断变更，敏捷方法看来做得不错，规范的方法则可以采用有计划控制的迭代、增量式的生命周期模型，这样除了加快变更的响应速度，也可以尽早暴露技术风险，提高计划的准确性。

但是当前的软件项目的特性并不能严格的符合敏捷、规范方式要求的适用范围，这需要在两者之间互相借鉴，取得一定程度上的平衡：说起来有点玄，其实不然。无论CMM、DoD、RUP、XP、Crystal、还是其他的方法，都是对以前软件项目成功实践的总结和归纳而形成不同的框架，例如象需求管理、配置管理、风险管理、测试驱动、增量式开发都不是什么新玩意儿，甚至比较新鲜的“结对编程”则远在50年代已经有应用的实践了，无所谓君临天下、适用于特性参差不齐的各类项目的统一的佳实践，而只有适用于某类特定项目的过程实践。在确定一个项目的过程时，应该根据实际情况对统一的过程进行修改。如果项目和人员组成的特征更加符合规范式方法的擅长范围，可以将规范式方法作为过程的主体，辅助以适当的敏捷化实践，例如按照需求优先级和技术风险规划版本的开发，让用户更加密切的参与到项目中来；反之亦然，在敏捷化开发中加大架构设计的力度，增加架构的伸缩性，根据业务经验对明显的需求变化及早准备，尽量减少变更成本/时间曲线的斜率，定义里程碑以确定项目的进度等等。在流程制定者真正掌握了其必须的知识（主要是各种方法的适用约束）和项目信息时，其定义的流程才是有效的和有生命力的，而不是机械的抱定某种模式不放，遇到挑战时象王明一样祭出马列原著作为挡箭牌。

流程的认识、定义和改进不是一朝一夕的，但是路却在脚下——“不积跬步，无以致千里”。CMM适时的加上了一个“I”——变成了CMMI，我们可以发现其中增加了“集成团队”、“风险管理”等过程域，更加贴近了敏捷思想（不知道原著者是否同意这种说法）——我们的项目又为何视变化为洪水猛兽？各个软件项目中都充满了特有的风险和不确定的因素，这才使一代又一代精英义无反顾地投入到了充满魅力（当然也充满了荣誉和利益）的IT行业，随着实践经验的积累会增加项目主导者对流程的深入理解，只有这样才能制定出适当的流程，找到规范与敏捷的恰当的平衡点。