软件研发管理问题和解决方案课件

软件研发管理问题和解决方案常见问题分析基础方法论介绍整体解决方案林锐博士软件研发管理问题和解决方案林锐博士目录1.企业研发管理的理念2.常见问题分析3.中型企业的研发管理需求4.基础方法论介绍－CMM5.基础方法论介绍－PMBOK6.基础方法论介绍－敏捷开发7.基础方法论介绍－RUP8.面向企业的软件研发管理解决方案9.基于Web的集成化项目管理系统Future3.0目录1.企业研发管理的理念1.企业研发管理的理念1.1目标企业的根本目标是“合法地赚取尽可能多的利润，使企业利益最大化”。企业所有的特定目标和行动都是围绕根本目标开展的。根本目标进一步决定了企业研发管理的目标和策略。企业研发管理的基本目标是：让所有人员有条不紊地开展工作，在预定的时间和成本之内，开发完成质量合格的产品，从而使企业和个人获得预定的利益。企业研发管理的奋斗目标是：调动一切积极因素，努力提高产品质量、提高工作效率并且降低成本，使企业和个人获得比预定目标更多的利益。1.2质量、进度（时间）、成本“质量、进度（时间）、成本”通常是衡量企业研发管理“优劣”的三个关键指标。不同的企业，甚至同一企业在不同时期，对三者的重要性看法是不一样的。如果出现“三者难以同时兼得”的情况，那么产品的决策者一定要搞清楚质量、进度（时间）、成本之间的复杂关系，判断孰重孰轻，给出优化和折衷的措施。

1.3规范化vs.超越规范化在企业里，大部分的工作是成熟的，有成功的模式可以套用，应当走规范化的路线；而另外小部分的工作可能是独特的，并不适宜套用规范（也可能没有规范可以套用），那么应当采用超越规范化的管理方式。通常前者约占80%，而后者约占20%

1.企业研发管理的理念1.1目标

2.1常见问题分析：立项管理2.1.1自主研发产品的立项问题拥有决策权的领导人独自决定，或者招集有关人员开会商议是否开发某个产品。决策过程中的主观臆断比较多，风险很高。如果决策错误，即使人们努力开发出功能很好的产品，却可能在商业上失败。由于没有进行充分必要的调研、可行性分析、立项建议、立项评审等工作，企业领导在组建开发团队时难以给出恰当的资源和进度计划。团队只知道干活，却不了解产品的开发背景，不清楚用户期望的产品应该是什么样的。在开发过程中经常迷失方向，导致进度延误、费用超支等问题。2.1.2合同项目的立项问题

委托方（客户方）和承包方（开发方）在签订合同的时候，双方对软件需求的了解并不深入，合同中对“开发什么”的描述比较空洞。合同签订之后，客户经常变更需求，开发方被迫不断修改软件，弄得疲惫不堪。夸张地概括：除了合同金额不变，其它一切都可能改变。刚签订合同时开发方似乎赚钱了，后头却可能得不偿失。双方在签订合同的过程中给出了一些空头承诺（例如对进度、质量、费用的估计过于乐观），在实际执行时却难以兑现这些承诺。处理不好将引发合同纠纷，轻则双方提前终止合同，重则双方反目成仇。2.1.3建议创建一种群体决策的立项管理规范，不仅让群众贡献智慧，而且让群众分担责任，使成功的经验被企业不断复用，并升华成为企业的制度。

2.1常见问题分析：立项管理2.1.1自主研发产品的立项2.2常见问题分析：

结项管理2.2.1共性问题某些项目由于进度拖延，不能按计划结项；某些项目即使开发完成了，由于利益关系也不愿结项。这些“不良”项目或者已经完成的项目一直占用企业资源（如人力资源和设备），无疑违背企业利益最大化的目标。在结项时，人们往往对财务和设备进行了详细的清算，却忽视了对知识财富、经验教训的总结。殊不知设备越用越差，但是知识财富越用越好，可谓主次颠倒。没有对项目的价值进行评估，开发人员干完活后，不知道自己的工作成果产生多大的效益，缺乏成就感。结项后，不能对员工的业绩进行公正考核，自然不能很好地激励员工。合同软件项目在结项之前，还面临“客户验收”的一些问题。例如缺乏双方认同的“验收标准”，导致验收过程混乱，过多地消耗双方的精力。2.2.2建议首要措施是建立企业的“结项管理规范”和“验收与发布”规范。自主研发的软件产品在结项之前，公司内部要进行类似的“验收”，防止不良项目蒙混过关。2.2常见问题分析：结项管理2.2.1共性问题2.3常见问题分析：项目规划2.3.1共性问题在项目刚开始阶段，人们对产品需求和技术的了解还比较肤浅，项目不确定因素比较多，此时很难对工作量和进度作出比较准确的估算。软件工程教科书和CMM推荐的COCOMO模型、代码行估算方法等等，对大多数国内项目无法适用，效果如同“电脑算命”。由此制定的项目计划可能不切实际，后面经常发生项目计划的变更（所以业界流传“计划快不如变化快”），将导致项目管理的复杂性和风险提高。项目的人员已经被上级领导限定死了，再多的活也是那几个人干；项目的结束日期早就被领导和客户指定了，不管合理不合理，反正时间一到就要交付软件；除了办公计算机和工资外，这个项目没有其它经费，项目经理只有干活的权利没有用钱的权利。如果人员、资金、时间都已经被毫无道理地指定了，那么项目规划就失去意义，这样的项目在国内非常普遍。

2.3.2建议建立企业的“项目规划规范”，给出合适的项目估算方法和项目计划模板。使用方便的软件工具，帮助项目经理进行项目规划。2.3常见问题分析：项目规划2.3.1共性问题2.4常见问题分析：项目监控2.4.1共性问题许多项目经理肩负重要的软件开发工作，他们往往把注意力集中在开发上面，很少认真考虑如何进行项目监控。没有突出项目监控的重点，项目经理要么什么都不监控（导致项目失控），要么监控得太多而陷入琐碎事务中。项目经理写周期性项目进展报告时，记流水帐，或者复制上次的报告，应付了事。懒得动脑筋分析项目遇到的一些问题，例如某些任务的进度延误了，不分析为什么延误了，就顺延。导致问题越积越多。项目实际执行情况与原定的项目计划严重脱节，领导、客户、市场人员、开发团队不了解项目真正的状况，使项目计划行同虚设。2.4.2建议建立企业的“项目监控规范”，使用方便的软件工具，帮助项目经理进行项目监控。上级领导和相关人员每周都要检查项目的监控要素，及时发现问题，及时解决问题，既要关心结果也要关心过程。

