qizg 发表于 2012-6-19 13:32:22

破窗效应-谁在打破第一扇窗户?

破窗效应-谁在打破第一扇窗户?
社会学家JamesQ.Wilson和GeorgeL.Kelling在《BrokenWindows》中指出:“一个房子如果窗户破了,没有人去修补,隔不久,其它的窗户也会莫名其妙地被人打破;一面墙,如果出现一些涂鸦没有被清洗掉,很快的,墙上就布满了乱七 八糟、不堪入目的东西;一个很干净的地方,人们不好意思丢垃圾,但是一旦地上有垃圾出现之后,人就会毫不犹疑地抛,丝毫不觉羞愧”
在开发和测试中,谁正在打破窗户?
糟糕的需求管理
需求是变化的,实际中,要做到准确和精确的需求定义,是不可能的。这是一句正确的话,但却被错误的使用。所以有对需求文档不重视的,不做维护的;有低质量的需求文档的;有把需求的问题不当问题的;有交付物与需求不一致的时候,改需求的;也有需求不明确的时候,却已经实现的。(需求优先还是系统优先,已经分不清了)。需求是一切开发和测试工作的依据。如果需求不明确,却实现了功能的,应当根据实现的功能定义这个需求,面对的问题可能是需求定义是错误的这一种情况,而不至于要面对一方面定义该需求不明确,另一方面又自行实现功能的两种局面。何况实现的功能有可能也是错的。徒然增加需求管理的复杂程度。面对需求的变化,做好需求与交付物的双向跟踪,一方面按照需求实现系统,保持一致,另一方面,通过实现的系统重新定义不明确的需求,维护一致性,而不要存在可能性。管理的过程越简单,越能有效跟踪。
没有的单元测试和集成测试
没有单元测试是目前的现状。有集成测试吗?集成测试报告看不出系统模块间是如何集成的,是自下而上还是自上而下?现实是把所有的打包放一起,然后测试下,形成所谓的集成测试。
流于形式的测试
例如集成测试目的不明确,测试时间短,测试不充分,流于形式,将问题和希望寄托在下一个环节。例如系统测试和验收测试阶段。
不可测性
可测试性是衡量模块的一项准则。既然是准则,自然高度就高,达到也自然有难度。但并不能因为有难度就可以不做。例如能效管理系统的数据源一直是个问题,数据量,数据精确度,数据有效性等,如果不符合要求,都会导致与数据相关项的不可测试性。当不可测项多了,测试人员就会放弃继续测试的意愿。此时,还会引发另外一个问题,对于其中存在可测试的部分也遭放弃。
重用性不强的模块
例如,在我们系统中的登录注册模块,实施的几个项目没有特别的需求变化。但是在每个项目中却都有不同的问题发生。这种不合理的情形会导致测试人员对模块的重用性持怀疑的态度,并对此没有信心。从而每个项目都要重新测试一遍,造成浪费。如果重用性高,在测试中就有理由,有信心省去该模块的测试,或抽查测试,既节约时间又不用面对质量风险。
不友好的人机交互
人机交互是个大问题,却引不起重视。界面不友好,个人色彩成分浓厚,简单问题复杂处理,不便捷的操作留给用户,界面呈现的功能与实际逻辑不匹配,需要用户来摸索,增加用户操作的难度,指望通过用户手册来规避问题。软件的人机交互,无论是行业准测,还是业界习惯,都发展的较成熟。如果将一个不便捷的操作留给用户,写到用户手册里,紧接着就会用同样的方式处理更多个。因为将此作为规避问题的合理方式。一个问题,如果当前就能解决,这是最节约,最保险的处理方式。人机交互要达到“所见即所得”的效果。
无用的理论之争
公司在导入CMMI,项目在采取敏捷方式。有人担心CMMI会威胁到敏捷的项目。例如CMMI强调文档,而敏捷却相反。但测试需要文档的时候,敏捷成了上方宝剑,并滥用至极。敏捷不强调文档的一个重要目的是节约,消除浪费。实际项目中做的如何呢?有的项目系统,测试环境不明,测试范围未划分,提交的测试系统未做整理,直接将还在调试的用来测试,因此里面很多调试文件;未实现的功能未做登记的。在测试前这些不都记录在案或者消除的吗?在测试过程中,大部分时间用在去了解系统的真实情况。这是敏捷的消除浪费还是增加浪费?当浪费在增加的时候,破窗的出现也是必然的。目前的情况,这样的问题还依然会长期存在吧。为弄清楚这个问题,不妨多做些引申。
针对变化,一般有2种处理方式,一种是“以不变应万变”,一种是“拥抱变化”。“以不变应万变”的前提是有一个成熟的组织结构和灵活的处理流程。CMMI就在干这个事情。在未达到这个能力前,我想明智的做法是“拥抱变化”。实际中项目的特点千差万别,因而有敏捷,XP, RUP,等等这些优秀的思想和模型来解决实际中的问题。说到解决问题,不得不提另外一个概念“最佳实践”。什么是“最佳实践”?你用方式1,我用方式2,哪个最佳?我以前就是这么理解的。后来发现不是这么回事。把事情做成的实践就可以称之为最佳实践。对于需求的变化,或其它问题,敏捷有没有非文档的实践来处理?如果有,这是它的最佳实践。如果没有,是否因为敏捷不强调文档就不采取该最佳实践,以此避免跟CMMI理念重合?没有任何说法最佳实践是有出身的。每个开发模型,思想都有互通的最佳实践。
将不是问题演变成问题
在测试前端,如果对客观问题有相应的处理和跟踪措施,在测试阶段即使没处理完,也会不当是问题。如果没有处理,在测试阶段,则将此作为问题,且是最严重的问题对待。尽管你有客观原因。在前端该处理而未处理的,有理由相信该问题已经失控,并对是否真会处理持怀疑态度。把前端环节问题流放到后端环节的,寄希望于后端环节的控制,是破窗的滋生环境。
不注重组织过程资产和知识库的积累
每个项目,生成的代码,文档,经验总结,等等需要注重平时的积累,形成组织过程资产。为将来组织所用。如果仅仅停留在个人经验的积累,没有项目积累,组织积累,没有知识库,这种效率是相当低的。换一个人,曾经所做的事情要重新来一遍。个人高效,不代表项目或组织高效。华为在导入IPD前,IBM对他做的调研的结论之一是:华为没有时间把事情一次做正确,却有时间反复做同一件事情。这种一针见血的结论放在今天能引起从业人员的警醒吗?未必如此。例如需求还没理解清楚,内部还没统一意见的情况下,就开始编码的,导致后期内部相互推诿,或反复修改代码,或修改代码难度加大,而改需求来满足已实现的代码。这种重复,无用的劳动,也是严重的破窗的表现。
软件开发和测试的方方面面如同一扇扇窗户,我们做的是打开窗户,关闭窗户,而尽量避免去打破窗户,尤其是第一扇窗户,打破了也要赶快修补,否则软件就会随着破窗效应,一扇扇的被打破。

愚人 发表于 2012-6-21 23:02:55

要好好理解一下

千里 发表于 2012-6-23 17:37:59

管理要从一开始就做好啊,规范也是。

wpk369 发表于 2012-6-28 11:05:23

需求是变化的,实际中,要做到准确和精确的需求定义,是不可能的

lihaoming89 发表于 2012-7-1 14:56:32

LZ精辟之言让小生受益匪浅:handshake

hellowang123 发表于 2012-7-17 15:58:24

ding
页: [1]
查看完整版本: 破窗效应-谁在打破第一扇窗户?