他点亮了灯，照耀着我们前进——纪念大师温伯格
（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)，上个世纪九十年代初写成，十年后由清华大学出版社引进。前三卷成书较早，先形成体系，而第四卷成书较迟，是对前面三卷的总结，至今没有中文版。为什么说，前三卷形成体系？因为作为软件质量经理，需要具备三大核心能力：
系统思维——对复杂局面的理解、洞察能力；
一阶度量——优先对正在发生的事情进行观察，并能够理解所观察到的结果的意义；
协调行动——即使在情感最激烈的情况下，依旧能够顾全大局、采取正确行动的能力。
之前，我也围绕思维能力——“软件测试的看家本领” 连续写了四篇文章，第一篇就是看家本领之一：软件测试的系统性思维。没有良好的系统性思维，就根本做不好测试的分析与设计，而这恰恰是测试的核心工作。度量，也是很基本的，没有度量就不知道自己的问题所在，就没有改进，所以，我反对CMMI把“量化管理”放在第4个level，更反对将“缺陷预防”放在第5个level。咱们软件开发，本身就是数字化工作，度量是顺水推舟的事情，就可以先做起来，正如今天持续集成，大家希望快速建立过程管理的可视化（因为迭代越快，可视化越重要），采用SonarQube建立质量的dashboard。开发写出来的每个缺陷或测试遗漏的每个缺陷，研发人员就应该及时分析，找出根本原因，从而采取措施进行纠正，持续构建缺陷预防能力，构建的越早越好，因为不产生缺陷，才是最经济的。敏捷的第一句话就是“个体与协作胜于流程和工具”，强调团队协作，从团队角度去对测试、对质量负责，温伯格比敏捷宣言（2001年）早十年就强调这种价值观。
但现实中许多测试人员，不要说具有这三种核心能力，连对“质量”都缺乏正确、全面的认识，从来没有认真理解“产品质量模型”、“使用质量模型”等。我坚持这样的观点：无论是软件开发还是软件测试，都需要很好地理解“质量”、“明白自己在做什么”，第一次把事情做对，即使在敏捷开发时代。道理很简单，先问自己：为什么要开发软件产品？开发产品就是解决用户的业务问题，让用户满意，而“质量就等于用户的满意度”。作为测试人员，核心工作就是发现软件中存在的缺陷、揭示产品质量风险，那就更需要了“什么是质量”。从测试角度理解“软件测试”，永远是片面的，必须从质量的高度、整个软件工程的高度来看待和理解软件测试。
《质量.软件.管理》一开始就讨论质量模式、质量文化。温伯格提出了软件亚文化的六种模式，由低向高逐步提升的过程，即从“不知不觉、反复无常、例行公事”的不良文化如何提升到“驾驭自如、未雨绸缪、整体一致”。曾经做过调查，绝大部分公司处在不良文化之中，少数好的公司也只是“驾驭自如”，很难做到“未雨绸缪”。针对管理模式提出四种模式:
控制模式：常用的模式，测试就属于质量控制，强调质量反馈。真正要做好控制，就要系统地建立质量体系，驾驭研发质量。
决策模式：引入复杂度、规模、动力等影响因素，讨论如何保持控制手段和对客户需求及时响应。
错误模式（故障模式）：只要是人就要犯错误，关键是如何进行（引发故障的）根本原因分析，并预防问题的发生。
压力模式：软件开发都是在压力下进行，没有压力就没有良好的绩效，但压力也不能将团队压垮，甚至在这里，温伯格也谈到“无为之道”。
管理模式也代表着思维模式，正如James在“上下文驱动的自动化测试方法（二）”中谈到“测试的中心必须是测试人员的技能和思维方式”，而国内许多工程师关注所谓的“干货”，希望他人介绍的技术、工具或实践，拿来就用，在某种程度上体现了“拿来主义”在这些工程师头脑中作祟，而在“思考”上的懒惰，看问题比较浅显，停留在眼前收益，而没有长远的考量和深度的思考。技术、工具使用，相对容易，而且更多地靠自己去实践就可以，不断实践，熟能生巧。而靠自己改变自己的思想、思维方式则非常难，倒是需要其他人的指导和帮助，甚至要通过和他人激烈辩论，不辩不明，才能认识自己的不足，重新认知某个概念或主题。思想、思维方式更有价值，正如人们常说，态度决定一切。态度如何产生？态度实际就是来自于个人的思想和思维方式，是思想、思维方式决定了个人的态度。例如，科学家就是以批判性思维方式去思考，敢于质疑某些定理形成的条件、前提或推理，从而推翻它，产生新的突破。有一个读者评论道“看了温伯格的著作，才有种豁然开朗，茅塞顿开的感觉；要是我早几年，刚做一两个项目后就能读到这本书就好啦；也不至于受到这么多年的煎熬；真想狠狠骂一骂国内计算机出版界，这么好的东西怎么现在才引进；光引进那些什么宝典、语言、编程环境、工具啦！太短视啦。”
从这里联想到：国内为什么缺少软件工程大师？为什么国内鲜见产生开发思想、过程模型、设计模式？虽然有众多原因，但主要原因是价值观问题、缺乏良好的思维训练，更准确地说，在中小学和大学教育中缺乏良好的系统化思维和批判性思维的训练，在思想上懒惰，缺少独立思考的能力，甚至不会思考。其次，缺少良好的环境和企业文化，虽然一般企业也提倡创新，但往往任务压得重，工作压力太大，多数工程师低头干活、干得很累，经常加班，回家就想睡，没有时间去思考。最后一点，多数人并不是热爱某项工作而去干，而是出于养家糊口、功利（如挣钱多），甚至是偶然因素干上某项工作，所以对待工作也很功利，只是努力做好眼前的工作，而很少去做、去思考“工作之外”的工作。
温伯格(Jerry)在80高龄还经常参加软件研发的社区活动、会议
《质量.软件.管理》内容值得讨论的主题还很多，案例也丰富，提出了许多金科玉律（见本文后面附录），大家慢慢体会。如果无法体会，就去图书馆借一本《质量.软件.管理》（系统思维），仔细阅读。由于时间和篇幅限制，后续再讨论《完美软件：对软件测试的各种幻想》、《程序开发心理学》、《系统化思维导论》、《咨询的奥秘》等，更好地领悟其中的精髓，以此纪念Jerry。
Jerry个人主页：http://www.geraldmweinberg.com/Site/Home.html
附录：软件质量管理中的定律、规则和原理
Crosby对质量的定义: 所谓质量,就是“符合需求”。
所谓质量，就是指没有任何错误。
Crosby关于质量的经济学: 第一次就正确地完成工作，其成本总是最经济的。
对完美的要求(Quest): 不分青红皂白地盲目追求完美并不能称为成熟，而只是一种幼稚的表现
每一条关于质量的陈述，都是关于某个(某些)人的陈述。
质量的政治/情感因素：质量就是对某个(某些)人而言的价值
政治上的两难(Dilemma): 对某一个人而言更高的质量,也许对另一个人而言就意味着更低的质量
质量决策：在进行决策的时候，应该考虑到谁的意见?
Boulding的向后原理: 事物之所以按照现有的方式发展，正是因为那是其最佳的方式
超级程序员的形象: 管理本身就是一种开发工具，但是却没有人懂得这个道理。
通过模型来改变思维模式：思维的变革，将导致企业的变革；反之亦然
系统行为规则：行为是由状态和输入共同作用的结果。
蹩脚管理第一定律：虽然某种方法行不通，还要变本加厉地去采用它。
Brooks的模型 ( Rephrased)：在软件项目失败的时候，缺少进度日程表更会迫使人们去面对其失败的现实（如其采用模型不当的问题）;即使与其他所有原因相加的作用相比，这种强制力的作用也要更强。
软件项目为什么会出现偏差：更多的情况下是由于缺乏质量；虽然这只是众多有害因素的一部分，但是其影响力要远远超过所有其它因素的总和。
软件项目为什么会出现偏差：更主要的是因为管理人员依据不当的系统模型，采取了错误的行动；这方面因素的作用要超过所有其他因素的总和。
伸缩式谬误(Fallacy)：大型规模与小型规模之间除了规模大一些以外,没有什么本质差别。
可逆式谬误：你所做过的每一件事，都可以被撤销掉,然后从头再来。
因果律谬误：任何结果总有其原因……而且因与果之间是一一对应的。
人所做的决策：只要在系统中存在人为决策点，那么真正决定下一事件如何发生的，并不是当前的事件，而是某个人对该事件的反应。
计算的平方法则：除非能够进行某些简化，否则随着方程数目的增加，为求解一组方程所需要的计算量，将至少会按照方程数目的平方量级增加
自然的软件动力(Dynamic)：虽然人类的大脑或多或少存在些许的差别，然而都是有一定限制；而随着程序规模的不断增加，软件的复杂度也将至少以平方的速度增加。
规模/复杂度动力：纵然你拥有所有开发者之中最最聪明的头脑，面对人们的需求，你很快就会感叹自己的脑力实在不够用。
Log-Log定律：只要在一张使用 Log-Log尺标的平面上，任何一组数据点都会构成一条直线
有益的模型：无论其表面上看起来如何，其实每一个人都在努力使自己(对项目)有所帮助。
加法原则：如果你希望减少无效的行为，那么最好的办法就是增加更多有效的行为。
附加的模型：人们究竟会按照哪种方式发生行为，并不是决定于现实本身，而是他们头脑中关于现实的模型
程序开发第一原理：对付错误的最好办法，就是首先不要犯错误
不出现错误的谬误：尽管大量的错误必然使得软件一文不值, 但是反过来，纵然你能够一点错误都不犯也不会对软件的价值有什么影响。
控制者的进退维谷：在一个有条不紊地运行着的系统之中，真正的控制者并不(像人们通常所想像的那样)需要做很多事情。
控制者谬误：如果控制者无事可干，那么无疑就是失职。如果控制者忙得不亦乐乎，那么肯定就是称职的控制者。
差异检出动力：首先，解决相对更为容易的那些问题所需要的时间更少；其次，在测试的整个过程中，大多数相对更为容易的问题将首先被发现
故障检出曲线(坏消息)：无论你采用何种方法都不可能以一种线性的速度依次检出各项故障。
故障检出曲线(好消息)：通过将不同技术结合起来，我们有可能创造出某种更有效的方法
军队里的原则：没有不称职的程序员；只有对故障动力缺乏理解的主管。
自我否定式（Self-Invalidating）模型：在每次进行修正的时候，如果你事先认为可以轻轻松松地正确完成，那么实际上很有可能你所做的修正就将是错的。
连锁(Ripple)效应：为了对某一个错误进行修正，所需要同时进行改动的代码段的数目。
摸块动力：如果将系统划分成更多的模块，那么你所需要考虑的副作用就会更少。
泰坦尼克效应：如果你认为绝对不会发生灾难，那么难以想像的灾难往往就会出现。
压力/判断动力：压力→顺从→错误地估计→控制不足→更大的压力
反应渐弱定律：你施加的压力越大，你收到的效果越小。
Weinberg软件第零（Zeroth）定律：如果软件不要求一定能够运转，那么你就没有什么需求不能满足。
主管们难得一见：如果主管们整天忙忙碌碌就意味着管理不善
没有时间去做好：既然我们从来都没有时间把工作做好，为什么我们却总是有时间从头返工
回力镖（Boomerang）效应：如果企图通过捷径实现质量，往往会把事情弄得更加糟糕。