项目管理者联盟 | 中国工程管理网 | 中国研发管理网 | 会员中心 | 资料库 | 论坛 | 博客 |
|
|
|
标题:需求验证的5大要点
楼主
|
|
嗨呦 PMB:4928 省份:北京 行业:综合应用 注册:2008/2/22 |
要做好需求验证,必须在思想、方法、语言、人员、内容5个要点上做好相应的工作,否则就会产生很多负面的影响。 1.思想 前面已经说过,由于Review被翻译成“评审”,导致很多人将其与中国人常说的评审相混淆,其实它们之间是有区别的:中国人常说的评审是评价,而Review应该是复查,是发现问题。这一点,必须成为所有组织、参加需求评审会的人员都应该建立的统一认识。 隐喻: 当测试团队严肃、认真地对你说:“经过我们三天时间的测试,发现你提交的程序一个Bug也没有!”请问你会作何理解呢? A、我的程序很牛! 我想很多人会选择B吧!因为“人非圣贤,孰能无过!”应该是测试手段还存在问题,导致潜在的问题没有被暴露。 可是,“我的需求评审通过了!”之类的话题总是被许多需求人员以很开心、愉快的方式说出来,我怎么听怎么觉得像听到“我的程序真牛!”。 就像我们不是想花大量的测试成本来验证自己的程序无错一样,采用成本昂贵的评审技术也不是为了验证需求文档是无错的,而是帮助我们尽早地发现问题、找到错误,避免因问题被延误到后期解决而付出惨痛的代价。 SERU诫语8-1:需求验证的目标是尽可能暴露问题,而不是证明无错。 2.方法 统一了思想之后,接下来的重点就是“方法得当”。 SERU诫语8-2:在企业中推行即时评审、同级桌查等正式化程度不高的评审手段,是创建企业评审文化的有效手段。 3.语言 SERU诫语8-3:在评审会中,不要用“评价者”的口气谈论你的观点。 4.人员 要开好评审会,选择合适的参与人员是很重要的;要点在于合适,而不是越多越好。具体来说,包括三个方面的要点: 同级:别忘了,在CMM/CMMI中提到的是Peer Review,Peer就是同级,千万不要一开评审会就请高阶领导。 该来的人要请:也就是评审的内容所涉及的第一责任人,要想办法请他们参加。 不该来的人不要请:也就是评审不是越多人参加越好的,通常应该保持比较小的范围,要直接相关的人员参与;一方面可以保证参与者对评审内容熟悉,另一方面也可以保证参与者关心评审过程。 5.内容 建议大家控制在9条之内,理由就是心理学中的“7±2” 原则,也就是人们容易记住的信息条目在5~9条之间。因此大家也可以根据实际的情况做一些变通。 除了要对缺陷检查表的规模进行压缩之外,还应该对评审的需求规格说明书进行压缩。根据笔者的经验,一个较熟悉的团队,要对需求进行相对有效的评审,应该控制在每小时30~40页之间。 解决该问题的关键在于必须对需求规格说明书进行拆分,根据读者的层次、所关心问题域的不同进行拆分,具体的方法我们在第4~6章中已经做了很多说明。 SERU诫语8-5:评审时要确保评审内容、缺陷检查表的规模适合,内容应该按每小时30~40页的速度来准备,缺陷检查表尽量在9条之内。 |
回复 | 引用 发表时间:2008/11/18 10:33:06 |
daijiangbao PMB:82 省份:广东省 行业:IT软件 注册:2003/4/17 |
标题:Re:需求验证的5大要点
1 楼
|
回复 | 引用 回复时间:2008/11/18 16:47:22 |
! 您尚未登录,不能回复主题。 现在 登录 注册 |
|