2.4常见问题分析：项目监控2.4.1共性问题2.5常见问题分析：配置管理和变更管理2.5.1共性问题有些软件机构竟然不使用软件配置管理工具，用最原始的方式手工管理代码和文档，经常出现“成果丢失、版本混乱”等问题。不少机构按照的CMM的要求制定了配置管理规范。该规范在理论上比较完善，面面俱到，但是实际操作比较麻烦，没有突出重点。久而久之，人们厌烦后就逐渐放弃了规范，按自己的习惯操作，留下了隐患。例如不少程序被

checkout后长久没有

checkin；有些程序保留在开发者本机，根本就没有放入配置库。维护期间修改了程序，但是没有放入配置库。没有变更控制流程，经常随意变更需求、设计、代码等，严重影响项目的正常开发进程。2.5.2建议建立简单有效的“配置管理规范”和“变更管理规范”。并使用方便的工具，帮助团队进行软件配置管理和变更管理。2.5常见问题分析：配置管理和变更管理2.5.1共性问题2.6常见问题分析：质量管理2.6.1共性问题虽然人们大都认可软件的质量很重要，但是许多软件人员并不懂得如何有效地改善软件质量属性如正确性、健壮性、可靠性、性能、易用性、安全性、可扩展性、可复用性、兼容性、可移植性等等。不会分析当前软件的质量要素是什么，没有把精力集中在改善对经济效益贡献最大的质量要素上面。

有些软件机构没有软件质量管理的措施，开发人员把完成功能当成终极目标。用户在使用软件的过程中发现许多Bug，导致开发方的纠错性维护代价很高。

有些软件机构虽然很重视软件质量，按照ISO,CMM的要求建立了管理规范，但是效果不明显。人们搞不清楚软件测试、技术评审、质量保证的作用和关系。不懂得内建质量，主要靠修补错误的方式提升质量，代价比较高。

很多人误以为提高软件质量是质量保证人员和测试人员的责任，没有意识到任何开发人员、管理人员都会对质量产生影响，都要对质量负责。另外，质量保证人员的权力比较小，很难推动质量改进措施。2.6.2建议让人们理解“什么是软件质量”及常见的软件质量属性，树立全面软件质量管理的理念（模型），制定软件测试、技术评审、质量保证的规范。并使用方便的工具，帮助团队进行软件质量管理。2.6常见问题分析：质量管理2.6.1共性问题2.7常见问题分析：需求开发与管理2.7.1共性问题对于大部分软件机构而言，需求开发与需求管理是问题最多、最难解决的过程域。软件机构中，通晓需求调查、需求分析、需求定义、需求评审、需求跟踪、需求变更控制的人员本来就比较少，也不容易招聘和培养这样的人才。

用户说不清楚需求、用户经常变更需求是普遍现象，令开发方非常头痛。开发人员不善于写文档，很难写出清楚、完整的软件需求规格说明书。后续开发人员可能误解需求，做出与需求不一致的设计、代码、测试用例等等，最后不得不大量返工重做。最难办的事情是莫过于“拒绝客户提出的需求变更请求”。客户会想当然地以为变更需求是他的权利，因为他付钱给开发方。通常情况下开发方是不敢得罪客户的，但是无原则地退让将使开发小组陷入困境。2.7.2建议建立“需求开发与管理规范”，给出合适的文档模板，采用方便的需求分析和管理工具。还要多请有经验的人来培训、传授实战经验。

制定应对需求变更的办法，例如：(1)双方签订需求变更管理协议;(2)将重大需求变更延缓到下个软件版本中实现;(3)让客户欠下人情。

2.7常见问题分析：需求开发与管理2.7.1共性问题2.8常见问题分析：软件设计2.8.1共性问题对于大部分软件机构而言，用户界面设计是弱项。国内绝大多数大学的计算机学科没有开设人机工程学、美学、心理学这些必修课。由于学生们接受的教育几乎全是科学与技术，他们根本不知道怎样才能设计出易用、美观的用户界面，很多人甚至想都没有想过。当他们毕业后真正参与软件产品开发时，只好凭着个人的经验与感觉设计软件的用户界面，这样产生的界面往往得不到大众用户的认可。

大部分软件机构都有一些技术出色的软件人员，他们在系统构架、数据库方面的设计能力相当不错。但是很多人不愿意、不善于写系统设计报告，这不利于后续的软件开发和维护。软件设计应当“细到什么程度”很难把握。太粗了的话，对后续开发工作的指导价值不高；反之倘若太细的话，耗费时间就比较多，如果后面不断改进设计的话，前面的设计浪费太多。2.8.2建议建立“软件设计规范”，给出合适的文档模板，采用方便的设计工具。还要多请有经验的人来培训、传授实战经验。

