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

上 海 漫 索 计 算 机 科 技 有 限 公 司

软件研发管理问题和解决方案 常见问题分析 基础方法论介绍 整体解决方案

林

锐

博士linrui@

目录1. 企业研发管理的理念 2. 常见问题分析 3. 中型企业的研发管理需求 4. 基础方法论介绍-CMM 5. 基础方法论介绍- PMBOK 6. 基础方法论介绍-敏捷开发 7. 基础方法论介绍- RUP 8. 面向企业的软件研发管理解决方案 9. 基于Web的集成化项目管理系统 Future3.0

Page 2

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

企业的根本目标是“合法地赚取尽可能多的利润，使企业利益最大化”。企业所有的特定目 标和行动都是围绕根本目标开展的。根本目标进一步决定了企业研发管理的目标和策略。

企业研发管理的基本目标是：让所有人员有条不紊地开展工作，在预定的时间和成本之内， 开发完成质量合格的产品，从而使企业和个人获得预定的利益。企业研发管理的奋斗目标是：调动一切积极因素，努力提高产品质量、提高工作效率并且降 低成本，使企业和个人获得比预定目标更多的利益。

1.2 质量、进度(时间)、成本

“质量、进度(时间)、成本”通常是衡量企业研发管理“优劣”的三个关键指标。不同的 企业，甚至同一企业在不同时期，对三者的重要性看法是不一样的。如果出现“三者难以同时兼得”的情况，那么产品的决策者一定要搞清楚质量、进度(时间 )、成本之间的复杂关系，判断孰重孰轻，给出优化和折衷的措施。

1.3 规范化 vs. 超越规范化

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

Page 3

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

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

2.1.2 合同项目的立项问题

委托方(客户方)和承包方(开发方)在签订合同的时候，双方对软件需求的了解

并 不深入，合同中对“开发什么”的描述比较空洞。合同签订之后，客户经常变更需求 ，开发方被迫不断修改软件，弄得疲惫不堪。夸张地概括：除了合同金额不变，其它 一切都可能改变。刚签订合同时开发方似乎赚钱了，后头却可能得不偿失。 双方在签订合同的过程中给出了一些空头承诺(例如对进度、质量、费用的估计过于 乐观),在实际执行时却难以兑现这些承诺。处理不好将引发合同纠纷，轻则双方提 前终止合同，重则双方反目成仇。

2.1.3 建议

创建一种群体决策的立项管理规范，不仅让群众贡献智慧，而且让群众分 担责任，使成功的经验被企业不断复用，并升华成为企业的制度。Page 4

2.2 常见问题分析： 结项管理2.2.1 共性问题

某些项目由于进度拖延，不能按计划结项；某些项目即使开发完成了，由于利益关系也不愿结项 。这些“不良”项目或者已经完成的项目一直占用企业资源(如人力资源和设备),无疑违背企 业利益最大化的目标。 在结项时，人们往往对财务和设备进行了详细的清算，却忽视了对知识财富、经验教训的总结。 殊不知设备越用越差，但是知识财富越用越好，可谓主次颠倒。 没有对项目的价值进行评估，开发人员干完活后，不知道自己的工作成果产生多大的效益，缺乏 成就感。 结项后，不能对员工的业绩进行公正考核，自然不能很好地激励员工。 合同软件项目在结项之前，还面临“客户验收”的一些问题。例如缺乏双方认同的“验收标准” ,导致验收过程混乱，过多地消耗双方的精力。

2.2.2 建议

首要措施是建立企业的“结项管理规范”和“验收与发布”规范。

自主研发的软件产品在结项之前，公司内部要进行类似的“验收”,防止不良项目蒙混过关。

Page 5

2.3 常见问题分析：项目规划2.3.1 共性问题

