CMMCMMI不是软件企业唯一的选项8.docVIP

CMM/CMMI不是软件企业唯一的选项 一边按照CMM/CMMI做各种需要的文档，一边还在按照老传统做什么调研、方案设计、调试，跟CMM/CMMI并不合拍。这是问题之一。 CMM/CMMI是一个评估的依据，也是一个过程改进的框架，并不是一个标准。这是问题之二。 CMM/CMMI体现了西方的“三权分力”的思想。SEPG相当于立法机构，而软件项目组相当于行政机构，SQA人员相当于司法机构。三者相互制约。这种软件项目经理和技术主管职位不分、职责不明的做法怎么能够做好CMMI? 这是问题之三。 CMM/CMMI不是为软件研究性项目设计的，而是为产品项目设计的。需要搞清楚你的项目是研究性的，还是产品性的，不要盲从CMM/CMMI。这是问题之四。 CMM/CMMI不可以以强权方式实施。不能越级做CMM/CMMI。需要收集不同项目的过程实践经验，经总结分析才能形成组织的过程。这是问题之五。 实施CMM时必须解决的认识问题 在企业的开发能力中过程、技术(含工具、方法)、人员都是主要的因子，都需要全面提高，只关注一个方面，而忽略了其他方面，都是有害的。 在开始实施CMM时，最容易犯的一个错误就是唯管理论或孤立地只抓过程改善，忽略了开发技术与人员的提高，过分强调管理的作用，实施了半年或一年后，发现企业的生产能力并没有得到明显的改善，这时反对的声音就会成为主流，过程改善就难以继续进行了。 管理就是预防，管理的作用是隐性的，不都是立竿见影的，大家要有耐心。在实施CMM时，企业的管理层在开始时往往会对过程改善期望值太高，希望短时间内效果显著，上面我们谈到了，效果显著与否不是由一个方面的要素决定的，需要多个因素共同改善。而管理的最大作用是预防，防患于未然。 任何的管理的改善都是符合J曲线的，即在改善的初期企业的运行效率可能会下降，甚至可能会出现一些混乱的局面，不过渡过了这段时间就会看到效果。所以在改善的初期大家要有这个思想准备，要有耐心。 坚持活学活用，以我为主。机械照搬CMM的条文是在实施CMM时常犯的错误。CMM是软件工程经验的集大成，是从实践中总结出来，用以指导实践的，CMM本身也在更新版本，不断完善。每个企业都有自己的特点，就象微软的MSF，那是微软自己内部的管理过程标准，是微软的产品开发经验总结，有些内容是CMM中没有的，完全可以借鉴过来使用，所以只要可以提高企业自己的软件管理水平，就应该大胆地来尝试。 要改良式不要革命式。让大家在小步快跑中接受变革，这样风险最小，效果最好。期望在短期内通过CMM评估，单纯追求市场上的轰动效应。恐怕由于没有实效而得不到大家的认同而难以将这种水平持续下去。一个企业引入CMM之后会从本质上影响企业的文化，改变大家的思想与做事方法。 CMM与企业的创新文化是不矛盾的。企业在推行CMM时，过分机械，没有从实际出发，不能与实践紧密结合，挫伤了开发人员的积极性。软件企业必须形成创新的文化，事实CMM本身也一种软件工程管理的创新，而技术创新是必须进行管理才能使其有效地转化为生产力，转化为企业的实际效益，达到效益最大化，这是最根本的。 要勇于实践，也要允许犯错误。CMM就是软件工程经验与教训的总结。在实施CMM的过程中，肯定会走些弯路，甚至于要犯错误，由此许多人会议论纷纷，一直会反映到高层经理处，这时不要犹豫，要敢于尝试，更不能因为有困难就打退堂鼓，现在大家都是摸着石头过河。要少说不，少说难，勇于实践，有错就改。对于软件企业的领导尤其要注意这一点，不要因为在过程中的一些实践失败，就对项目经理、SEPG等人员有偏见，要提倡这种文化。管理过程改进是组织内所有人的事情，而并非仅仅是SEPG的事情。按照CMM专家的建议，在一个组织内专职从事软件过程改善的人数应为组织总人数的2-3%，根据这一建议，我们企业内一开始就配备专职的软件工程过程组（SEPG），这些员工专职负责企业的软件过程改善工作，另外我们根据需要组织一些技术任务组（TWG），他们会兼职的参与特定过程规程、标准的制定、试点和修改完善工作。在这种情况，可能会出现如下的问题： SEPG成了最忙的人，TWG的任务往往会由于那些兼职的人员以工作忙为理由一拖再拖，最后还是由SEPG的成员替代TWG做工作； 企业的非开发人员对管理过程改进的效果一下没有明确地感受到，甚至看到由于加了些新的活动可能使项目拖期可能会更严重，于是他们可能就会将这些抱怨反馈到企业的高层经理，在推行过程中经常会听到：我这个项目时间太紧，当前不适合使用CMM； 高层经理迫于市场的压力，甚至可能会提出不合实际的项目工期等等。推行CMM不仅仅是管理人员的事情，每个人都要积极参与。要改变原来的一些做法：即SEPG是在使劲的推进CMM的工作，而不是大家自觉自愿的来实施CMM。从SEPG的角度来看，要做好培训的工作，