不要在缺陷上招致恼羞成怒
上一篇 /
下一篇 2012-08-16 08:55:29
/ 个人分类:测试经验
51Testing软件测试网+B&sv5]q6s 当你在开评审会(例如产品概念评估、需求评审、设计评审、代码评审、测试评审、产品发布评审)时,通常会检查出评审项目的一些缺陷。评审项目的作者对于这些暴露出的缺陷当然会感到不自在。51Testing软件测试网4bRj@XD&m
M Tp4YK0 出于通常的礼貌,一旦在特定领域发现了三四个问题,就不要再过高、过深地批评了。如果你需要指出再多的条目,可以将其写下来,让被困扰的人随后能仔细看到这些要点。否则这些事情会招致对方恼羞成怒。由于被评审人成了众矢之的,在效率上会极大地影响评审的后续进展。51Testing软件测试网9C#Sn$Qb&A'N!XCKh
51Testing软件测试网t1YK"tx9xrGf 对于评审,有下列一些有效的办法:51Testing软件测试网*A,O)U+wUs
51Testing软件测试网
X
Zsn7rd/Vr N9e2B 确保对评审项目的关注,而评价不是针对生产或创造评审项目的人或单位。换句话说,评审应针对事物、方法,而不是针对人。
5R7OiB"y7S@!LV%vL.{.m03I4m@0CKq6Fn3E0 避免用“你”、“你的”这类个人化的评价。
E6db+q6S_fj$le~051Testing软件测试网2_K'dI4R 设法表达你要求修改的原因是想达成什么目标:确定修改与市场策略有关,基于一般的架构原则,抑或是公司或部门的目标?
X}&iSWq"B/L6T07[_3uP2N-l'^0 评审应关注改善评审项目的方法,不仅仅因为没有遵循某个编码指导原则,而是修改后为什么有用。评审项目的人不仅需要知道怎样把事情做得更好,还要知道为什么这种改进是有用的。51Testing软件测试网#qd$ki;uJ(C