在项目刚开始阶段，人们对产品需求和技术的了解还比较肤浅，项目不确定因素比较多，此时很 难对工作量和进度作出比较准确的估算。软件工程教科书和CMM推荐的COCOMO模型、代码行 估算方法等等，对大多数国内项目无法适用，效果如同“电脑算命”。由此制定的项目计划可能 不切实际，后面经常发生项目计划的变更(所以业界流传“计划快不如变化快”),将导致项目 管理的复杂性和风险提高。 项目的人员已经被上级领导限定死了，再多的活也是那几个人干；项目的结束日期早就被领导和 客户指定了，不管合理不合理，反正时间一到就要交付软件；除了办公计算机和工资外，这个项 目没有其它经费，项目经理只有干活的权利没有用钱的权利。如

果人员、资金、时间都已经被毫 无道理地指定了，那么项目规划就失去意义，这样的项目在国内非常普遍。

2.3.2 建议

建立企业的“项目规划规范”,给出合适的项目估算方法和项目计划模板。 使用方便的软件工具，帮助项目经理进行项目规划。

Page 6

2.4 常见问题分析：项目监控2.4.1 共性问题

许多项目经理肩负重要的软件开发工作，他们往往把注意力集中在开发上面，很少认真考虑如何 进行项目监控 。

没有突出项目监控的重点，项目经理要么什么都不监控(导致项目失控),要么监控得太多而陷 入琐碎事务中。项目经理写周期性项目进展报告时，记流水帐，或者复制上次的报告，应付了事。懒得动脑筋分 析项目遇到的一些问题，例如某些任务的进度延误了，不分析为什么延误了，就顺延。导致问题 越积越多。 项目实际执行情况与原定的项目计划严重脱节，领导、客户、市场人员、开发团队不了解项目真 正的状况，使项目计划行同虚设。

2.4.2 建议

建立企业的“项目监控规范”,使用方便的软件工具，帮助项目经理进行项目监控。 上级领导和相关人员每周都要检查项目的监控要素，及时发现问题，及时解决问题，既要关心结 果也要关心过程。

Page 7

2.5 常见问题分析：配置管理和变更管理2.5.1 共性问题

有些软件机构竟然不使用软件配置管理工具，用最原始的方式手工管理代码和文档，经常出现“ 成果丢失、版本混乱”等问题。

不少机构按照的CMM的要求制定了配置管理规范。该规范在理论上比较完善，面面俱到，但是实际 操作比较麻烦，没有突出重点。久而久之，人们厌烦后就逐渐放弃了规范，按自己的习惯操作， 留下了隐患。例如不少程序被 checkout 后长久没有 checkin;有些程序保留在开发者本机，根 本就没有放入配置库。维护期间修改了程序，但是没有放入配置库。 没有变更控制流程，经常随意变更需求、设计、代码等，严重影响项目的正常开发进程。

2.5.2 建议

建立简单有效的“配置管理规范”和“变更管理规范”。 并使用方便的工具，帮助团队进行软件配置管理和变更管理。

Page 8

2.6 常见问题分析：质量管理2.6.1 共性问题

虽然人们大都认可软件的质量很重要，但是许多软件人员并不懂得如何有效地改善软件质量属性 如正确性、健壮性、可靠性、性能、易用性、安全性、可扩展性、可复用性、兼容性、可移植性 等等。不会分析当前软件的质量要素是什么，没有把精力集中在改善对经济效益贡献最大的质量 要素上面。 有些软件机构没有软件质量管

理的措施，开发人员把完成功能当成终极目标。用户在使用软件的 过程中发现许多Bug,导致开发方的纠错性维护代价很高。 有些软件机构虽然很重视软件质量，按照ISO,CMM 的要求建立了管理规范，但是效果不明显。 人们搞不清楚软件测试、技术评审、质量保证的作用和关系。不懂得内建质量，主要靠修补错误 的方式提升质量，代价比较高。 很多人误以为提高软件质量是质量保证人员和测试人员的责任，没有意识到任何开发人员、管理 人员都会对质量产生影响，都要对质量负责。另外，质量保证人员的权力比较小，很难推动质量 改进措施。

2.6.2 建议

