51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 3473|回复: 6
打印 上一主题 下一主题

[讨论] 评审的相关问题

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2008-12-2 15:51:15 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
关于评审我有很多问题,请大家帮忙解答:
1、对于小公司而言评审做到什么程度比较适中?(因为有成本控制)是需要将所有阶段的评审都执行呢?还是找到可能会对项目影响最大的阶段评审?
2、如何推进评审?让大家接受评审而不是去抵触?
3、评审的标准流程之类的内容的细致程度应该如何?是应该足够细致?还是应该先制定出一个粗略的标准,在执行的过程中慢慢改进?
4、评审通常有几种形式?除了正式评审以外的评审,希望大家能够帮助解释一下具体都针对那些内容的评审。
谢谢大家,希望大家帮忙解答!
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2008-12-2 20:47:44 | 只看该作者
成本与质量的权衡
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2008-12-3 18:10:23 | 只看该作者

试答

1、对于小公司而言评审做到什么程度比较适中?(因为有成本控制)是需要将所有阶段的评审都执行呢?还是找到可能会对项目影响最大的阶段评审?
就算是大公司也并不是所有的阶段、所有的产物都需要评审,可根据项目类型、可剪裁项来确定需要评审的被评审物,例如里程碑评审、计划评审。
另外不太同意你说的“对项目影响最大的阶段”这个概念,软件开发中的各个阶段都需要关注,你可以对其中的产出物进行评审以保证该阶段的进度和质量。

2、如何推进评审?让大家接受评审而不是去抵触?
评审的活动是为了让精通业务、技术上的人帮助改善自己的工作,提高软件质量,制定切实可行、有效的评审规范,然后执行评审,参照评审意见改进工作。让大家理解评审带来的好处,让领导层认同评审的意义,给大家一个过程应该是可以接受的!

3、评审的标准流程之类的内容的细致程度应该如何?是应该足够细致?还是应该先制定出一个粗略的标准,在执行的过程中慢慢改进?
我理解你说的是评审的规范,评审规范只要表明评审活动的流程、输入、输出、召开形式即可,在实际执行评审过程中的关键是通过评审活动审视被评审物的存在问题,改进工作项。
当然第一次制定的规范需要相关参与过评审工作的人进行沟通和交流,然后在实践中改善。

4、评审通常有几种形式?除了正式评审以外的评审,希望大家能够帮助解释一下具体都针对那些内容的评审。
同行评审对改进工作是最有效、最直接的,也是应用广泛的。
要注意评审工作的改进,每次评审后也要总结一下本次评审活动的经验和教育,不管改善。

以上都是个人意见,难免偏颇,欢迎讨论。

[ 本帖最后由 雅丹咔咔 于 2008-12-3 18:13 编辑 ]
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2008-12-4 12:05:40 | 只看该作者
我也试答一下
1、对于小公司而言评审做到什么程度比较适中?(因为有成本控制)是需要将所有阶段的评审都执行呢?还是找到可能会对项目影响最大的阶段评审?
其实评审对于我来说,感觉最重要的是有效性,如在我们公司,一个CMMI4的公司,在管理类文档的评审上,基本上流于形式,在开发的工作产品的评审上,虽然能够进行,但是总是在进度等因素的影响下大大的打折扣
所以对于小公司,从成本的角度考虑,个人认为对管理的文档可以采取走查的方式,大家只是要知道一些做事的方式和方法,对一些关键点的控制上,如设计的评审,代码的评审上要加强评审,一些小公司,可能技术牛人不多,所以在关键点上我们要保证过程质量,通过过程质量来保证产品的质量
2、如何推进评审?让大家接受评审而不是去抵触?
培训,教育,高层的支持,至于相应的开发人员的接收与否,关键在管理者身上
3、评审的标准流程之类的内容的细致程度应该如何?是应该足够细致?还是应该先制定出一个粗略的标准,在执行的过程中慢慢改进?
个人感觉没有粗细,只有合适与否,如果真的要建议,我想还是先制定的不粗不细,太粗没有可操作性,太细,就像CMMI搞得都是文档,反而有问题,所以争取适合公司的流程,让管理者认同,然后执行,然后再持续的过程改进
4、评审通常有几种形式?除了正式评审以外的评审,希望大家能够帮助解释一下具体都针对那些内容的评审。
根据不同的形式有好几类分类,现在说的比较多的是,项目内部的评审,专家评审,客户评审等
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2008-12-10 14:47:31 | 只看该作者
编码阶段中,同行之间的代码评审真的用有效吗?

我们准备在下阶段工作中这样做:
代码评审过程中,作者首先介绍一下自己的代码实现的功能和实现的方式,然后小组成员交叉检查,看是否存在问题。

大家帮忙看一下,这样做是否可行?缺少什么关键的步骤了吗?
回复 支持 反对

使用道具 举报

该用户从未签到

6#
 楼主| 发表于 2008-12-11 15:02:43 | 只看该作者
原帖由 懒月亮... 于 2008-12-10 14:47 发表
编码阶段中,同行之间的代码评审真的用有效吗?

我们准备在下阶段工作中这样做:
代码评审过程中,作者首先介绍一下自己的代码实现的功能和实现的方式,然后小组成员交叉检查,看是否存在问题。

大家帮忙看一 ...

代码评审也只能是关键代码评审、其余代码就只能抽查了,对于关键代码需要有经验的人参加,而对于抽查的代码可以组能成员互评,因为所有代码都检查实在是没有那么多时间,并且还可以引进一些代码检查工具阿,可以帮助检查的,对于规则检查时很有效的。
回复 支持 反对

使用道具 举报

该用户从未签到

7#
 楼主| 发表于 2008-12-11 15:10:32 | 只看该作者

感谢大家的解答

感谢大家的解答,现在对评审也有了很深的认识。
对于3#的朋友对我说的“对项目影响最大的阶段”,其实我是要说对项目质量影响最大的阶段,因为对于小公司而言很可能不会将所有的阶段评审都执行,或不能都采用正式评审,那这并不意味着不进行跟踪和管理,只是可能不进行评审,而采用其他的在效果和时间的比值更大的方法来进行。
在这里我说说自己知道的几种评审:技术评审和管理评审:正式评审、走查,同行评审、项目组内部互评。
回复 支持 反对

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-26 19:32 , Processed in 0.075023 second(s), 27 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表