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