CMM是过程流派的产物. 而OO的思想是倾向于目标式的思维方式. 有人认为两者是风马牛, 但程序员自己设计的时候用的是OO思想, 而被管理的时候是过程化的. 而且要写这么多罗索的文档, 推行起来有困难很正常. 我通常会打个比方, 我们的程序出问题了, 而又不知道问题在哪一定是用工具 Debug, 但复杂的系统通常只能用 Log. CMM倡导的各种文档就是相当于 Log. 有了这些文档才能做项目改进分析.
对于我所在的公司来说没必要过CMM, 只是借用它的思想和办法. 首要的问题就是CMM的界限, 边界. CMM是对项目整个生命周期进行过程跟踪. 它抹杀了个人英雄, 但也在一定程度上会抑止一些创造性的火花. 通常以技术为主或者产品不是很固定的公司难以实现这种管理方式. 而在那些应用为主的公司则非常重视. 对于创造性较强的项目, 就应该减少过程化管理的程度, 在项目趋于稳定时, 加强这方面的管理以提高产品的质量. 就我所在公司的情况, 一半是前者一半是后者. 我们对于新的项目有比较完整的文档管理. 稳定以后, 只在系统迁移的做文档记录. 对于抢时间的项目, 我们通常只进行最基本的文档记录, 重点是数据库字典. 其它文档一律后补. 这样保证以后能维护而又使项目准时完成. 明确 CMM 才能正确的使用它.
其实软件改进过程里面最重要的还是人. 特别使中小型的公司, 能把握住人, 公司才能生存. 毕竟文档都是人写的. 把人培养好, 公司甚至可以没有管理. 当每个员工都积极参与公司事务时, 管理制度就消失了. 我在第一家公司的时候, 曾经一度呈现这种状态. 那时候, 公司深恐待薄员工, 员工都珍惜自己的岗位. 回头思考, 发现有很多问题当时都在上层没有发现的时候解决了. 当一个问题出现时, 很快就会传播到每个下层员工的耳里. 问题解决后, 同样的传播开. 初看好像耽误一些员工手里的活, 其实从整个公司的效率来看绝对是很高的. 当时真有点无为而治的感觉. 所以, 首先有好的管理模式和用人机制, CMM 才能发挥作用. 而管理的关键在于知. 篇幅有限, 就写到这.
对于我所在的公司来说没必要过CMM, 只是借用它的思想和办法. 首要的问题就是CMM的界限, 边界. CMM是对项目整个生命周期进行过程跟踪. 它抹杀了个人英雄, 但也在一定程度上会抑止一些创造性的火花. 通常以技术为主或者产品不是很固定的公司难以实现这种管理方式. 而在那些应用为主的公司则非常重视. 对于创造性较强的项目, 就应该减少过程化管理的程度, 在项目趋于稳定时, 加强这方面的管理以提高产品的质量. 就我所在公司的情况, 一半是前者一半是后者. 我们对于新的项目有比较完整的文档管理. 稳定以后, 只在系统迁移的做文档记录. 对于抢时间的项目, 我们通常只进行最基本的文档记录, 重点是数据库字典. 其它文档一律后补. 这样保证以后能维护而又使项目准时完成. 明确 CMM 才能正确的使用它.
其实软件改进过程里面最重要的还是人. 特别使中小型的公司, 能把握住人, 公司才能生存. 毕竟文档都是人写的. 把人培养好, 公司甚至可以没有管理. 当每个员工都积极参与公司事务时, 管理制度就消失了. 我在第一家公司的时候, 曾经一度呈现这种状态. 那时候, 公司深恐待薄员工, 员工都珍惜自己的岗位. 回头思考, 发现有很多问题当时都在上层没有发现的时候解决了. 当一个问题出现时, 很快就会传播到每个下层员工的耳里. 问题解决后, 同样的传播开. 初看好像耽误一些员工手里的活, 其实从整个公司的效率来看绝对是很高的. 当时真有点无为而治的感觉. 所以, 首先有好的管理模式和用人机制, CMM 才能发挥作用. 而管理的关键在于知. 篇幅有限, 就写到这.
