面向企业的软件研发管理解决方案-林锐培训资料.ppt

1、http:/ 上上 海海 漫漫 索索 计计 算算 机机 科科 技技 有有 限限 公公 司司面向企业的软件研发管理解决方案面向企业的软件研发管理解决方案常见问题分析常见问题分析基础方法论介绍基础方法论介绍整体解决方案整体解决方案林林 锐锐 博士博士Page 2目录目录1.企业研发管理的理念企业研发管理的理念2.常见问题分析常见问题分析3.中型企业的研发管理需求中型企业的研发管理需求4.基础方法论介绍基础方法论介绍CMM5.基础方法论介绍基础方法论介绍 PMBOK6.基础方法论介绍敏捷开发基础方法论介绍敏捷开发7.基础方法论介绍基础方法论介绍 RUP8.漫索公司的软件研发管理解决方案漫索公司的软件

2、研发管理解决方案9.基于基于Web的集成化软件研发管理系统的集成化软件研发管理系统 Future2.0 介绍介绍10.相关著作相关著作Page 31.企业研发管理的理念企业研发管理的理念1.1 1.1 目标目标企企业业的的根根本本目目标标是是“合合法法地地赚赚取取尽尽可可能能多多的的利利润润，使使企企业业利利益益最最大大化化”。企业所有的特定目标和行动都是围绕根本目标开展的。根本目标进一步决定了企业研发管理的目标和策略。企业研发管理的基本目标是：让让所所有有人人员员有有条条不不紊紊地地开开展展工工作作，在在预预定定的的时时间间和和成成本本之之内内，开发完成质量合格的产品，从而使企业和个人获得预

3、定的利益开发完成质量合格的产品，从而使企业和个人获得预定的利益。企业研发管理的奋斗目标是：调动一切积极因素，努力提高产品质量、提高工作效率并且降调动一切积极因素，努力提高产品质量、提高工作效率并且降低成本，使企业和个人获得比预定目标更多的利益低成本，使企业和个人获得比预定目标更多的利益。1.2 1.2 质量、进度（时间）、成本质量、进度（时间）、成本“质量、进度（时间）、成本”通常是衡量企业研发管理“优劣”的三个关键指标。不同的企业，甚至同一企业在不同时期，对三者的重要性看法是不一样的。如果出现“三者难以同时兼得”的情况，那么产品的决策者一定要搞清楚质量、进度（时间）、成本之间的复杂关系，判断

4、孰重孰轻，给出优化和折衷的措施。1.3 1.3 规范化规范化 vs.vs.超越规范化超越规范化在企业里，大部分的工作是成熟的，有成功的模式可以套用，应当走规范化的路线；而另外在企业里，大部分的工作是成熟的，有成功的模式可以套用，应当走规范化的路线；而另外小部分的工作可能是独特的，并不适宜套用规范（也可能没有规范可以套用），那么应当采小部分的工作可能是独特的，并不适宜套用规范（也可能没有规范可以套用），那么应当采用超越规范化的管理方式。用超越规范化的管理方式。通常前者约占80%，而后者约占20%Page 42.1 常见问题分析：立项管理常见问题分析：立项管理2.1.1 2.1.1 自主研发产品的

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

6、题导致进度延误、费用超支等问题。2.1.2 2.1.2 合同项目的立项问题合同项目的立项问题委托方（客户方）和承包方（开发方）在签订合同的时候，双方对软件需求的了解并不深入，合合同同中中对对“开开发发什什么么”的的描描述述比比较较空空洞洞。合合同同签签订订之之后后，客客户户经经常常变变更更需需求求，开开发发方方被被迫迫不不断断修修改改软软件件，弄弄得得疲疲惫惫不不堪堪。夸张地概括：除了合同金额不变，其它一切都可能改变。刚签订合同时开发方似乎赚钱了，后头却可能得不偿失。双方在签订合同的过程中给出了一些空头承诺（例如对进度、质量、费用的估计过于乐观），在实际执行时却难以兑现这些承诺。处理不好将引发

7、合同纠纷，轻则双方提前终止合同，重则双方反目成仇。2.1.3 2.1.3 建议建议创创建建一一种种群群体体决决策策的的立立项项管管理理规规范范，不不仅仅让让群群众众贡贡献献智智慧慧，而而且且让让群群众众分分担担责责任任，使使成功的经验被企业不断复用，并升华成为企业的制度成功的经验被企业不断复用，并升华成为企业的制度。Page 52.2 常见问题分析：常见问题分析：结项管理结项管理2.2.1 2.2.1 共性问题共性问题某些项目由于进度拖延，不能按计划结项；某些项目即使开发完成了，由于利益关系也不愿结项。这些“不良”项目或者已经完成的项目一直占用企业资源（如人力资源和设备），无疑违背企业利益最大

8、化的目标。在结项时，人们往往对财务和设备进行了详细的清算，却忽视了对知识财富、经验教训的总结。殊不知设备越用越差，但是知识财富越用越好，可谓主次颠倒。没有对项目的价值进行评估，开发人员干完活后，不知道自己的工作成果产生多大的效益，缺乏成就感。结项后，不能对员工的业绩进行公正考核，自然不能很好地激励员工。合同软件项目在结项之前，还面临“客户验收”的一些问题。例如缺乏双方认同的“验收标准”，导致验收过程混乱，过多地消耗双方的精力。2.2.2 2.2.2 建议建议首要措施是建立企业的“结项管理规范”和“验收与发布”规范。自主研发的软件产品在结项之前，公司内部要进行类似的“验收”，防止不良项目蒙混过关

