首页  编辑  

软件项目管理(国信德勤)

Tags: /超级猛料/Software.软件工程/项目管理/   Date Created:

国信培训要点和参考

软件项目管理PPT已删除。

了解怎样去估算项目的工作量和成本、什么是 Delphi 、功能点和 PROBE 等估算方法、以及怎样制订项目预算和进度表及如何制订项目整体计划;如何来选择生命周期;如何分解项目,如何预测项目进度和规模;如何监督和控制项目;如何管理风险;以及如何度量项目;

1        PETS 表, WBS 分解表格可以参考和使用

2         功能点方法进行评估软件规模方面有用

3         根据估算规模和项目特点选择不同的生命周期

4         生命周期选择之后,必须设定里程碑,并根据里程碑把握进度;

5         生命周期选择后, PM 应该制定每个周期、里程碑中的标准活动;

6         指定标准活动后,根据经验或者讨论制定工作量,时间范围,进度控制等;

7         分解可以自顶向下,工作量 / 规模等估算可以从下向上

8         项目评审总结需要记录项目的规模,工作量,生产力等数据

9         根据记录的数据建立预测关系,如果强相关 R 2 逼近 1 ,则可以根据一个因素预测另外一个因素;

10         鼎利研发部项目一般没有控制预算,但项目经理应该有这个概念,对项目组的成本心里面应该有底;

11        PM 对任何事情,处理的时候把握:自己做,委托别人实现,外包(移交其他项目组等)等;

12         鼎利的问题在于,对于某些工作没有严格指定责任人,以后应该严格指定责任人

13         评审要执行好,严格执行

14         建议鼎利根据自己的实际情况,制定一套自己的合适的规范流程,规范软件的研发;

15         严格的项目管理会比较繁琐,但我们可以借鉴,应该心中有数;

16         项目经理应该严格控制项目成员的进度情况,不能依赖研发人员自己的自觉性

17         结合 URTrack ,配合 PETS WBS 分解表格,进行进度控制;

18         检查不能在进度的末尾检查,应该在前期进行检查,不能被动等待,应该主动检查,项目经理应该自己明确那些检查点,并在检查点的时候主动检查;

19         鼎利目前的做法其实是挺不错的,但是没有严格要求和严格执行;

20         项目经理应该按照 PETS WBS 分解表,填写表格和检查,严格控制进度;

21         项目经理需要对工作日志进行整理和统计分析,建立资源模型,用于得到每个阶段工作量,工时数据等,可以为以后的估算,进度控制等进行数据积累;

22         项目跟踪:进度(安排的每个任务,里程碑); 工作量跟踪 (日报),鼎利缺少工作量的跟踪;属性跟踪(需求,规模,);

23         项目应该建立需求库,对需求进行跟踪和管理;

24         可以根据周报,日报,里程碑报告的内容来反推需要检查和跟踪的内容,进行项目管理和跟踪;

25         综合项目管理:公司的软件研发,应该对各个项目和产品进行分类,对每个分类要规定一些研发的步骤,进行裁剪等,因为每个项目不可能遵循所有的生命周期的所有步骤和研发的所有的活动过程;

26         培训提高不能胜任的角色的技能;

27         制度要有执行力,规范要严格执行;

28         承诺之前要协商,承诺之后要承担责任;

29        CMMI3 没有大量的数据,只能作为定性管理, CMMI4 采集了大量的历史数据,可以进行精细化的定量管理;

30        PM 应该每周、每月,或者里程碑的时候,对 AC (实际工时), PV (计划工时), EV (已完成任务的总工时),计算 CPI SPI ,形成图形化(增值图等)的显示,以便可以直观地显示精度的偏差; CPI SPI 的计算,参考附加资料

31         提高生产力

32         每个研发人员测量和度量花费 5 分钟即可,不要太多,但一定要坚持,度量数据包括:任务的计划工时,实际工时,代码行数等等;

33        PM 管理思想应该引导给项目组成员, PM 应该让员工从被动到习惯到主动自觉地去参与项目管理和度量数据采集;

34         项目组成员进度偏离时, PM 应该陪着项目组成员完成任务,追赶进度,直到赶上为止;

35         每个员工应该每天明白自己每天工作的有效时间:据统计,一般每天每个员工真正有效的时间为 3-4 个小时;(有同感)

36         设计评审时间应该是设计时间的一半左右,少于三分之一不合格;测试的时候,单元测试应该找出的 Bug 一般建议在 5 个左右,太少和太多都不好;测试时间也是开发时间的一半左右,少于三分之一也不好;

37         告诫研发人员不要浪费时间在调试上,而是应该在算法流程和逻辑思路的理清上面;

38         研发人员的自我单元测试和白盒测试不够,而且没有真正地有效地进行;

39         测试的二八定理: 80% 的问题占最多的几类问题,要重点改进;测试检查单的检查项:要对测试的问题进行分类,找出最容易出现问题的几类,重点解决;测试人员可以填写 Pareto 图; 1         测试部要积累数据

40         代码审查九句真言:

a)         看见 If ,就要想到 else

b)         看见 Malloc ,就要找 Free

c)         函数调用要小心,需要看看返回值;

d)         看见 for 循环,就找边界值;

e)         看见 return 要注意,要去前面找资源;

f)         看见数组就要找下标

g)         字符串,就要看长度;

h)         看到函数,就要看变量初始化;

i)         赋值函数,要检查初始化;

41         工作不饱满怎么办?如果研发进度不是很饱满,那么可以测试,交叉测试,代码审查,文档编写,学习专业知识,主动请求其他的任务,而不是去聊天,上网等等;

42         度量可以针对某些属性来做,例如可以先实现规模的度量,也可以针对生产率,也可以针对工作量等;

43         项目经理应该在项目管理当中,逐渐培养研发人员,让有培养潜力的人员逐渐参与项目管理工作,以对抗项目经理离职的情况;

44         度量体系

a)         确定度量指标:指标的名称,用途等

b)         根据度量信息模型和构造,进行分解,分解为指示器,直到分解为实体和属性,把这些信息落实到底层的文档;

c)         分析属性属于那个实体,那个表格等;

d)         通过测量来采集数据

e)         度量负责人对测量的数据进行分析,统计和生成报告;

45         测试报告:统计生成 PPT 和图表,发送给 PM 和管理层。每周要给出测试得到的 BUG 数,严重等级类别,解决的问题数,总的未解决的问题数等样本数据,生成趋势图等;

R平方预测.xls (15.0KB)
功能点方法--计算调整因子.pdf (28.3KB)
功能点计算.xls (13.5KB)
补充材料-功能点方法.pdf (227.8KB)
补充材料.pdf (483.2KB)
软件领域的典型活动 from Capers Jones.doc (63.5KB)
项目计划书模版.doc (65.5KB)