2.8常见问题分析：软件设计2.8.1共性问题2.9常见问题分析：编程与调试2.9.1共性问题软件机构的大部分程序员的技能是合格的，但是他们编写的程序风格差异较大，代码质量有高有低。大多数软件机构没有编程规范，即使有的话，开发人员也没有很好地按规范编程。相当多的程序员没有养成对所有代码进行“单步跟踪调试”的习惯。嫌单元测试很麻烦，懒得执行，却没有替代方案。2.9.2建议制定简单明了、重点突出的“编程规范”，让团队遵照此规范编写程序。采用集成化的开发调试工具，提高编程质量和效率。2.9常见问题分析：编程与调试2.9.1共性问题2.10常见问题分析：软件测试2.10.1共性问题许多软件人员没有系统地学习过软件测试，搞不清楚各种测试的概念，例如单元测试、集成测试、验收测试、黑盒测试、白盒测试、功能测试、性能测试等等，混为一谈，不知如何下手。测试人员没有掌握有效测试的方法，大多凭感觉测试，结果重复测试已经测试过的，那些深藏的bug却发现不了。客户在使用软件的过程中发现的bug比公司内部测试时发现的还多，不仅改错代价高，而且降低了客户对产品的满意度。团队没有采用有效的缺陷跟踪工具。测试人员发现bug时，口头告知有关人员或者记在Word、Excel文件中，修改bug信息或者测试报告时非常麻烦。难以及时从bug列表中找出规律，测试的效率比较低。2.9.2建议建立“软件测试规范”，采用方便的测试管理工具。还要多请有经验的人来培训、传授实战经验。2.10常见问题分析：软件测试2.10.1共性问题2.11常见问题分析：软件维护2.11.1共性问题在维护期间，除了纠错性维护外，客户可能提出需求变更（但是不支付费用），维护人员对客户妥协，导致维护工作量增大、成本增加。如果是合同软件项目，用户对开发方的依赖性比较大，不愿意自己解决粗浅的问题，经常叫开发方“干这干那”。开发方不敢得罪客户，导致开发方做了许多不属于维护的工作，吃哑巴亏。开发人员一边开发新项目，一边维护老项目。而维护为体现不出业绩，又影响了新项目的进度，开发人员比较心烦。2.11.2建议制定“软件维护规范”，界定什么是“免费维护”、什么是“有偿维护”，以及相应的操作规则，提高维护效率并且降低维护成本。

2.11常见问题分析：软件维护2.11.1共性问题2.12常见问题分析：其它问题2.12.1技术vs.市场许多开发人员喜欢技术研究和技术挑战。虽然嘴上说开发产品要以“客户（市场）为中心”，但是在开发软件的时候，却不知不觉以技术为中心，例如喜欢采用新技术、追求技术上的完美。导致进度延误，成本增加，甚至可能有质量风险。他们开发出来的软件在技术上可能很先进，但是并不是用户所关心的。多数开发人员缺乏商业头脑，常常做出背离企业根本目标的事情。企业领导应当重视这个问题，要经常性地向开发人员们灌输商业理念。让他们明白“能够赚钱的技术才是好技术”。在企业里，商业利益高于技术追求。

2.11.2项目经理的财务权国内大部分企业的项目经理有带头干活的权利和义务，他们对项目的进度和质量负最大责任，但是没有财务权。大部分项目没有经费，即使有经费，也得由上级领导审批使用，不能自己作主。有时团队加班干了不少活，项目经理却没有钱“意思意思”，很没有面子。没有财务权的项目经理，不是完整意义上的项目经理。企业不给项目经理财务权的初衷是为了控制成本，防止项目经理乱花钱。但是实际上效果适得其反。由于项目经理没有财务权，他们就不会关心成本也不懂得如何控制成本。因管理不成熟、工作效率不高、进度延误等问题导致“隐性成本”不断增加，钱在不知不觉地流失。企业领导应当给予项目经理“适当”的财务权，只要确定项目财务制度并限定经费额度，就不会造成失控。既让项目经理“有点小钱”慰劳团队，有工作积极性；又让他真正重视成本控制，并付诸实践。用“小量胡萝卜”获得大回报。

2.12常见问题分析：其它问题2.12.1技术vs.3.中型企业的研发管理需求3.1需求特征必要性。如果软件机构只有数人或者十几个人，即使没有研发管理规范，能力强的机构领导一个人也能从容指挥。当软件机构的人数超过50人后，如果还没有研发管理规范的话，那么机构领导将会力不从心。人数越多，非规范化管理越容易产生混乱，迫使企业不得不走规范化管理的路线，以降低管理代价和风险。经济基础。建立规范化的研发管理是需要一定的投资的，例如咨询、培训、购买工具等等。小型软件机构通常没有钱去做这件事情，望洋兴叹。中型机构能够养活50－200人，表示它们是有一定经济实力的，只要投资额适当而且产生的效益高于投资，那么中型机构一般都愿意做这件事情。

发展欲望。有些中型机构的领导雄心勃勃，高瞻远瞩，他们迫切希望提高研发管理能力从而提升整个企业的核心竞争力，产生源源不断的推动力，推动企业持续发展壮大。他们对研发管理的态度是主动的，而不是被动的。

3.2费用估算国内一些大型IT企业建立了完整的研发管理体系，投资巨大。例如上海贝尔、华为分别请HP、IBM建立研发管理体系，投资额分别达到数千万元、上亿元。这种投资额是中型企业望尘莫及的。在研发管理方面，中型企业无法效仿大型企业的做法。国内中型软件机构对研发管理的投资额大约在数万元至元数十万元。这点“小钱”根本无法引入IBM、HP、Rational等公司的研发管理解决方案。

大部分国内中型软件机构需要的是“轻量级”的研发管理解决方案，包括咨询、培训、购买工具，总费用在5万元至20万元之间比较合适。

3.中型企业的研发管理需求3.1需求特征4.基础方法论介绍－CMM4.1基本概念产品是在过程中研制出来的。一般地，好的过程才可能得到好的产品，而差的过程只会得到差的产品。提高软件过程能力的实践通称为软件过程改进（SoftwareProcessImprovement）。软件过程改进的根本目的是：提高质量、提高生产率并且降低开发成本。

CMM/CMMI是世界范围内用于衡量软件过程能力的事实上的标准，同时也是软件过程改进最权威的指南。

CMM等级评估：从狂热回归理性。现在软件业界普遍关注的是：企业如何以比较低的代价有效地提高软件过程能力。CMM等级评估则退居次要地位。

4.2CMM的盲区和常见应用问题CMM本身不谈如何赚钱的问题。它假设了美好的前提条件，即企业有充足的人员、资金、时间从事软件过程改进，当软件过程能力提高了，那么产品的质量、生产率自然上去了（同时成本也下降了），企业自然能够获取更多的利润。软件过程改进对企业经济效益的贡献是间接的，从投入到产出，时间相对比较长。