9、。Page 62.3 常见问题分析：项目规划常见问题分析：项目规划2.3.1 2.3.1 共性问题共性问题在项目刚开始阶段，人们对产品需求和技术的了解还比较肤浅，项目不确定因素比较多，此时很很难对工作量和进度作出比较准确的估算。难对工作量和进度作出比较准确的估算。软件工程教科书和CMM推荐的COCOMO模型、代码行估算方法等等，对大多数国内项目无法适用，效果如同“电脑算命”。由此制定的项目计划可能项目计划可能不切实际，后面经常发生项目计划的变更（所以业界流传不切实际，后面经常发生项目计划的变更（所以业界流传“计划快不如变化快计划快不如变化快”），将导致项目），将导致项目管理的复杂性和风险提高。

10、管理的复杂性和风险提高。项目的人员已经被上级领导限定死了，再多的活也是那几个人干；项目的结束日期早就被领导和客户指定了，不管合理不合理，反正时间一到就要交付软件；除了办公计算机和工资外，这个项目没有其它经费，项目经理只有干活的权利没有用钱的权利。如果人员、资金、时间都已经被毫如果人员、资金、时间都已经被毫无道理地指定了，那么项目规划就失去意义，这样的项目在国内非常普遍。无道理地指定了，那么项目规划就失去意义，这样的项目在国内非常普遍。2.3.2.3.2 2 建议建议建立企业的“项目规划规范”，给出合适的项目估算方法和项目计划模板。使用方便的软件工具，帮助项目经理进行项目规划。Page 72.4

11、 常见问题分析：项目监控常见问题分析：项目监控2.4.1 2.4.1 共性问题共性问题许多项目经理肩负重要的软件开发工作，他们往往把注意力集中在开发上面，很少认真考虑如何进行项目监控。没有突出项目监控的重点，项目经理要么什么都不监控（导致项目失控），要么监控得太多而陷入琐碎事务中。项目经理写周期性项目进展报告时，记流水帐，或者复制上次的报告，应付了事。懒得动脑筋分析项目遇到的一些问题，例如某些任务的进度延误了，不分析为什么延误了，就顺延。导致问题越积越多。项目实际执行情况与原定的项目计划严重脱节，领导、客户、市场人员、开发团队不了解项目真正的状况，使项目计划行同虚设。2.4.2.4.2 2 建

12、议建议建立企业的“项目监控规范”，使用方便的软件工具，帮助项目经理进行项目监控。上级领导和相关人员每周都要检查项目的监控要素，及时发现问题，及时解决问题，既既要要关关心心结结果也要关心过程。果也要关心过程。Page 82.5 常见问题分析：配置管理和变更管理常见问题分析：配置管理和变更管理2.5.1 2.5.1 共性问题共性问题有些软件机构竟然不使用软件配置管理工具，用最原始的方式手工管理代码和文档，经常出现经常出现“成果丢失、版本混乱成果丢失、版本混乱”等问题等问题。不少机构按照的CMM的要求制定了配置管理规范。该规范在理论上比较完善，面面俱到，但是实际操作比较麻烦，没有突出重点。久而久之，

13、人们厌烦后就逐渐放弃了规范，按自己的习惯操作，留下了隐患。例如不少程序被 checkout 后长久没有 checkin；有些程序保留在开发者本机，根本就没有放入配置库。维护期间修改了程序，但是没有放入配置库。没有变更控制流程，经常随意变更需求、设计、代码等，严重影响项目的正常开发进程没有变更控制流程，经常随意变更需求、设计、代码等，严重影响项目的正常开发进程。2.5.2.5.2 2 建议建议建立简单有效的“配置管理规范”和“变更管理规范”。并使用方便的工具，帮助团队进行软件配置管理和变更管理。Page 92.6 常见问题分析：质量管理常见问题分析：质量管理2.6.1 2.6.1 共性问题共性问

14、题虽然人们大都认可软件的质量很重要，但是许多软件人员并不懂得如何有效地改善软件质量属性如正确性、健壮性、可靠性、性能、易用性、安全性、可扩展性、可复用性、兼容性、可移植性等等。不会分析当前软件的质量要素是什么，没有把精力集中在改善对经济效益贡献最大的质量没有把精力集中在改善对经济效益贡献最大的质量要素上面。要素上面。有些软件机构没有软件质量管理的措施，开发人员把完成功能当成终极目标没有软件质量管理的措施，开发人员把完成功能当成终极目标。用户在使用软件的过程中发现许多Bug，导致开发方的纠错性维护代价很高。有些软件机构虽然很重视软件质量，按照按照ISO,CMM 的要求建立了管理规范，但是效果不明

15、显的要求建立了管理规范，但是效果不明显。人们搞不清楚软件测试、技术评审、质量保证的作用和关系。不懂得内建质量，主要靠修补错误不懂得内建质量，主要靠修补错误的方式提升质量，代价比较高的方式提升质量，代价比较高。很多人误以为提高软件质量是质量保证人员和测试人员的责任，没有意识到任何开发人员、管理误以为提高软件质量是质量保证人员和测试人员的责任，没有意识到任何开发人员、管理人员都会对质量产生影响，都要对质量负责。人员都会对质量产生影响，都要对质量负责。另外，质量保证人员的权力比较小，很难推动质量改进措施。2.6.2.6.2 2 建议建议让人们理解“什么是软件质量”及常见的软件质量属性，树立全面软件质

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