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