但是在很多项目中,反刍管理还没有得到很好的执行,一方面是因为各方面的压力迫使项目管理越来越倾向于“走捷径”,能省略的步骤就省略;另一方面,就是成功的反刍管理的案例没有得到推广和示范,一部分人对此不以为然。以下针对本人在项目管理中的经验,提供一个软件开发反刍管理的报告模板。
我们首先需要确定,PPR回顾的是什么?项目的所有方面,都可以回顾。从管理,协调,技术创新,故障处理,计划等等,当然也包括项目成员的个人总结。所以我认为PPR可以分为两个大类:项目总结,和个体总结。
一、个体总结
个体总结,可以采用PSP(个体软件过程)的模式,模板如文后的附录。
从附录的表格可见,PSP总结突出的是时间管理和故障管理,当然也可以根据项目具体特色,设计总结的条目。例如,我们认为除了这些数据,研发人员还有一些自己思考的事情,如技术创新,也需要总结,还可以按照自己喜欢的任意格式,提交个人总结报告。我们还提供项目论坛,大家可以发表个人看法,或者刊登个人的总结,以便加强交流。
二、项目总结
以下是我制定的软件项目开发总结报告模板,它目前列举的是从计划、协调、质量和其他四个方面进行回顾总结。
XX项目开发总结报告
1.概述
1.1编写目的
< 编写者可以照抄下列语句,说明《开发总结报告》的编写目的,也可以适当修改。
“编写本《开发总结报告》的目的在于对××××软件项目开发过程进行总结,对遇到的困难和解决办法进行反思和总结,为以后软件的改进提供建议,为产品质量改进提供参考。”>
1.2 XX开发环境介绍
<逐项列出相关的项目及其关系。
如A与B项目相关,是属于后者的一个子系统开发,因此制定的计划是后者计划的一部分,同样进度也会受后者的制约。
又如A是基于XX平台的一个子系统,因此他的稳定性和性能受后者制约;由于在此平台上已经开发了×个子系统通过性能样机评审,×个子系统通过设计定型(转产),×个子系统通过实验局和正式开局,所以一些通用模块经过考验,在稳定性和性能等方面有长足改进,也给本子系统的开发减少了风险、难度和工作量。>
1.3参考资料
< 列出相关的文档资料。
如系统设计方案,研制规范,历次测试报告(用于后面分析故障时举例)。>
2.计划总结
2.1开发计划与实践描述
< 简要介绍本软件系统的开发过程,主要是列出原定计划和实际进度。>
开发阶段 |
计划开始时间 |
计划结束时间 |
实际开始时间 |
实际结束时间 |
系统设计 |
|
|
|
|
详细设计 |
|
|
|
|
性能样机测试 |
|
|
|
|
转产 |
|
|
|
|
2.2进度总结
描述:
原因:
改善建议:
3与相关项目协调总结
3.1与相关项目协调描述
< 总体描述:开发过程中与相关项目协调、合作的情况,是良好,还是有待改进。>
3.2协调情况详细分析
< 说明各个具体协调情景。>
协调情景 |
开发影响 |
详细描述 |
原因 |
改进建议 |
|
正向 |
|
|
|
|
负向 |
|
|
|
|
|
|
|
|
4.测试故障总结
4.1故障数分布描述
< 记录历次正式测试的故障数,并总结故障分布是否呈现良好的收敛特性。>
测试 |
A类故障数 |
B类故障数 |
C类故障数 |
D类故障数 |
总计 |
系统测试一 |
|
|
|
|
|
系统测试二 |
|
|
|
|
|
系统测试三 |
|
|
|
|
|
验证测试一 |
|
|
|
|
|
总结:
4.2开发故障详细分析
< 在此对历次正式测试的故障进行分类分析,重要在于提出解决方案,为后续开发提供参考。
其中“故障类别”是对一类故障的命名,如通用模块代码不完全通用。
“解决方案”与“防范手段”的区别在于,前者提出根除的方法,后者提供前者如果作不到的情形下,如何尽早发现、定位、修复故障的手段,如对通用模块的功能进行遍历自测。
“数目”是此类故障在故障历次测试中出现的总频度。
“举例”是此类故障在某个测试报告中的详细描述位置,便于查阅。>
故障类别 |
原因分析 |
解决方案 |
防范手段 |
数目 |
举例 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
5.开发过程总结
< 总结其他方法和经验,为今后的系统设计、开发工作提出建议。如开发人员流动较大,而且交接工作仓促,导致系统质量收到影响;或者开发人员不足,导致自测不够充分等等。>
PPR是为了总结项目在发展中暴露的不足之初,期望今后得到改善;当然PPR实践本身也需要经常回顾、总结和提高。而且,需要强调的是,PPR虽然是项目结束之前的最后一项工作,但是它的准备工作一直贯穿者这个项目周期,所有人员都要用心用脑工作和思考,才能不断挖掘和进步。
附PSP的个体项目计划总结表。
PSP项目计划总结表
人员: 日期:
程序号:
总结 |
计划 |
实际 |
累计 | |||||||
Minutes/LOC |
|
|
| |||||||
LOC/Hour |
|
|
| |||||||
Defects/KLOC |
|
|
| |||||||
过程效益 |
|
|
| |||||||
A/FR |
|
|
| |||||||
程序规模(LOC) |
|
|
| |||||||
新开发的与更改的 |
|
|
| |||||||
最大规模 |
|
|
| |||||||
最小规模 |
|
|
| |||||||
开发阶段时间/min |
计划 |
实际 |
累计 |
累计百分比 | ||||||
计划 |
|
|
|
| ||||||
设计 |
|
|
|
| ||||||
编码 |
|
|
|
| ||||||
代码复查 |
|
|
|
| ||||||
编译 |
|
|
|
| ||||||
测试 |
|
|
|
| ||||||
后置处理 |
|
|
|
| ||||||
总计 |
|
|
|
| ||||||
最大时间 |
|
|
|
| ||||||
最小时间 |
|
|
|
| ||||||
引入的缺陷 |
计划 |
实际 |
累计 |
累计百分比 |
Def/Hour | |||||
计划 |
|
|
|
|
| |||||
设计 |
|
|
|
|
| |||||
编码 |
|
|
|
|
| |||||
代码复查 |
|
|
|
|
| |||||
编译 |
|
|
|
|
| |||||
测试 |
|
|
|
|
| |||||
总计 |
|
|
|
|
| |||||
排除的缺陷 |
计划 |
实际 |
累计 |
累计百分比 |
Def/Hour | |||||
计划 |
|
|
|
|
| |||||
设计 |
|
|
|
|
| |||||
编码 |
|
|
|
|
| |||||
代码复查 |
|
|
|
|
| |||||
编译 |
|
|
|
|
| |||||
测试 |
|
|
|
|
| |||||
总计 |
|
|
|
|
| |||||
本文由作者向AMT提供
作者联系方式:ru.haiyan@mail.zte.com.cn