他点亮了灯,照耀着我们前进——纪念大师温伯格

(Are Your Lights On?: How to Figure Out What the Problem Really Is)

美国计算机名人堂代表人物、软件开发的人类学家和心理学家 温伯格(Gerald M. Weinberg)于几天前(8月7日)离开了我们🙏🙏 ,觉得有必要写些文章来纪念他。十几年前,我在写《软件质量保证与管理》,就认真学习了他的《质量.软件.管理》,之后也买了他的不少的书,如完美软件(对软件测试的各种幻想)、程序开发心理学、技术领导之路、咨询的奥妙…人走了,但留下来的这些著作(见个人主页)依旧照亮大家前进的道路。

在早期,人们碰到的问题多数是技术问题,温伯格的写作的题材侧重技术,但那时的影响比较小。随着时间流逝,程序员更多了、项目也更大了,虽然技术问题仍然存在,但是他认为可以找到大把的人解决这些问题。但是,对于更大更复杂的项目,人为失误出现地越来越频繁,问题也越来越严重,但是许多技术专家对于解决人的问题、管理的问题却显得既无训练、又无头绪,很少有人能够帮助大家解决这类问题,因此温伯格改变了他的关注点,开始关注软件开发中非技术的问题——人的问题,包括心理学、协作、领导力等问题,于是写下了《程序开发心理学》、《系统化思维导论》、《成为技术领导者》、《你的灯亮着吗?》、《咨询的奥秘》等著作,也正是这些著作在软件工程领域产生了很大的影响。毕竟技术是特地的问题,影响的范围小,人的问题和管理的问题更具有普遍性,解决这类问题,对成千上万的人都有启发和帮助。正如网友所说,他对软件业发展的贡献,超过一些计算机图灵奖的获得者。而作为软件测试人员,更应该好好读一读他写的《质量.软件.管理》(四卷)、《完美软件:对软件测试的各种幻想》、《程序开发心理学》、《系统化思维导论》、《探索需求:设计前的质量》这八本书。

先谈谈《质量.软件.管理》,这是一套书,共四卷,即:系统思维(Systems Thinking)、一阶测量(First-Order Measurement)、协调行动(Congruent Action)和预期变革(Anticipating Change),上个世纪九十年代初写成,十年后由清华大学出版社引进。前三卷成书较早,先形成体系,而第四卷成书较迟,是对前面三卷的总结,至今没有中文版。为什么说,前三卷形成体系?因为作为软件质量经理,需要具备三大核心能力:

  1. 系统思维——对复杂局面的理解、洞察能力;
  2. 一阶度量——优先对正在发生的事情进行观察,并能够理解所观察到的结果的意义;
  3. 协调行动——即使在情感最激烈的情况下,依旧能够顾全大局、采取正确行动的能力。

之前,我也围绕思维能力——“软件测试的看家本领” 连续写了四篇文章,第一篇就是看家本领之一:软件测试的系统性思维。没有良好的系统性思维,就根本做不好测试的分析与设计,而这恰恰是测试的核心工作。度量,也是很基本的,没有度量就不知道自己的问题所在,就没有改进,所以,我反对CMMI把“量化管理”放在第4个level,更反对将“缺陷预防”放在第5个level咱们软件开发,本身就是数字化工作,度量是顺水推舟的事情,就可以先做起来,正如今天持续集成,大家希望快速建立过程管理的可视化(因为迭代越快,可视化越重要),采用SonarQube建立质量的dashboard。开发写出来的每个缺陷或测试遗漏的每个缺陷,研发人员就应该及时分析,找出根本原因,从而采取措施进行纠正,持续构建缺陷预防能力构建的越早越好,因为不产生缺陷,才是最经济的。敏捷的第一句话就是“个体与协作胜于流程和工具”,强调团队协作,从团队角度去对测试、对质量负责,温伯格比敏捷宣言(2001年)早十年就强调这种价值观。

但现实中许多测试人员,不要说具有这三种核心能力,连对“质量”都缺乏正确、全面的认识,从来没有认真理解“产品质量模型”、“使用质量模型”等。我坚持这样的观点:无论是软件开发还是软件测试,都需要很好地理解“质量”、“明白自己在做什么”,第一次把事情做对,即使在敏捷开发时代。道理很简单,先问自己:为什么要开发软件产品?开发产品就是解决用户的业务问题,让用户满意,而“质量就等于用户的满意度”。作为测试人员,核心工作就是发现软件中存在的缺陷、揭示产品质量风险,那就更需要了“什么是质量”。从测试角度理解“软件测试”,永远是片面的,必须从质量的高度、整个软件工程的高度来看待和理解软件测试。