企业领导当然想把资源用在“刀刃”上，即赚钱最多最快的地方。当软件过程改进和其它直接赚钱的事情“发生资源冲突”时，人们只好“拆东墙，补西墙”，往往减少软件过程改进的资源。小结：对于软件过程改进而言，CMM/CMMI和ISO等等都是用来参考的，而不是用来迷信的。企业在参考业界推荐的标准或规范时，要舍弃那些听起来很先进但是对本企业无益处的东西，只选取对企业有实用价值的东西。4.基础方法论介绍－CMM4.1基本概念5.基础方法论介绍－PMBOK5.1基本概念项目管理协会（PMI）是目前全球影响最大的项目管理专业机构，该机构的项目管理专家认证（PMP）被广泛认同。PMI的突出贡献是总结了一套项目管理知识体系（PMBOK）。

PMBOK把项目管理知识划分为九个知识领域：综合管理、范围管理、时间管理、成本管理、质量管理、人力资源管理、沟通管理、风险管理和采购管理。每个知识领域包括数量不等的项目管理过程。5.2PMBOK和CMM/CMMI对比简评CMM/CMMI论述的项目管理方法仅仅适用于软件项目，但是不适用于其它行业的项目管理。PMBOK论述的方法适用于任何行业的项目管理，但是对软件项目管理而言，PMBOK的针对性不够强。

CMM/CMMI不仅论述软件项目管理，而且论述整个机构的软件研发管理。PMBOK的方法局限于项目管理，对于企业研发管理则不够用。

CMM/CMMI基本上不谈“成本管理”和“人力资源管理”，它先假设机构有充足的资金和人力资源，通常不切合企业实际情况。因此PMBOK的“成本管理”和“人力资源管理”可以弥补CMM/CMMI的不足。

建议：对于软件机构研发管理或者软件项目管理，采用CMM/CMMI为主导的方法论，并结合PMBOK的知识，取长补短。5.基础方法论介绍－PMBOK5.1基本概念6.基础方法论介绍－敏捷开发6.1基本概念2001年，为了解决许多公司的软件团队陷入不断扩大的过程泥潭，一批业界专家概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则，他们称自己为敏捷联盟（AgileAlliance）。他们起草了一个旨在鼓励更好的软件开发方法的宣言，称为敏捷联盟宣言（TheManifestooftheAgileAlliance）。然后在该宣言基础上制定了12条原则用于指导实践。该宣言和12条原则是敏捷软件开发方法的核心。

6.2我们的观点敏捷软件开发的宣言和12条原则并非普遍适用。敏捷开发方法表达了“简单、快速、实用”的软件开发思想，它不是成熟的理论、也不是事实上的标准（不象CMM,PMBOK那样具有严密的理论体系，被企业广泛接受）。即使人们认同某些原则，但是不同的人往往有不同的理解，实践差异很大。敏捷开发方法对于提高个人、小型团队的工作效率是很有帮助的（如果用对了的话）。但是企图用它指导大型、中型软件机构的研发管理是有很高风险的，它的某些主张是局部观点而不是全局观点，如果把握不好分寸的话可能导致整体混乱，而“整体的混乱”会淹没“局部的好处”。我们研制的“精简并行过程（SPP）”的理论基础是“经典软件工程、CMM、PMBOK”。为了提高效率，在局部地方借鉴了“敏捷软件开发的思想”，用于裁减过于冗长、笨重的过程规范。6.基础方法论介绍－敏捷开发6.1基本概念6.基础方法论介绍－敏捷开发敏捷软件开发的12条原则：（1）我们最优先要做的是通过尽早地、持续地交付有价值的软件来使客户满意。

（2）即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。（3）经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。

（4）在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。

（5）围绕被激励起来的个人来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。

（6）在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。

（7）可以工作的软件是首要的进度度量标准。

（8）敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。

（9）不断地关注优秀的技能和好的设计会增强敏捷能力。

（10）简单——把无需做的工作最大化的艺术——是最根本的。

（11）最好的构架、需求和设计出于自我组织的团队。

（12）每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。6.基础方法论介绍－敏捷开发敏捷软件开发的12条原则：7.基础方法论介绍－RUP7.基础方法论介绍－RUP8.面向企业的软件研发管理解决方案8.1目标帮助企业建立适合于自身需求的软件研发管理规范，并部署配套的软件工具；通过充分的培训，帮助员工们掌握提高质量、提高生产率、降低成本的方法；协助企业依据规范开展软件研发和管理工作，持续提升能力。

8.2工作流程

面向企业的软件研发管理解决方案8.面向企业的软件研发管理解决方案8.1目标

面向企业的8.面向企业的软件研发管理解决方案8.3集成化研发管理方法（SimplifiedParallelProcess,SPP）

8.面向企业的软件研发管理解决方案8.3集成化研发管理8.面向企业的软件研发管理解决方案8.4内容和时间

1.调查分析问题

对企业研发管理的能力现状进行调查与分析，调查内容要覆盖所有工作领域（过程域），总结“强项”和“弱项”，给出建议。

预计时间跨度为2个月，乙方到甲方现场工作和服务约20工作日。日程安排由双方共同商定。

2.制定研发管理规范

绘制研发管理的总体流程图；绘制组织结构图，并确定角色职责表；定义每个过程域的规范（目的，关键活动和流程，工作成果）

3.选用合适的工具

选择并部署合适的开发工具和管理工具。推荐管理工具是Future和CVS。含1年免费维护和升级服务4.充分必要的培训

为研发管理流程中的所有人员提供充分必要的培训，包括软件工程、项目管理等，让人们掌握提高软件质量、提高生产率、降低成本的方法。

5.执行、监督与反馈

协助客户依据规范开展软件研发和管理工作。跟踪试点项目的执行情况，及时解答执行过程中遇到的问题，持续地提升客户的软件研发能力。

乙方提供一年的售后服务。

解决方案的内容视企业的实际情况而定。

8.面向企业的软件研发管理解决方案8.4内容和时间

1.8.5相关著作8.5相关著作9.集成化软件项目管理系统（Future）9.集成化软件项目管理系统（Future）