让人们理解“什么是软件质量”及常见的软件质量属性，树立全面软件质量管理的理念(模型) ,制定软件测试、技术评审、质量保证的规范。 并使用方便的工具，帮助团队进行软件质量管理。

Page 9

2.7 常见问题分析：需求开发与管理2.7.1 共性问题

对于大部分软件机构而言，需求开发与需求管理是问题最多、最难解决的过程域。 软件机构中，通晓需求调查、需求分析、需求定义、需求评审、需求跟踪、需求变更控制的人员 本来就比较少，也不容易招聘和培养这样的人才。 用户说不清楚需求、用户经常变更需求是普遍现象，令开发方非常头痛。 开发人员不善于写文档，很难写出清楚、完整的软件需求规格说明书。后续开发人员可能误解需 求，做出与需求不一致的设计、代码、测试用例等等，最后不得不大量返工重做。 最难办的事情是莫过于“拒绝客户提出的需求变更请求”。客户会想当然地以为变更需求是他的 权利，因为他付钱给开发方。通常情况下开发方是不敢得罪客户的，但是无原则地退让将使开发 小组陷入困境。

2.7.2 建议

建立“需求开发与管理规范”,给出合适的文档模板，采用方便的需求分析和管理工具。 还要多请有经验的人来培训、传授实战经验。 制定应对需求变更的办法，例如：(1)双方签订需求变更管理协议;(2)将重大需求变更延缓到下个 软件版本中实现;(3)让客户欠下人情。

Page 10

2.8 常见问题分析：软件设计2.8.1 共性问题

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

户的认可。 大部分软件机构都有一些技术出色的软件人员，他们在系统构架、数据库方面的设计能力相当不 错。但是很多人不愿意、不善于写系统设计报告，这不利于后续的软件开发和维护。 软件设计应当“细到什么程度”很难把握。太粗了的话，对后续开发工作的指导价值不高；反之 倘若太细的话，耗费时间就比较多，如果后面不断改进设计的话，前面的设计浪费太多。

2.8.2 建议

建立“软件设计规范”,给出合适的文档模板，采用方便的设计工具。 还要多请有经验的人来培训、传授实战经验。

Page 11

2.9 常见问题分析：编程与调试2.9.1 共性问题

软件机构的大部分程序员的技能是合格的，但是他们编写的程序风格差异较大，代码质量有高有 低。大多数软件机构没有编程规范，即使有的话，开发人员也没有很好地按规范编程。

相当多的程序员没有养成对所有代码进行“单步跟踪调试”的习惯。嫌单元测试很麻烦，懒得执行，却没有替代方案。

2.9.2 建议

制定简单明了、重点突出的“编程规范”,让团队遵照此规范编写程序。 采用集成化的开发调试工具，提高编程质量和效率。

Page 12

2.10 常见问题分析：软件测试2.10.1 共性问题

许多软件人员没有系统地学习过软件测试，搞不清楚各种测试的概念，例如单元测试、集成测试 、验收测试、黑盒测试、白盒测试、功能测试、性能测试等等，混为一谈，不知如何下手。

测试人员没有掌握有效测试的方法，大多凭感觉测试，结果重复测试已经测试过的，那些深藏的 bug却发现不了。客户在使用软件的过程中发现的bug比公司内部测试时发现的还多，不仅改错代 价高，而且降低了客户对产品的满意度。团队没有采用有效的缺陷跟踪工具。测试人员发现bug时，口头告知有关人员或者记在Word、 Excel文件中，修改bug信息或者测试报告时非常麻烦。难以及时从bug列表中找出规律，测试的效 率比较低。

2.9.2 建议

建立“软件测试规范”,采用方便的测试管理工具。 还要多请有经验的人来培训、传授实战经验。

Page 13

2.11 常见问题分析：软件维护2.11.1 共性问题

在维护期间，除了纠错性维护外，客户可能提出需求变更(但是不支付费用),维护人员对客户 妥协，导致维护工作量增大、成本增加。

