### 关于软件过程改进论述 - - - - - - 公司管理软件过程的能力比较弱，常常导致项目处于混乱状态。过程混乱，即便是使用最新的技术和工具，其优势难以体现。“阻碍企业发展的瓶颈问题通常不是技术问题，而是杂乱无章的管理。”林锐老师的理论体系中，看到这句话和有关于在企业中进行过程改进的论述，颇有启发。在此也根据林锐老师的论述对软件过程改进的问题加以突出强调。 #### 1、提高软件过程能力的实践 > 软件过程改进是软件工程学的一个主要研究方向，其中CMM/CMMI是该领域举世瞩目的重大成果。 CMM/CMMI是世界范围内用于衡量软件过程能力的标准。但是人们往往搞不清楚“软件过程改进”和“CMMI等级评估”之间的关系。软件过程改进其真正的目的是提高公司的软件过程能力，而不是为了达到CMMI某个等级标准。 把“软件过程改进”比喻为“学英语，提高英语的能力”，那“CMM/CMMI等级评估”就好比是“英语等级考试”。等级考试的成绩并不等价于英语能力。大多数情况下，考试成绩很好的人不见得英语能力就很好，可能是“哑巴英语”。这种“特性”传染到软件领域：不少企业虽然通过了高级别的CMM/CMMI等级评估，但是其实际的软件过程能力却未必很高。 > CMM/CMMI到底是什么？ CMM/CMMI是世界范围内用于衡量软件过程能力的标准，但是CMM/CMMI不是软件过程改进的执行标准，不可能存在适合所有企业的执行标准。就像“英语等级考试”是所有中国大学都认同的评估大学生英语能力的标准，但是“英语等级考试大纲”绝对不是“学好英语的通用标准”。 所以，我们不能把CMM/CMMI直接作为公司的软件过程规范，主要原因是： CMM/CMMI内容之广，之深。其论述了数十个过程域和数百条关键实践，但是这些“过程域和实践”不能与“某个具体企业的具体业务和组织结构”很好的衔接起来。有些企业死搬硬套CMM/CMMI标准，甚至按照CMM/CMMI逐个执行其中的过程域和实践，如同“邯郸学步”，看起来可笑，并不能够包治百病。 > 应该如何应用CMM\\CMMI？ 根据公司的实际情况，我们既要裁剪CMM/CMMI中的一些过程域和实践，又要补充CMM/CMMI中没有涉及的过程域和实践。公司领导和软件过程改进人员必须要明白：公司需要的是一个既符合商业目标，又容易执行的软件过程规范。 裁剪：要分析企业的业务特征，根据自身的人力和财力，选取CMMI中一些精华的部分和重要的东西，舍弃一些不重要的东西。至于什么是“重要的东西”，就要通过它对公司的促进作用有多大来衡量了。 补充：比如，CMM/CMMI对于软件开发和管理过程的论述很深，但却没有涉及“商务过程”，例如没有谈及立项管理、售前服务、售后服务等。这是CMM/CMMI的不足之处。因为企业开发产品的最终目的是把产品给卖出去，赚取利润。如果软件过程规范中不考虑这些因素的话，就会导致开发团队闭门造车，进而开发出“在技术上是很好的，但商业上却是失败的产品”。 #### 2、对软件过程改进的建议 ##### A）各级专家必须“亲自参与”，不能“口头支持” 过程改进不是“办家家”，需要投入很大的人力和物力去做的。软件研发管理过程中所涉及的人员都应该熟悉过程规范，并掌握其技能。各级领导的主要职责是“带领团队完成预定目标”，他们要“亲自参与”过程改进，才能深刻体会过程中的要点，掌握研发管理的方法技能。具体体现在：参与分析问题，商议改进对策；参与制定和自己工作相关的过程规范；参与评审；参加培训学习等。 ##### B）制定的过程规范不求“全面”，只求“实际实用” 凡从事过程改进的人员，他们都希望制定出一套“大而全”的过程规范，能够覆盖所有事务。之后大家可能就会发现，缺乏经验是一个原因，而贪大求全是个错误。站在使用者角度看，过厚的过程规范，看都看晕了，更不用说要去很好地执行了！ ##### C）不过度的迷信标准 对于CMM/CMMI、PMBOK、ISO9000等标准只能够用来参考，而不能过度的迷信于它。从而使公司的目标导向发生了轨道偏移。不能够为了评CMM\\CMMI的更高等级，把CMM\\CMMI看成是“佛经”，来照搬操作，根本不考虑在执行过程是否合理。 ##### D）推行新过程的方式应该是引导，而非强制 自古就有“上有政策，下有对策”的说法。所以，在推广过程规范时不仅要预防成员对此应付了事，还要引导大家正确地做事情。制定过程规范的本意是为了帮助大家把工作做得更好，而不是存难大家。以下是几点对“引导推行”新过程规范的建议： （一）解释规范 过程改进人员不要只是天天埋头拼命写过程规范文档，写完了上缴就了事。应该充分的把公司的内部网站利用起来，在其中设立一个专门解释过程规范的专栏，加大对新过程规范的宣传。关键在于合理的理解与运用。如果不对过程规范加以解释，大家就不能够懂“为什么要学习和执行新过程规范？”，如果不懂“为什么”又怎么能够很好地执行呢？公司上下，如果没有几个人能很好的把公司的项目研发管理体系说得清楚，那就更不用说去很好的执行了。 公司有一部分条款也可能用了“必须”的语气。有些内容可能会损害一些人的利益，但为了统一大局，又不得不做。如果过程改进人员不对此加以清楚的解释，很可能会导致一些本来可以避免的埋怨或争议。对新的过程规范作进一步的解释会带来一些间接性的好处：不合理之处会很快被发现并提出（因为解释不通嘛）。 （二）培训和考核 要对公司全员进行新过程规范的培训与考核，使公司中的每个人都熟悉与自己工作相关的过程规范。只有全员参与，才能够使团队发挥最大的力量。上面说到，公司里的各级经理亲自参与培训和考核要比口头支持作用来的大。 （三）QA人员应监督新过程规范的实施 人都难免存在惰性，如果没有人来监督员工们按照新过程规范来做事，那么自觉性较差的人就可能会回到以前做事的老习惯上。 CMMI中把质量保证称为“过程与产品质量保证”。而其QA人员的职责就是要定期地检查项目成员的“工作过程以及工作成果”是否符合既定的过程规范，来提高和改进“过程质量和产品质量”。 就比如：几乎所有的人都明白基本的交通法规，但是明知故犯的人也有不少，所以还需要很多交通警察来进行监管。而在IT研发中，质量保证人员就是充当交通警察的角色。 ##### E）定义好过程规范中所需的文档 在CMM\\CMMI等级评定中，有这样的规定： > 如果公司实现了过程文档化，就可以达到CMM2级水平。 > 如果公司实现了对过程的文档有文档记录和管理的，就可以达到CMM3级水平。 在公司里推行CMM\\CMMI标准后，一般就会要求开发团队写不少文档。因此，在推广新的软件过程规范时，员工们就会抱怨 “要写的文档太多了，都没有时间”！甚至还有人把进度延误归罪于写文档上。大家抱怨“文档太多了”，估计是因为： （一）过程规范可能太臃肿，规定了太多不必要的文档，如果是这样，那就应该对过程规范做进一步的精简，删除一些不必要的文档。 （二）过程规范所要求的文档本身是适量的，可能是由于以前写的文档太少，一下子还很难适应写文档的习惯。 在新的过程规范中，应尽量想办法将写文档的难度降低，以提高写文档的效率。一要下功夫制定出好而精的文档模板，并给出充足的提示和示例。让使用者 “依葫芦画瓢”，总比他自己在那儿瞎想“该怎样写”要方便得多吧。二要鼓励开发人员经常写文档，才会熟能生巧，以提高其写作能力。 #### 3、软件过程改进的实施方案 第一、调查收集问题，并进行分析。过程改进人员调查企业中与开发、管理、销售、维护/服务等相关的工作人员，分析其反馈重要的问题及其共性问题，收集提出者和各级领导的意见，并共同分析、协商解决其问题的对策。 第二、优化组织结构以及岗位职责。过程改进人员根据调查结果，优化公司组织结构和岗位职责，甚至涉及到重要岗位的人员调整和职权调整。 第三、优化，并制定新的过程规范。过程改进人员帮助公司优化和制定软件研发管理的新过程规范，一般涉及到商务、项目管理、项目开发和相关支持等过程域。（这一步主要参照于IBM公司制定的集成化研发过程——IDP） 第四、整理和部署配套的管理软件。公司应尽量整理和部署与过程规范配套的管理软件，比如：配置管理工具（SVN）、缺陷跟踪工具（Jira）、任务管理工具（My Project）等等。 第五、对全员进行培训和指导。过程改进人员为企业员工提供充分且必要的培训和指导，让员工充分地理解新的过程规范，并掌握其技能。 第六、引导对新过程规范的执行。全体人员根据新的过程规范开展工作，过程改进负责人和QA监督执行情况，并记录问题。然后再周期性地改进过程。