9.集成化软件项目管理系统（Future）9.2Future的特色物美价廉、富有成效的集成化项目管理工具Future将企业研发管理过程中最常用的工具全部集成于Web环境，并与方法论“精简并行过程SPP”配套，相互支持。企业不必购买多个分立的管理工具，避免了管理工具之间不兼容、数据孤立的问题。不仅提高了研发管理效率，而且大大降低了购买工具的成本。Future软件不仅可以为企业建立完备的研发管理数据库，而且帮助企业领导对所有项目的进度、工作量、成本、质量进行数据分析，为研发绩效考核提供客观依据。易用美观的用户界面Future软件的系统视图、项目视图、个人视图、领导视图、文档视图、论坛视图具有高度一致、易用美观的用户界面。用户使用Future，可以轻松地完成研发项目的管理工作。这源于我们对用户特征的深刻理解，和对用户界面的精心设计。

容易扩展、与流行软件兼容Future3.0的所有页面数据可以导出到Excel文件；后续版本可以导入、导出MSProject数据；后续版本可以访问配置管理软件CVS的文件库；后续版本将集成更多的工具，如人力资源管理系统、客户关系管理系统等。为了方便地和企业现有的管理系统交互信息，我们提供WebService接口，并帮助用户对Future进行二次开发。9.集成化软件项目管理系统（Future）9.2Futu9.集成化软件项目管理系统（Future）9.3Future3.0的运行环境服务器端操作系统：Windows2000/2003/XP，或Linux数据库：缺省采用MySQL4.0.*，兼容Oracle,SQLServerJAVA运行环境：J2SE1.4以上版本Web服务器：Tomcat4.1以上版本内存：建议至少512M客户端的配置操作系统：Windows2000/2003/XP浏览器：IE6.0以上版本内存：建议至少256M9.集成化软件项目管理系统（Future）9.3Futu9.4Future3.0功能示例－系统视图－立项结项9.4Future3.0功能示例－系统视图－立项结项9.5Future3.0功能示例－项目视图－任务管理9.5Future3.0功能示例－项目视图－任务管理9.6Future3.0功能示例－项目视图－Gantt图9.6Future3.0功能示例－项目视图－Gantt图9.7Future3.0功能示例－项目视图－缺陷跟踪9.7Future3.0功能示例－项目视图－缺陷跟踪9.8Future3.0功能示例－项目视图－缺陷统计图9.8Future3.0功能示例－项目视图－缺陷统计图9.9Future3.0功能示例－文档视图9.9Future3.0功能示例－文档视图9.10Future3.0功能示例－领导视图－人员工作统计9.10Future3.0功能示例－领导视图－人员工作统9.11Future3.0功能示例－个人视图－个人任务9.11Future3.0功能示例－个人视图－个人任务9.12Future3.0功能示例－论坛视图－发贴回贴9.12Future3.0功能示例－论坛视图－发贴回贴软件研发管理问题和解决方案常见问题分析基础方法论介绍整体解决方案林锐博士软件研发管理问题和解决方案林锐博士目录1.企业研发管理的理念2.常见问题分析3.中型企业的研发管理需求4.基础方法论介绍－CMM5.基础方法论介绍－PMBOK6.基础方法论介绍－敏捷开发7.基础方法论介绍－RUP8.面向企业的软件研发管理解决方案9.基于Web的集成化项目管理系统Future3.0目录1.企业研发管理的理念1.企业研发管理的理念1.1目标企业的根本目标是“合法地赚取尽可能多的利润，使企业利益最大化”。企业所有的特定目标和行动都是围绕根本目标开展的。根本目标进一步决定了企业研发管理的目标和策略。企业研发管理的基本目标是：让所有人员有条不紊地开展工作，在预定的时间和成本之内，开发完成质量合格的产品，从而使企业和个人获得预定的利益。企业研发管理的奋斗目标是：调动一切积极因素，努力提高产品质量、提高工作效率并且降低成本，使企业和个人获得比预定目标更多的利益。1.2质量、进度（时间）、成本“质量、进度（时间）、成本”通常是衡量企业研发管理“优劣”的三个关键指标。不同的企业，甚至同一企业在不同时期，对三者的重要性看法是不一样的。如果出现“三者难以同时兼得”的情况，那么产品的决策者一定要搞清楚质量、进度（时间）、成本之间的复杂关系，判断孰重孰轻，给出优化和折衷的措施。

1.3规范化vs.超越规范化在企业里，大部分的工作是成熟的，有成功的模式可以套用，应当走规范化的路线；而另外小部分的工作可能是独特的，并不适宜套用规范（也可能没有规范可以套用），那么应当采用超越规范化的管理方式。通常前者约占80%，而后者约占20%

1.企业研发管理的理念1.1目标

2.1常见问题分析：立项管理2.1.1自主研发产品的立项问题拥有决策权的领导人独自决定，或者招集有关人员开会商议是否开发某个产品。决策过程中的主观臆断比较多，风险很高。如果决策错误，即使人们努力开发出功能很好的产品，却可能在商业上失败。由于没有进行充分必要的调研、可行性分析、立项建议、立项评审等工作，企业领导在组建开发团队时难以给出恰当的资源和进度计划。团队只知道干活，却不了解产品的开发背景，不清楚用户期望的产品应该是什么样的。在开发过程中经常迷失方向，导致进度延误、费用超支等问题。2.1.2合同项目的立项问题

委托方（客户方）和承包方（开发方）在签订合同的时候，双方对软件需求的了解并不深入，合同中对“开发什么”的描述比较空洞。合同签订之后，客户经常变更需求，开发方被迫不断修改软件，弄得疲惫不堪。夸张地概括：除了合同金额不变，其它一切都可能改变。刚签订合同时开发方似乎赚钱了，后头却可能得不偿失。双方在签订合同的过程中给出了一些空头承诺（例如对进度、质量、费用的估计过于乐观），在实际执行时却难以兑现这些承诺。处理不好将引发合同纠纷，轻则双方提前终止合同，重则双方反目成仇。2.1.3建议创建一种群体决策的立项管理规范，不仅让群众贡献智慧，而且让群众分担责任，使成功的经验被企业不断复用，并升华成为企业的制度。

2.1常见问题分析：立项管理2.1.1自主研发产品的立项2.2常见问题分析：