如果是合同软件项目，用户对开发方的依赖性比较大，不愿意自己解决粗浅的问题，经常叫开发 方“干这干那”。开发方不敢得罪客户，导致开发方做了许多不属于维护的工作，吃哑巴亏。开发人员一边开发新项目，一边维护老项目。而维护

为体现不出业绩，又影响了新项目的进度， 开发人员比较心烦。

2.11.2 建议

制定“软件维护规范”,界定什么是“免费维护”、什么是“有偿维护”,以及相应的操作规则 ，提高维护效率并且降低维护成本。

Page 14

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

2.11.2 项目经理的财务权

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

3. 中型企业的研发管理需求3.1 需求特征

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

而且产生的效益高于投资， 那么中型机构一般都愿意做这件事情。

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

3.2 费用估算

国内一些大型IT企业建立了完整的研发管理体系，投资巨大。例如上海贝尔、华为分 别请HP、IBM建立研发管理体系，投资额分别达到数千万元、上亿元。这种投资额是 中型企业望尘莫及的。在研发管理方面，中型企业无法效仿大型企业的做法。国内中 型软件机构对研发管理的投资额大约在数万元至元数十万元。这点“小钱”根本无法 引入IBM、HP、Rational等公司的研发管理解决方案。 大部分国内中型软件机构需要的是“轻量级”的研发管理解决方案，包括咨询、培 训、购买工具，总费用在5万元至20万元之间比较合适。Page 16

4. 基础方法论介绍-CMM4.1 基本概念

产品是在过程中研制出来的。一般地，好的过程才可能得到好的产品，而差的过程只 会得到差的产品。提高软件过程能力的实践通称为软件过程改进(Software Process Improvement)。软件过程改进的根本目的是：提高质量、提高生产率并且降低开发 成本。 CMM/CMMI是世界范围内用于衡量软件过程能力的事实上的标准，同时也是软件过 程改进最权威的指南。 CMM等级评估：从狂热回归理性。现在软件业界普遍关注的是：企业如何以比较低的 代价有效地提高软件过程能力。CMM等级评估则退居次要地位。

4.2 CMM的盲区和常见应用问题

CMM本身不谈如何赚钱的问题。它假设了美好的前提条件，即企业有充足的人员、资 金、时间从事软件过程改进，当软件过程能力提高了，那么产品的质量、生产率自然 上去了(同时成本也下降了),企业自然能够获取更多的利润。软件过程改进对企业 经济效益的贡献是间接的，从投入到产出，时间相对比较长。 企业领导当然想把资源用在“刀刃”上，即赚钱最多最快的地方。当软件过程改进和 其它直接赚钱的事情“发生资源冲突”时，人们只好“拆东墙，补西墙”,往往减 少软件过程改进的资源。 小结：对于软件过程改进而言，CMM/CMMI和ISO等等都是用来参考的，而不是用来迷 信的。企业在参考业界推荐的标准或规范时，要舍弃那些听起来很先进但是对本企业 无益处的东西，只选取对企业有实用价值的东西。Page 17

5. 基础方法论介绍-PMBOK5.1 基本概念

项目管理协会(PMI)是目前全球影响最大的项目管理专业机构，该

机构的项目管理专家认证( PMP)被广泛认同。PMI的突出贡献是总结了一套项目管理知识体系(PMBOK)。

PMBOK把项目管理知识划分为九个知识领域：综合管理、范围管理、时间管理、成本管理、质 量管理、人力资源管理、沟通管理、风险管理和采购管理。每个知识领域包括数量不等的项目管 理过程。

5.2 PMBOK和CMM/CMMI对比简评

