第1章-研发管理和过程改进的概念教学教材.doc

集成化软件研发流程IDP 5.0Integrated Development Processes第1章 研发管理和过程改进的概念上海漫索计算机科技有限公司1.1 研发管理的概念31.2 过程改进的概念41.2.1 什么是过程？为什么要重视过程？41.2.2 什么是过程改进？企业为什么需要过程改进？51.2.3 软件过程改进和CMMI之间的关系61.2.4 有了CMMI为什么还要研制企业的过程规范？71.2.5 如何应用CMMI？71.3 过程改进的实施建议81.3.1 各级领导“亲身参与”而非“口头支持”81.3.2 制定“合适”而非“大而全”的过程规范81.3.3 不要迷信所谓的标准91.3.4 “引导推行”而非“强硬推行”91.3.5 写好必要的文档111.4 研发管理的过程改进方法121.1 研发管理的概念企业的根本目标是“合法地赚取尽可能多的利润，使企业整体利益最大化”。企业所有的特定目标和行动（例如研发、营销等）都是围绕根本目标开展的，不能和根本目标抵触。企业研发管理的指导思想是：关注结果，重视过程。 “关注结果”是指：以最终产品获得的经济效益来衡量研发业绩，追求利益最大化。 “重视过程”是指：将期望的成果分解到每个过程域（即工作环节）去实现，努力把每项工作做好，从而得到好的成果。衡量研发工作优劣的三个关键指标是：质量、生产率和成本。人们在工作的时候总是希望：做得好（即质量高）、做得快（即生产率高）而且少花钱（即成本低）。如果出现三者难以同时兼得的情况，那么决策者一定要搞清楚质量、生产率、成本之间的复杂关系，判断孰重孰轻，给出优化和折中的措施。企业研发管理的目标： 基本目标：让所有人员有条不紊地开展工作，在预定的时间和成本之内，开发完成质量合格的产品，从而使企业和个人获得预定的利益。 奋斗目标：调动一切积极因素，努力提高产品质量、提高工作效率并且降低成本，使企业和个人获得比预定目标更多的利益。在IT企业中，软件研发管理所涉及的主要过程域有： 商务过程域：合同项目和自主产品的立项管理，合同项目客户跟踪，产品优化和市场推广。 项目管理过程域：项目规划与监控，风险跟踪和变更控制，结项管理。 项目开发过程域：需求开发，设计，实现，测试，试用与验收等。 机构支持过程域：质量管理，软件配置管理和文档管理，客户服务和维护，跨部门协作等。上述过程域中的任何活动都会影响研发项目的质量、时间和成本。人们显然难以一股脑地把所有的事情做好，需要合适的管理方法。企业里大部分工作是成熟的，有现成的模式可以套用，这类工作应当靠流程制度来管理，可比喻为“法治”。企业中还有一部分工作可能是独特的，并不适宜套用流程制度（也可能没有流程制度可以套用），相关人员要当机立断、高效地处理问题，可比喻为“人治”。一般地，企业既需要大量的“法治”管理方式，又需要小量的“人治”管理方式。通常前者约占60-80%，而后者约占20-40%。“法治”和“人治”结合使用是企业管理的重要手段。企业领导要关注两点：一是建立合适的流程制度（实现良好的法治）；二是使用合适的人（实现良好的人治）。国内大部分IT企业的研发管理现状是：“法治”太少，混乱的“人治”太多。阻碍国内IT企业发展的瓶颈问题通常不是技术问题，而是杂乱无章的管理。1.2 过程改进的概念1.2.1 什么是过程？为什么要重视过程？一、什么是过程人们使用合适的方法、技术、工具才能开发出用户需要的产品。过程是指“人，方法，技术和工具”的集合，如图1-1所示。过程被写成文档后，变成了公司的“流程制度”，公司成员们依据“流程制度”开展工作，这叫“法治管理”。产品工具技术方法人员过程图1-1 过程示意图二、过程与产品有什么关系？为什么要重视过程?软件产品不能靠人们的意念瞬间完成，它需要一个研发过程。一般情况下，好的过程才可能得到好的产品，而差的过程会得到差的产品。当然也有相反的情况，有些人在混乱的过程中创造了很好的产品，也有些人在严谨的过程中生产出商业上失败的产品。但这类现象不具有指导意义，本书不作讨论。为什么要重视过程？由于公司销售的是产品而非过程，人们常常只把眼光盯在产品上，而忘了过程的重要性。例如，领导对员工们下达命令时经常强调：“我不管你们怎么做，只要时间一到你们交付产品就行。”其实这是一句因果关系颠倒了的话，却在业界普遍存在。下面的故事给出了警示：如果领导不关心员工怎么做（即做事的过程），往往会得到失望的结果。公司领导对项目经理小王说：这个软件项目对公司和客户都很重要，你们要好好干，在6个月之内完成，要让客户满意。6个月后我来看你们的成果，为你们庆功。每个月末，领导照例打电话问小王：“项目进展怎么样了？”小王每次答曰：“挺好。”6个月后，领导兴冲冲地问小王：“项目完成了吧，可以交付给客户了吧？”小王说：“还有一点东西没有完成，再给我们一个月时间，肯定能够完成。”7个月后，小王说：“出了一些小意外，我们正在解决之中，我保证下个月完成。”8个月后，小王说：“我们正在修改某些功能，还需要一个月。”9个月后，小王说：“我们正在完善某些功能，还需要一个月。”领导和小王日益焦虑，12个月后，项目终于完成了。领导喜气洋洋地请客户来验收软件，大家都做好了庆功地准备。客户看了软件后，大吃一惊：“这不是我们想要的软件！”在12月里，公司和客户都不关心该项目的过程，都不知道软件是怎样开发的、不知道软件做成什么模样了，都等着看最后的结果。结果是，进度延误了6个月，终于开发完成了不符合客户需求的软件。项目团队疲惫不堪，公司和客户损失惨重。所以，人们既要关注结果，又要重视过程。1.2.2 什么是过程改进？企业为什么需要过程改进？过程改进（Process Improvement）是指：根据企业的现实情况和发展需求，优化流程制度，努力提升人们在过程中的工作能力，从而“提升产品质量、提升生产率并降低成本”。（注：这是本书作者对过程改进的定义）“过程改进”本身就是一件消耗时间、精力和成本的事情，那么企业为什么要做“过程改进”？答案是：过程改进是企业谋求进步的需要。企业谋求进步离不开以下两点：（1）企业人士要不断学习新技术，开发新产品，开拓新业务领域。（2）企业人士要不断反省自己，总结经验教训，改正缺点、发挥优点。后者就是“过程改进”。过程改进体现了“自我反省、自我改进”的精神，不论对人生还是对企业而言，都是极为重要的。1.2.3 软件过程改进和CMMI之间的关系在二十世纪七、八十年代，软件工程的研究重点是需求分析、软件设计、编程、测试、维护等领域的方法、技术和工具，我们称之为经典软件工程。应该说现代的软件技术、软件工具要比几十年前好不知道多少倍，可是如今绝大多数软件项目依然面临着质量低下、进度延误、费用超支这些老问题。人们逐渐意识到，由于机构管理软件过程的能力比较弱，常常导致项目处于混乱状态，过程混乱使得新技术、新工具的优势难以体现。经典的软件工程不是不好，而是不够用。提高软件过程能力的实践通称为软件过程改进（Software Process Improvement）。软件过程改进的目的是：提高软件质量、提高生产率并且降低开发成本。从二十世纪九十年代至今，软件过程改进成为软件工程学科的一个主流研究方向，其中CMM/CMMI是该领域举世瞩目的重大成果。CMM/CMMI是世界范围内用于衡量软件过程能力的标准。人们往往搞不清楚“软件过程改进”和“CMMI等级评估”之间的关系，经常混为一谈。本节作个比喻来解释：把“软件过程改进”比喻为“学英语，提高英语能力”，那么“CMMI等级评估”就好比是“英语等级考试”。一般情况下，英语等级考试的成绩反映了英语能力。但是，在特别擅长应试的中国，英语考试成绩很好并不见得英语能力很好，甚至差到“哑巴英语”的程度。这种“特性”传染到软件领域，不少企业虽然通过了高级别的CMMI等级评估，但是其实际的软件过程能力却非常底下。软件过程改进的真正目的是提高机构的软件过程能力，而不是为了达到CMMI高等级。“汝果欲写诗，功夫在诗外”，这是很好的启示。1.2.4 有了CMMI为什么还要研制企业的过程规范？卡内基梅隆大学软件工程研究所发布的CMMI for Development 1.2版本，厚达560页。既然有了全世界认同的“CMMI宝典”，企业为什么还要研制自己的软件过程规范呢？解答这个疑问，我们首先要搞清楚“CMMI是什么”以及“CMMI不是什么”。CMMI是世界范围内用于衡量软件过程能力的标准，但是CMMI不是软件过程改进的执行标准，不可能存在适合所有企业的执行标准。就如“英语四六级考试”是中国所有大学都认同的评估大学生英语能力的标准，但是“英语四六级考试大纲”绝对不是“学好英语的标准”。不能把“CMMI宝典”直接作为企业的软件过程规范，主要原因如下：CMMI的560页文本论述了二十多个过程域和数百条实践，但是这些“过程域和实践”没有与“企业的具体业务和组织结构”衔接起来。有些企业死搬硬套CMMI，竟然按照CMMI文本的逐个遍历CMMI的过程域和实践，这种方式非常迂腐可笑：如同给一个病人治病，不考虑病人需要吃什么药，却把药店里面的药逐个儿吃一遍，以为就能治好病。1.2.5 如何应用CMMI？既然不能全盘套用CMMI文本，那么究竟该如何应用CMMI？ 应当根据企业的实际情况，既要裁剪CMMI过程域和实践，又要补充CMMI没有涉及的过程域和实践。企业领导和软件过程改进工作者必须明白：企业需要吻合商业目标、容易执行的软件过程规范。什么是裁剪？裁剪不是指用剪刀把CMMI厚厚的书剪成薄薄的书，裁剪是要动脑筋的：要分析企业的业务特征，根据自身的人力和财力，选取CMMI文本中一些重要的东西，舍弃其它不重要的东西。至于什么是“重要的东西”，则要根据它对企业的贡献多少来衡量。CMMI都560页厚了，为什么还要补充过程域和实践？CMMI对于软件开发和管理过程的论述非常深入，但是却没有涉及“商务过程”，例如没有谈立项管理、售前服务、售后服务等。这是CMMI很大的缺陷。企业开发产品的最终目的是卖出产品，赚取利润。如果软件过程规范中不考虑商务过程的话，会导致开发团队“闭门造车”，很可能开发出“技术上很好的产品，但却是商业上失败的产品”。1.3 过程改进的实施建议1.3.1 各级领导“亲身参与”而非“口头支持”过程改进不是闹着玩的，是需要投入人力去做的。软件研发管理过程中所涉及的人员都应该熟悉过程规范，并掌握技能。作者曾看到很多这样的现象：咨询师给企业员工培训过程规范的时候，各级经理总有各种理由不参加培训，当真正在项目中推行新的过程规范时候，各级经理自己却不懂，仍然按照他原先不合理的方式管理，让下属不知所措。各级领导的主要职责是“带领团队完成目标”，他们要“亲自参与”过程改进，才能深刻体会过程的要点，掌握研发管理的方法技能。“亲自参与”体现在：参与分析问题，商议改进对策；参与制定和自己工作相关的过程规范；参与评审；参加培训学习等等。1.3.2 制定“合适”而非“大而全”的过程规范大凡第一次从事过程改进的人员，他们总是希望制定“大而全”的过程规范，能够覆盖企业中的所有事务。6年前，作者带领6名研究人员在上海贝尔公司一个软件事业部（约150人）从事过程改进工作，一年时间不知不觉写了长达500页的软件过程规范以及数百页的相关指南。我花了九牛五虎之力去培训推广，最终还是没有很好地用起来。我们走了很大的弯路，反省后发现，缺乏经验只是一个原因，而“贪大求全”才是最大的错误原因。站在用户角度想想，那么厚的过程规范，人都看晕过去了，怎么能够地很好执行呢！从2002年至今，我一直不断地创作、改进“集成化软件研发流程IDP”（详见第4章），最近发布的IDP 5.0流程规范和文档模板，加起来不到100页。用户和作者自己都比较满意。（注：请从作者公司网站下载IDP和相关文件。）1.3.3 不要迷信所谓的标准CMM/CMMI、PMBOK、ISO9000等标准都是用来参考的，而不是用来“迷信”的。我发现当人们崇拜CMM/CMMI时，他的思想意识就不知不觉地被CMM/CMMI控制了，这是非常有害的。2000年2005年期间，国内软件业界兴起CMM热潮。很多软件过程改进人员把CMM当圣经看待，完全对照CMM文本来操作，都不敢想一想是否合理。CMM 2级和3级过程域的划分未必是绝对正确的，例如“产品工程”（Product Engineering）过程域放在CMM 3级，而CMM 2级所有6个过程域没有一个是讲述技术开发过程的。对于国内大多数软件项目而言，技术开发占总工作量的70以上，而项目管理占总工作量的30以下。明眼人都看得出，技术开发过程的规范化比项目管理过程的规范化尤为重要与迫切（至少也是同等吧）。如果你迷信CMM，你自然而然地会先把精力集中在CMM 2级6个关键过程域上，而忽视了技术开发过程域。如果这样做的企业通过了CMM 2级认证，声称因此能够把产品做得又快又好，打死我都不相信。企业即使不采用CMM/CMMI，也是有可能把软件研发做得很好的，例如Microsoft、Google并不采用CMMI，它们有自己的研发管理方法。互联网公司的软件研发人员最喜欢嘲笑“笨重”的CMMI。据说某互联网公司的领导夜里做梦，梦见一个过了CMMI 5级的公司在做总动员，要进军互联网，于是他在梦中笑醒了。企业采用业界推荐的标准时，要舍弃那些听起来很先进，但是对本企业无益处的东西，只选取对企业有实用价值的东西。1.3.4 “引导推行”而非“强硬推行”作者曾经询问某公司领导：“在推广过程规范的时候遇到阻力怎么办？”该领导回答很干脆：“强制执行，不按规范执行者以失职处理。”这种答复“说得容易，做起来难”。在中国自古就存在“上有政策，下有对策”之说，在推广过程规范时不仅要预防员工们应付了事，还要引导员工们正确地做事情。举个例子说，计划生育是一项基本国策，它在实施之初遇到了强大的阻力。有一些人暴力对抗，很多人东躲西藏（形成了超生游击队）。怎么办？惩罚违抗者是一种不得已的措施。更好的方法是对全国人民进行教育宣传，这么多年下来，成绩斐然。如今计划生育已经深得民心了。企业制定过程规范是为了帮助员工们把工作做得更好，而不是存心与人们过不去。企业要设法使员工们乐于执行过程规范从而避免流于形式。以下是作者总结的“引导推行”的建议：一、解释规范过程改进者不要只是埋头写过程规范，写完了上缴了事。最好在企业内部网上开辟一个专栏，专门解释过程规范。过程规范不是数学定理，可谓“智者见智，笨者见笨”。如果不对过程规范作解释，员工们怎么能够理解“为什么”，如果不理解“为什么”怎么能够很好地执行呢？不少公司都有名目繁多的规章制度，很多条款用了“必须”的语气。有些内容会损害不少人的利益，但为了顾全大局不得已这样做，但是如果不解释清楚原因，可能会招致本来可以避免的埋怨或对抗。对过程规范作进一步解释会带来间接的好处：不合理之处会很快被发现（因为解释不通嘛）。二、培训和考试要对全员进行培训与考试，使企业中的每个人都熟悉与自己工作相关的过程规范。只有这样才能防止一些人拖后退，使团队发挥最大的力量。企业里的各级经理往往派下属参加培训，而自己则以工作忙为理由回避培训。我曾经给一个软件事业部做了大力度的培训，几乎所有干活的人都参加培训和考试了（连行政秘书都没放过），但是漏掉了几个经理。结果“当兵的”至少都知道到哪里下载过程规范，知道规范里讲些什么东西。但是那几个“当官的”却浑然不知，依旧我行我素，真是带头起破坏作用啊。所以说，领导亲自参与培训和考试要比口头支持有意义得多。三、质量保证人员监督实施人都有惰性，如果没有人来监督员工们按照过程规范办事，那么自觉性不强的员工就会回到“无序”的老路上。CMMI把质量保证称为“过程与产品质量保证”。质量保证人员的职责就是周期性地检查项目成员的“工作过程以及工作成果”是否符合既定的过程规范，来监控和改进“过程质量以及产品质量”。几乎所有的老百姓都明白基本的交通法规，但是明知故犯的人不少，所以社会需要很多交通警察。质量保证人员的工作性质有点像交通警察。1.3.5 写好必要的文档企业搞过CMM/CMMI之后，通常会要求开发团队写不少文档。据说CMM/CMMI等级和文档有这样的关系：你们对所做的事情有文档记载吗？如果有，好，达到了CMM 2级。你们对所做的事情的文档有文档记载吗？如果有，很好，达到了CMM 3级。你们对所做的事情的文档的文档有文档记载吗？如果有，非常好，达到了CMM 4级。很多管理者有这样的感受，在推广软件过程规范时，员工们抱怨最多的就是“要写的文档太多了”！甚至很多人把进度延误归罪于写文档。人们抱怨“文档太多了”，有两种原因：一是过程规范的确很臃肿，规定了太多不必要的文档，如果是这种情况，那么应该精简过程规范，减少文档数量。二是过程规范要求的文档本身是合适的，但是人们以前写文档太少了，一下子不习惯写文档。现代人早晚各刷一次牙，我们觉得很正常。可是古代人不刷牙，如果你要求古代人早晚各刷一次牙，他们肯定觉得太麻烦了。企业应该想办法降低写文档的难度，提高写文档的效率。一要下功夫制定出结构良好的文档模板，给出充足的提示和示例。这样使用者就可以“依葫芦画瓢”，总比他自己琢磨怎样写要方便得多。二要鼓励开发人员经常写文档，才会熟能生巧，不断提高写作能力。1.4 研发管理的过程改进方法3.优化过程规范2. 优化组织结构岗位职责1. 调查分析问题研发管理工具如RDMS方法论如CMMI,IDP等 持续提升企业的软件研发和管理能力5. 培训和辅导4. 部署配套的管理工具6. 执行与改进作者根据多年的咨询经验，总结了软件研发管理的过程改进方法，如图1-2所示。下文中的“咨询师”可以是企业内部的过程改进人员，也可以是外聘的咨询师。图1-2 软件研发管理过程改进的一般方法步骤第1步，调查分析问题。咨询师访谈企业中和“研发、管理、营销、服务”相关的工作人员，分析共性的和重要的问题，征求提出者和领导的意见，共同协商解决问题的对策。第2步，优化组织结构和岗位职责。咨询师根据访谈结果，优化组织结构和岗位职责，可能需要调整重要岗位的人选和权力。第3步，研制和优化过程规范。咨询师帮助企业“研制和优化”软件研发管理的流程规范，一般需整合“商务过程、项目管理过程、项目开发过程、支持过程”。请参考第4章“集成化软件研发流程IDP”。第4步，部署配套的管理工具。企业尽量部署与流程规范配套的管理工具，例如配置管理工具、缺陷跟踪工具、任务管理工具等等。请参考第5章“集成化研发管理平台”。第5步，培训和辅导。咨询师为企业员工提供充分必要的培训和辅导，让员工理解过程规范，并掌握技能。第6步，执行和改进。企业员工根据新的过程规范开展工作，过程改进负责人监督执行情况，记录问题，然后周期性地改进过程。