结项管理2.2.1共性问题某些项目由于进度拖延，不能按计划结项；某些项目即使开发完成了，由于利益关系也不愿结项。这些“不良”项目或者已经完成的项目一直占用企业资源（如人力资源和设备），无疑违背企业利益最大化的目标。在结项时，人们往往对财务和设备进行了详细的清算，却忽视了对知识财富、经验教训的总结。殊不知设备越用越差，但是知识财富越用越好，可谓主次颠倒。没有对项目的价值进行评估，开发人员干完活后，不知道自己的工作成果产生多大的效益，缺乏成就感。结项后，不能对员工的业绩进行公正考核，自然不能很好地激励员工。合同软件项目在结项之前，还面临“客户验收”的一些问题。例如缺乏双方认同的“验收标准”，导致验收过程混乱，过多地消耗双方的精力。2.2.2建议首要措施是建立企业的“结项管理规范”和“验收与发布”规范。自主研发的软件产品在结项之前，公司内部要进行类似的“验收”，防止不良项目蒙混过关。2.2常见问题分析：结项管理2.2.1共性问题2.3常见问题分析：项目规划2.3.1共性问题在项目刚开始阶段，人们对产品需求和技术的了解还比较肤浅，项目不确定因素比较多，此时很难对工作量和进度作出比较准确的估算。软件工程教科书和CMM推荐的COCOMO模型、代码行估算方法等等，对大多数国内项目无法适用，效果如同“电脑算命”。由此制定的项目计划可能不切实际，后面经常发生项目计划的变更（所以业界流传“计划快不如变化快”），将导致项目管理的复杂性和风险提高。项目的人员已经被上级领导限定死了，再多的活也是那几个人干；项目的结束日期早就被领导和客户指定了，不管合理不合理，反正时间一到就要交付软件；除了办公计算机和工资外，这个项目没有其它经费，项目经理只有干活的权利没有用钱的权利。如果人员、资金、时间都已经被毫无道理地指定了，那么项目规划就失去意义，这样的项目在国内非常普遍。

2.3.2建议建立企业的“项目规划规范”，给出合适的项目估算方法和项目计划模板。使用方便的软件工具，帮助项目经理进行项目规划。2.3常见问题分析：项目规划2.3.1共性问题2.4常见问题分析：项目监控2.4.1共性问题许多项目经理肩负重要的软件开发工作，他们往往把注意力集中在开发上面，很少认真考虑如何进行项目监控。没有突出项目监控的重点，项目经理要么什么都不监控（导致项目失控），要么监控得太多而陷入琐碎事务中。项目经理写周期性项目进展报告时，记流水帐，或者复制上次的报告，应付了事。懒得动脑筋分析项目遇到的一些问题，例如某些任务的进度延误了，不分析为什么延误了，就顺延。导致问题越积越多。项目实际执行情况与原定的项目计划严重脱节，领导、客户、市场人员、开发团队不了解项目真正的状况，使项目计划行同虚设。2.4.2建议建立企业的“项目监控规范”，使用方便的软件工具，帮助项目经理进行项目监控。上级领导和相关人员每周都要检查项目的监控要素，及时发现问题，及时解决问题，既要关心结果也要关心过程。

2.4常见问题分析：项目监控2.4.1共性问题2.5常见问题分析：配置管理和变更管理2.5.1共性问题有些软件机构竟然不使用软件配置管理工具，用最原始的方式手工管理代码和文档，经常出现“成果丢失、版本混乱”等问题。不少机构按照的CMM的要求制定了配置管理规范。该规范在理论上比较完善，面面俱到，但是实际操作比较麻烦，没有突出重点。久而久之，人们厌烦后就逐渐放弃了规范，按自己的习惯操作，留下了隐患。例如不少程序被

checkout后长久没有

checkin；有些程序保留在开发者本机，根本就没有放入配置库。维护期间修改了程序，但是没有放入配置库。没有变更控制流程，经常随意变更需求、设计、代码等，严重影响项目的正常开发进程。2.5.2建议建立简单有效的“配置管理规范”和“变更管理规范”。并使用方便的工具，帮助团队进行软件配置管理和变更管理。2.5常见问题分析：配置管理和变更管理2.5.1共性问题2.6常见问题分析：质量管理2.6.1共性问题虽然人们大都认可软件的质量很重要，但是许多软件人员并不懂得如何有效地改善软件质量属性如正确性、健壮性、可靠性、性能、易用性、安全性、可扩展性、可复用性、兼容性、可移植性等等。不会分析当前软件的质量要素是什么，没有把精力集中在改善对经济效益贡献最大的质量要素上面。

有些软件机构没有软件质量管理的措施，开发人员把完成功能当成终极目标。用户在使用软件的过程中发现许多Bug，导致开发方的纠错性维护代价很高。

有些软件机构虽然很重视软件质量，按照ISO,CMM的要求建立了管理规范，但是效果不明显。人们搞不清楚软件测试、技术评审、质量保证的作用和关系。不懂得内建质量，主要靠修补错误的方式提升质量，代价比较高。

很多人误以为提高软件质量是质量保证人员和测试人员的责任，没有意识到任何开发人员、管理人员都会对质量产生影响，都要对质量负责。另外，质量保证人员的权力比较小，很难推动质量改进措施。2.6.2建议让人们理解“什么是软件质量”及常见的软件质量属性，树立全面软件质量管理的理念（模型），制定软件测试、技术评审、质量保证的规范。并使用方便的工具，帮助团队进行软件质量管理。2.6常见问题分析：质量管理2.6.1共性问题2.7常见问题分析：需求开发与管理2.7.1共性问题对于大部分软件机构而言，需求开发与需求管理是问题最多、最难解决的过程域。软件机构中，通晓需求调查、需求分析、需求定义、需求评审、需求跟踪、需求变更控制的人员本来就比较少，也不容易招聘和培养这样的人才。

用户说不清楚需求、用户经常变更需求是普遍现象，令开发方非常头痛。开发人员不善于写文档，很难写出清楚、完整的软件需求规格说明书。后续开发人员可能误解需求，做出与需求不一致的设计、代码、测试用例等等，最后不得不大量返工重做。最难办的事情是莫过于“拒绝客户提出的需求变更请求”。客户会想当然地以为变更需求是他的权利，因为他付钱给开发方。通常情况下开发方是不敢得罪客户的，但是无原则地退让将使开发小组陷入困境。2.7.2建议建立“需求开发与管理规范”，给出合适的文档模板，采用方便的需求分析和管理工具。还要多请有经验的人来培训、传授实战经验。