《质量.软件.管理》一开始就讨论质量模式、质量文化。温伯格提出了软件亚文化的六种模式,由低向高逐步提升的过程,即从“不知不觉、反复无常、例行公事”的不良文化如何提升到“驾驭自如、未雨绸缪、整体一致”。曾经做过调查,绝大部分公司处在不良文化之中,少数好的公司也只是“驾驭自如”,很难做到“未雨绸缪”。针对管理模式提出四种模式:

  1. 控制模式:常用的模式,测试就属于质量控制,强调质量反馈。真正要做好控制,就要系统地建立质量体系,驾驭研发质量。
  2. 决策模式:引入复杂度、规模、动力等影响因素,讨论如何保持控制手段和对客户需求及时响应。
  3. 错误模式(故障模式):只要是人就要犯错误,关键是如何进行(引发故障的)根本原因分析,并预防问题的发生。
  4. 压力模式:软件开发都是在压力下进行,没有压力就没有良好的绩效,但压力也不能将团队压垮,甚至在这里,温伯格也谈到“无为之道”。

管理模式也代表着思维模式,正如James在“上下文驱动的自动化测试方法(二)”中谈到“测试的中心必须是测试人员的技能和思维方式”,而国内许多工程师关注所谓的“干货”,希望他人介绍的技术、工具或实践,拿来就用,在某种程度上体现了“拿来主义”在这些工程师头脑中作祟,而在“思考”上的懒惰,看问题比较浅显,停留在眼前收益,而没有长远的考量和深度的思考。技术、工具使用,相对容易,而且更多地靠自己去实践就可以,不断实践,熟能生巧。而靠自己改变自己的思想、思维方式则非常难,倒是需要其他人的指导和帮助,甚至要通过和他人激烈辩论不辩不明,才能认识自己的不足,重新认知某个概念或主题。思想、思维方式更有价值,正如人们常说,态度决定一切。态度如何产生?态度实际就是来自于个人的思想和思维方式,是思想、思维方式决定了个人的态度。例如,科学家就是以批判性思维方式去思考,敢于质疑某些定理形成的条件、前提或推理,从而推翻它,产生新的突破。有一个读者评论道“看了温伯格的著作,才有种豁然开朗,茅塞顿开的感觉;要是我早几年,刚做一两个项目后就能读到这本书就好啦;也不至于受到这么多年的煎熬;真想狠狠骂一骂国内计算机出版界,这么好的东西怎么现在才引进;光引进那些什么宝典、语言、编程环境、工具啦!太短视啦。

从这里联想到:国内为什么缺少软件工程大师?为什么国内鲜见产生开发思想、过程模型、设计模式?虽然有众多原因,但主要原因是价值观问题、缺乏良好的思维训练,更准确地说,在中小学和大学教育中缺乏良好的系统化思维和批判性思维的训练,在思想上懒惰,缺少独立思考的能力,甚至不会思考。其次,缺少良好的环境和企业文化,虽然一般企业也提倡创新,但往往任务压得重,工作压力太大,多数工程师低头干活、干得很累,经常加班,回家就想睡,没有时间去思考。最后一点,多数人并不是热爱某项工作而去干,而是出于养家糊口、功利(如挣钱多),甚至是偶然因素干上某项工作,所以对待工作也很功利,只是努力做好眼前的工作,而很少去做、去思考“工作之外”的工作。

温伯格(Jerry)在80高龄还经常参加软件研发的社区活动、会议

《质量.软件.管理》内容值得讨论的主题还很多,案例也丰富,提出了许多金科玉律(见本文后面附录),大家慢慢体会。如果无法体会,就去图书馆借一本《质量.软件.管理》(系统思维),仔细阅读。由于时间和篇幅限制,后续再讨论《完美软件:对软件测试的各种幻想》、《程序开发心理学》、《系统化思维导论》、《咨询的奥秘》等,更好地领悟其中的精髓,以此纪念Jerry。

Jerry个人主页:http://www.geraldmweinberg.com/Site/Home.html 