CMM/CMMI论述的项目管理方法仅仅适用于软件项目，但是不适用于其它行业的项目管理。PMBOK论 述的方法适用于任何行业的项目管理，但是对软件项目管理而言，PMBOK的针对性不够强。 CMM/CMMI不仅论述软件项目管理，而且论述整个机构的软件研发管理。PMBOK的方法局限于项目管 理，对于企业研发管理则不够用。 CMM/CMMI基本上不谈“成本管理”和“人力资源管理”,它先假设机构有充足的资金和人力资源 ，通常不切合企业实际情况。因此PMBOK的“成本管理”和“人力资源管理”可以弥补CMM/CMMI的 不足。 建议：对于软件机构研发管理或者软件项目管理，采用CMM/CMMI为主导的方法论，并结合PMBOK的 知识，取长补短。

Page 18

6. 基础方法论介绍-敏捷开发6.1 基本概念

2001年，为了解决许多公司的软件团队陷入不断扩大的过程泥潭，一批业界专家概括出了一些可 以让软件开发团队具有快速工作、响应变化能力的价值观和原则，他们称自己为敏捷联盟(Agile Alliance)。他们起草了一个旨在鼓励更好的软件开发方法的宣言，称为敏捷联盟宣言(The Manifesto of the Agile Alliance)。然后在该宣言基础上制定了12条原则用于指导实践。该宣言和 12条原则是敏捷软件开发方法的核心。

6.2 我们的观点

敏捷软件开发的宣言和12条原则并非普遍适用。

敏捷开发方法表达了“简单、快速、实用”的软件开发思想，它不是成熟的理论、也不是事实上 的标准(不象CMM, PMBOK那样具有严密的理论体系，被企业广泛接受)。即使人们认同某些原则 ，但是不同的人往往有不同的理解，实践差异很大。敏捷开发方法对于提高个人、小型团队的工作效率是很有帮助的(如果用对了的话)。但是企图 用它指导大型、中型软件机构的研发管理是有很高风险的，它的某些主张是局部观点而不是全局 观点，如果把握不好分寸的话可能导致整体混乱，而“整体的混乱”会淹没“局部的好处”。 我们研制的“精简并行过程(SPP)”的理论基础是“经典软件工程、CMM、PMBOK”。为了提高效率 ，在局部地方借鉴了“敏捷软件开发的思想”,用于裁减过于冗长、笨重的过程规范。

Page 19

6. 基础方法论介绍-敏捷开发敏捷软件开发的12条原则

:

(1)我们最优先要做的是通过尽早地、持续地交付有价值的软件来使客户满意。 (2)即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

(3)经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。(4)在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。 (5)围绕被激励起来的个人来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。 (6)在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。 (7)可以工作的软件是首要的进度度量标准。 (8)敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。 (9)不断地关注优秀的技能和好的设计会增强敏捷能力。 (10)简单——把无需做的工作最大化的艺术——是最根本的。 (11)最好的构架、需求和设计出于自我组织的团队。

(12)每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。

Page 20

7. 基础方法论介绍-RUP7.1 基本概念

RUP(Rational Unified Process)是Rational公司推出的软件过程模型，它是软件 业界迄今为止商品化最成功的软件过程模型。RUP的近千页文档可以从Rational公司 的网站()下载，RUP 2000中文版也已经发布。 RUP的主要特征是： – 采用迭代的、增量式的开发过程。 – 采用UML语言描述软件开发过程。 – 有一系列功能强大的软件工具支撑(Rational公司的软件产品)。

7.2 我们的观点

RUP及其配套软件工具是重量级的软件研发管理解决方案，它面向的是高端用户，对 用户的财力、开发和管理能力要求都很高： – 首先，用户得有钱买Rational的软件工具，否则光有RUP方法论如同纸上谈兵。 – 如果要使用RUP方法，人们得先熟悉UML,否则除了RUP模型图之外你基本上看不 懂细节内容。可是在普通企业里，大部分人(尤其是领导和管理人员)不熟悉 UML。学习UML和RUP的难度远高于CMM和PMBOK。

– 项目经理和开发组长要有能力控制迭代过程，否则迭代式开发就变得混乱无序 和漫无边际 RUP及其配套的软件工具基本上不适合于国内中型和小型软件机构。Page 21

本文来源：https://www.bwwdw.com/article/pjj1.html