制定应对需求变更的办法，例如：(1)双方签订需求变更管理协议;(2)将重大需求变更延缓到下个软件版本中实现;(3)让客户欠下人情。

2.7常见问题分析：需求开发与管理2.7.1共性问题2.8常见问题分析：软件设计2.8.1共性问题对于大部分软件机构而言，用户界面设计是弱项。国内绝大多数大学的计算机学科没有开设人机工程学、美学、心理学这些必修课。由于学生们接受的教育几乎全是科学与技术，他们根本不知道怎样才能设计出易用、美观的用户界面，很多人甚至想都没有想过。当他们毕业后真正参与软件产品开发时，只好凭着个人的经验与感觉设计软件的用户界面，这样产生的界面往往得不到大众用户的认可。

大部分软件机构都有一些技术出色的软件人员，他们在系统构架、数据库方面的设计能力相当不错。但是很多人不愿意、不善于写系统设计报告，这不利于后续的软件开发和维护。软件设计应当“细到什么程度”很难把握。太粗了的话，对后续开发工作的指导价值不高；反之倘若太细的话，耗费时间就比较多，如果后面不断改进设计的话，前面的设计浪费太多。2.8.2建议建立“软件设计规范”，给出合适的文档模板，采用方便的设计工具。还要多请有经验的人来培训、传授实战经验。

2.8常见问题分析：软件设计2.8.1共性问题2.9常见问题分析：编程与调试2.9.1共性问题软件机构的大部分程序员的技能是合格的，但是他们编写的程序风格差异较大，代码质量有高有低。大多数软件机构没有编程规范，即使有的话，开发人员也没有很好地按规范编程。相当多的程序员没有养成对所有代码进行“单步跟踪调试”的习惯。嫌单元测试很麻烦，懒得执行，却没有替代方案。2.9.2建议制定简单明了、重点突出的“编程规范”，让团队遵照此规范编写程序。采用集成化的开发调试工具，提高编程质量和效率。2.9常见问题分析：编程与调试2.9.1共性问题2.10常见问题分析：软件测试2.10.1共性问题许多软件人员没有系统地学习过软件测试，搞不清楚各种测试的概念，例如单元测试、集成测试、验收测试、黑盒测试、白盒测试、功能测试、性能测试等等，混为一谈，不知如何下手。测试人员没有掌握有效测试的方法，大多凭感觉测试，结果重复测试已经测试过的，那些深藏的bug却发现不了。客户在使用软件的过程中发现的bug比公司内部测试时发现的还多，不仅改错代价高，而且降低了客户对产品的满意度。团队没有采用有效的缺陷跟踪工具。测试人员发现bug时，口头告知有关人员或者记在Word、Excel文件中，修改bug信息或者测试报告时非常麻烦。难以及时从bug列表中找出规律，测试的效率比较低。2.9.2建议建立“软件测试规范”，采用方便的测试管理工具。还要多请有经验的人来培训、传授实战经验。2.10常见问题分析：软件测试2.10.1共性问题2.11常见问题分析：软件维护2.11.1共性问题在维护期间，除了纠错性维护外，客户可能提出需求变更（但是不支付费用），维护人员对客户妥协，导致维护工作量增大、成本增加。如果是合同软件项目，用户对开发方的依赖性比较大，不愿意自己解决粗浅的问题，经常叫开发方“干这干那”。开发方不敢得罪客户，导致开发方做了许多不属于维护的工作，吃哑巴亏。开发人员一边开发新项目，一边维护老项目。而维护为体现不出业绩，又影响了新项目的进度，开发人员比较心烦。2.11.2建议制定“软件维护规范”，界定什么是“免费维护”、什么是“有偿维护”，以及相应的操作规则，提高维护效率并且降低维护成本。

2.11常见问题分析：软件维护2.11.1共性问题2.12常见问题分析：其它问题2.12.1技术vs.市场许多开发人员喜欢技术研究和技术挑战。虽然嘴上说开发产品要以“客户（市场）为中心”，但是在开发软件的时候，却不知不觉以技术为中心，例如喜欢采用新技术、追求技术上的完美。导致进度延误，成本增加，甚至可能有质量风险。他们开发出来的软件在技术上可能很先进，但是并不是用户所关心的。多数开发人员缺乏商业头脑，常常做出背离企业根本目标的事情。企业领导应当重视这个问题，要经常性地向开发人员们灌输商业理念。让他们明白“能够赚钱的技术才是好技术”。在企业里，商业利益高于技术追求。

2.11.2项目经理的财务权国内大部分企业的项目经理有带头干活的权利和义务，他们对项目的进度和质量负最大责任，但是没有财务权。大部分项目没有经费，即使有经费，也得由上级领导审批使用，不能自己作主。有时团队加班干了不少活，项目经理却没有钱“意思意思”，很没有面子。没有财务权的项目经理，不是完整意义上的项目经理。企业不给项目经理财务权的初衷是为了控制成本，防止项目经理乱花钱。但是实际上效果适得其反。由于项目经理没有财务权，他们就不会关心成本也不懂得如何控制成本。因管理不成熟、工作效率不高、进度延误等问题导致“隐性成本”不断增加，钱在不知不觉地流失。企业领导应当给予项目经理“适当”的财务权，只要确定项目财务制度并限定经费额度，就不会造成失控。既让项目经理“有点小钱”慰劳团队，有工作积极性；又让他真正重视成本控制，并付诸实践。用“小量胡萝卜”获得大回报。

2.12常见问题分析：其它问题2.12.1技术vs.3.中型企业的研发管理需求3.1需求特征必要性。如果软件机构只有数人或者十几个人，即使没有研发管理规范，能力强的机构领导一个人也能从容指挥。当软件机构的人数超过50人后，如果还没有研发管理规范的话，那么机构领导将会力不从心。人数越多，非规范化管理越容易产生混乱，迫使企业不得不走规范化管理的路线，以降低管理代价和风险。经济基础。建立规范化的研发管理是需要一定的投资的，例如咨询、培训、购买工具等等。小型软件机构通常没有钱去做这件事情，望洋兴叹。中型机构能够养活50－200人，表示它们是有一定经济实力的，只要投资额适当而且产生的效益高于投资，那么中型机构一般都愿意做这件事情。