附录:软件质量管理中的定律、规则和原理

  1. Crosby对质量的定义: 所谓质量,就是“符合需求”。
  2. 所谓质量,就是指没有任何错误。
  3. Crosby关于质量的经济学: 第一次就正确地完成工作,其成本总是最经济的。
  4. 对完美的要求(Quest): 不分青红皂白地盲目追求完美并不能称为成熟,而只是一种幼稚的表现
  5. 每一条关于质量的陈述,都是关于某个(某些)人的陈述。
  6. 质量的政治/情感因素:质量就是对某个(某些)人而言的价值
  7. 政治上的两难(Dilemma): 对某一个人而言更高的质量,也许对另一个人而言就意味着更低的质量
  8. 质量决策:在进行决策的时候,应该考虑到谁的意见?
  9. Boulding的向后原理: 事物之所以按照现有的方式发展,正是因为那是其最佳的方式
  10. 超级程序员的形象: 管理本身就是一种开发工具,但是却没有人懂得这个道理。
  11. 通过模型来改变思维模式:思维的变革,将导致企业的变革;反之亦然
  12. 系统行为规则:行为是由状态和输入共同作用的结果。
  13. 蹩脚管理第一定律:虽然某种方法行不通,还要变本加厉地去采用它。
  14. Brooks的模型 ( Rephrased):在软件项目失败的时候,缺少进度日程表更会迫使人们去面对其失败的现实(如其采用模型不当的问题);即使与其他所有原因相加的作用相比,这种强制力的作用也要更强。
  15. 软件项目为什么会出现偏差:更多的情况下是由于缺乏质量;虽然这只是众多有害因素的一部分,但是其影响力要远远超过所有其它因素的总和。
  16. 软件项目为什么会出现偏差:更主要的是因为管理人员依据不当的系统模型,采取了错误的行动;这方面因素的作用要超过所有其他因素的总和。
  17. 伸缩式谬误(Fallacy):大型规模与小型规模之间除了规模大一些以外,没有什么本质差别。
  18. 可逆式谬误:你所做过的每一件事,都可以被撤销掉,然后从头再来。
  19. 因果律谬误:任何结果总有其原因……而且因与果之间是一一对应的。
  20. 人所做的决策:只要在系统中存在人为决策点,那么真正决定下一事件如何发生的,并不是当前的事件,而是某个人对该事件的反应。
  21. 计算的平方法则:除非能够进行某些简化,否则随着方程数目的增加,为求解一组方程所需要的计算量,将至少会按照方程数目的平方量级增加
  22. 自然的软件动力(Dynamic):虽然人类的大脑或多或少存在些许的差别,然而都是有一定限制;而随着程序规模的不断增加,软件的复杂度也将至少以平方的速度增加。
  23. 规模/复杂度动力:纵然你拥有所有开发者之中最最聪明的头脑,面对人们的需求,你很快就会感叹自己的脑力实在不够用。
  24. Log-Log定律:只要在一张使用 Log-Log尺标的平面上,任何一组数据点都会构成一条直线
  25. 有益的模型:无论其表面上看起来如何,其实每一个人都在努力使自己(对项目)有所帮助。
  26. 加法原则:如果你希望减少无效的行为,那么最好的办法就是增加更多有效的行为。
  27. 附加的模型:人们究竟会按照哪种方式发生行为,并不是决定于现实本身,而是他们头脑中关于现实的模型
  28. 程序开发第一原理:对付错误的最好办法,就是首先不要犯错误
  29. 不出现错误的谬误:尽管大量的错误必然使得软件一文不值, 但是反过来,纵然你能够一点错误都不犯也不会对软件的价值有什么影响。
  30. 控制者的进退维谷:在一个有条不紊地运行着的系统之中,真正的控制者并不(像人们通常所想像的那样)需要做很多事情。
  31. 控制者谬误:如果控制者无事可干,那么无疑就是失职。如果控制者忙得不亦乐乎,那么肯定就是称职的控制者。
  32. 差异检出动力:首先,解决相对更为容易的那些问题所需要的时间更少;其次,在测试的整个过程中,大多数相对更为容易的问题将首先被发现
  33. 故障检出曲线(坏消息):无论你采用何种方法都不可能以一种线性的速度依次检出各项故障。
  34. 故障检出曲线(好消息):通过将不同技术结合起来,我们有可能创造出某种更有效的方法
  35. 军队里的原则:没有不称职的程序员;只有对故障动力缺乏理解的主管。
  36. 自我否定式(Self-Invalidating)模型:在每次进行修正的时候,如果你事先认为可以轻轻松松地正确完成,那么实际上很有可能你所做的修正就将是错的。
  37. 连锁(Ripple)效应:为了对某一个错误进行修正,所需要同时进行改动的代码段的数目。
  38. 摸块动力:如果将系统划分成更多的模块,那么你所需要考虑的副作用就会更少。
  39. 泰坦尼克效应:如果你认为绝对不会发生灾难,那么难以想像的灾难往往就会出现。
  40. 压力/判断动力:压力→顺从→错误地估计→控制不足→更大的压力
  41. 反应渐弱定律:你施加的压力越大,你收到的效果越小。
  42. Weinberg软件第零(Zeroth)定律:如果软件不要求一定能够运转,那么你就没有什么需求不能满足。
  43. 主管们难得一见:如果主管们整天忙忙碌碌就意味着管理不善
  44. 没有时间去做好:既然我们从来都没有时间把工作做好,为什么我们却总是有时间从头返工
  45. 回力镖(Boomerang)效应:如果企图通过捷径实现质量,往往会把事情弄得更加糟糕。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

联系我
  • 上海市嘉定区曹安公路4800号同济大学软件学院
  • kerryzhu@vip.163.com