发展欲望。有些中型机构的领导雄心勃勃，高瞻远瞩，他们迫切希望提高研发管理能力从而提升整个企业的核心竞争力，产生源源不断的推动力，推动企业持续发展壮大。他们对研发管理的态度是主动的，而不是被动的。

3.2费用估算国内一些大型IT企业建立了完整的研发管理体系，投资巨大。例如上海贝尔、华为分别请HP、IBM建立研发管理体系，投资额分别达到数千万元、上亿元。这种投资额是中型企业望尘莫及的。在研发管理方面，中型企业无法效仿大型企业的做法。国内中型软件机构对研发管理的投资额大约在数万元至元数十万元。这点“小钱”根本无法引入IBM、HP、Rational等公司的研发管理解决方案。

大部分国内中型软件机构需要的是“轻量级”的研发管理解决方案，包括咨询、培训、购买工具，总费用在5万元至20万元之间比较合适。

3.中型企业的研发管理需求3.1需求特征4.基础方法论介绍－CMM4.1基本概念产品是在过程中研制出来的。一般地，好的过程才可能得到好的产品，而差的过程只会得到差的产品。提高软件过程能力的实践通称为软件过程改进（SoftwareProcessImprovement）。软件过程改进的根本目的是：提高质量、提高生产率并且降低开发成本。

CMM/CMMI是世界范围内用于衡量软件过程能力的事实上的标准，同时也是软件过程改进最权威的指南。

CMM等级评估：从狂热回归理性。现在软件业界普遍关注的是：企业如何以比较低的代价有效地提高软件过程能力。CMM等级评估则退居次要地位。

4.2CMM的盲区和常见应用问题CMM本身不谈如何赚钱的问题。它假设了美好的前提条件，即企业有充足的人员、资金、时间从事软件过程改进，当软件过程能力提高了，那么产品的质量、生产率自然上去了（同时成本也下降了），企业自然能够获取更多的利润。软件过程改进对企业经济效益的贡献是间接的，从投入到产出，时间相对比较长。

企业领导当然想把资源用在“刀刃”上，即赚钱最多最快的地方。当软件过程改进和其它直接赚钱的事情“发生资源冲突”时，人们只好“拆东墙，补西墙”，往往减少软件过程改进的资源。小结：对于软件过程改进而言，CMM/CMMI和ISO等等都是用来参考的，而不是用来迷信的。企业在参考业界推荐的标准或规范时，要舍弃那些听起来很先进但是对本企业无益处的东西，只选取对企业有实用价值的东西。4.基础方法论介绍－CMM4.1基本概念5.基础方法论介绍－PMBOK5.1基本概念项目管理协会（PMI）是目前全球影响最大的项目管理专业机构，该机构的项目管理专家认证（PMP）被广泛认同。PMI的突出贡献是总结了一套项目管理知识体系（PMBOK）。

PMBOK把项目管理知识划分为九个知识领域：综合管理、范围管理、时间管理、成本管理、质量管理、人力资源管理、沟通管理、风险管理和采购管理。每个知识领域包括数量不等的项目管理过程。5.2PMBOK和CMM/CMMI对比简评CMM/CMMI论述的项目管理方法仅仅适用于软件项目，但是不适用于其它行业的项目管理。PMBOK论述的方法适用于任何行业的项目管理，但是对软件项目管理而言，PMBOK的针对性不够强。

CMM/CMMI不仅论述软件项目管理，而且论述整个机构的软件研发管理。PMBOK的方法局限于项目管理，对于企业研发管理则不够用。

CMM/CMMI基本上不谈“成本管理”和“人力资源管理”，它先假设机构有充足的资金和人力资源，通常不切合企业实际情况。因此PMBOK的“成本管理”和“人力资源管理”可以弥补CMM/CMMI的不足。

建议：对于软件机构研发管理或者软件项目管理，采用CMM/CMMI为主导的方法论，并结合PMBOK的知识，取长补短。5.基础方法论介绍－PMBOK5.1基本概念6.基础方法论介绍－敏捷开发6.1基本概念2001年，为了解决许多公司的软件团队陷入不断扩大的过程泥潭，一批业界专家概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则，他们称自己为敏捷联盟（AgileAlliance）。他们起草了一个旨在鼓励更好的软件开发方法的宣言，称为敏捷联盟宣言（TheManifestooftheAgileAlliance）。然后在该宣言基础上制定了12条原则用于指导实践。该宣言和12条原则是敏捷软件开发方法的核心。

6.2我们的观点敏捷软件开发的宣言和12条原则并非普遍适用。敏捷开发方法表达了“简单、快速、实用”的软件开发思想，它不是成熟的理论、也不是事实上的标准（不象CMM,PMBOK那样具有严密的理论体系，被企业广泛接受）。即使人们认同某些原则，但是不同的人往往有不同的理解，实践差异很大。敏捷开发方法对于提高个人、小型团队的工作效率是很有帮助的（如果用对了的话）。但是企图用它指导大型、中型软件机构的研发管理是有很高风险的，它的某些主张是局部观点而不是全局观点，如果把握不好分寸的话可能导致整体混乱，而“整体的混乱”会淹没“局部的好处”。我们研制的“精简并行过程（SPP）”的理论基础是“经典软件工程、CMM、PMBOK”。为了提高效率，在局部地方借鉴了“敏捷软件开发的思想”，用于裁减过于冗长、笨重的过程规范。6.基础方法论介绍－敏捷开发6.1基本概念6.基础方法论介绍－敏捷开发敏捷软件开发的12条原则：（1）我们最优先要做的是通过尽早地、持续地交付有价值的软件来使客户满意。

（2）即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。（3）经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。

（4）在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。

（5）围绕被激励起来的个人来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。

（6）在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。

（7）可以工作的软件是首要的进度度量标准。

（8）敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。

（9）不断地关注优秀的技能和好的设计会增强敏捷能力。

（10）简单——把无需做的工作最大化的艺术——是最根本的。

（11）最好的构架、需求和设计出于自我组织的团队。

（12）每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。6.基础方法论介绍－敏捷开发敏捷软件开发的