（1）质量价值简介

原文：Quality：It's All in the Values – Neil Harrison

最近，我家搬到一个新房子。有些事情是搬进新房特有的兴奋：检查新房间、感觉一下脚趾头之间的地毯、第一次使用新的器具…啊，对了，新的器具。不幸的是，我们的热情被消减了一下，因为我们发现冰箱不制冷。我们很快换了一个，但是制冰器不工作。制冰器修好了，但是门开不了。然后水管结冰了。在修理工过来几次之后，冰箱终于工作了。但是同时，炉灶和洗碗机 – 由同一家公司制造的 – 也需要修理。

在那家公司的网站上，他们自豪地宣称自己对质量的承诺。那家公司尤其对他们的无缺陷制造流程感到自豪。但是我没有体验到，我得到结论：这家公司不真正相信质量，质量没有其它方面重要，例如，可能没有短期的利益重要。

从冰箱到软件

这跟软件有什么关系吗？有点。在软件行业，我们也像这样一个大的器具公司，提供产品给顾客，标榜我们对质量的承诺，甚至打着过程成熟度的认证的旗号。但是真正起作用的是用户对产品的印象。如果用户需要忍受经常的死机、烦人的bug，或者软件很难用，那么我们的质量是个脆弱的东西。我们贴着ISO、CMM或6个西格玛的标记并不会让我们好过点。

那么怎样的组织才是个质量组织？软件行业中的丰田是怎样的呢？

疯狂的过程

我们都希望为我们的用户制造出高质量的产品。通常，我们尝试通过改进我们的流程来提高产品质量。表面上看起来，过程改进确实需要提倡，毕竟，我们怎样做一样事情对最终结果会有重大的影响。但是，在我们多年研究的很多项目中，我和我的同事Jim Coplien发现一个组织的流程不很好地反映它的总体效力。随着我们的进一步研究，我们发现几个原因。

其中一个原因是，很多流程没有真正产生它们预期的好处。流程可能需要过多的成本，从而削减了它们的好处，或者真正的结果与计划想要的不一样。因此，人们通常偷偷绕开流程以便完成他们的工作。

另外一个原因是，组织认可流程和流程应该达到的目的，但是对于组织来说存在更加重要的目标。你可能有质量流程，但是当进度受紧时，进度胜利了，质量流程被扔出了窗外。简而言之，我们的行动受到很多动机的驱动。这些动机形成我们的流程 – 那些我们真正执行的流程。这些动机比流程要稳定，因为这些动机来源于组织的价值。实际上，这些价值在组织的核心位置，并驱动组织的大部分集体行为。这对于质量而言更加正确。

发现价值

定义个人的价值是很容易的 – 它们是我们觉得对自己是最重要的原则。例如，我们的个人价值可能包括诚实、帮助别人、做好自己的工作。组织的价值类似于个人价值 – 它们是这个企业作为整体考虑的最重要的原则。

每个企业都有一个文化，而价值是文化背后的驱动力量。“文化”这个词会勾起我们一副婆罗洲丛林中的土著的图画。我们想象他们的药师、他们的典礼、他们的咒语，还有他们的民间传说。他们有自己的符号、信仰、神、惩罚制度。全世界的企业的文化也是类似的。在我们自己的组织中，我们有自己认为最强的人。我们有自己的典礼 – 我们把它叫做“流程”。我们的语言充斥者自己的术语和缩略词，这些都是我们的文化的标记。我们的文化创造出角色和沟通方式，并建立惩罚制度。

企业的价值很难被找出来。有些组织仅仅把它抓住而不愿意分享。而有些则没有意识到自己的价值是什么。但是有一些方法洞悉组织的价值。

其中一种方法是看组织给予哪些人奖励。你是否因为建造高质量的软件而得到奖励？如果有，你是幸运的，因为你的组织很可能认为质量是非常重要的。另一方面，你可能因为软件完成得快而得到奖励，忽略了它的质量。

有时候，价值是很奇怪的。我研究的一个企业，我看到人们处理紧急关键的问题会得到大的奖励。这创建了一种鼓励出现紧急危机的文化，这样，人们能成为英雄。当我问及这个问题时，架构主管说，“是的，我们像汽车跑在汽油上一样对待危机。”在这个组织，质量不是一个核心价值，实际上，它奖励一些会导致低质量的行为。

价值还体现在人们扮演的角色、这些角色之间的沟通类型。尤其能从质量和沟通的质量看出来。它们展示给我们看那些角色是重要的，由组织的文化暗中指定了。我们从研究的组织中发现模式。这些模式形成了动态组成的软件项目组的语言模式。这里有一些模式是跟质量和价值尤其相关的。这些模式是从Organizational Patterns of Agile Software Development这本书选出来的。它们包括：

1、雇用质量保证模式

2、引入客户质量模式

3、客户代表质量模式

4、架构师控制产品模式

5、架构和实现模式

6、代码拥有者模式

（2）雇用质量保证模式

如果不能依靠开发人员来测试他们认为会出现的错误，那么雇用专职的质量保证人员作为一个重要的职位。

几年前，一个朋友发狂地找到我。她在一个系统测试组，她感觉自己被孤立了。开发人员不跟系统测试人员说话，看起来像系统测试员没有足够的关于项目的信息。因为他们得不到他们需要的信息，影响他们的正常工作。简而言之，组织有系统测试员的角色，但是人们不认为这个角色是重要的。这说明了质量在这个组织的重要程度。

另一方面，我们可以看看在Borland Quattro Pro for windows（QPW）的角色和沟通。项目是在90年代早期做的，堪称高效和成功的传奇。在这个组织里，质量保证的角色是中心，并且与所有其他角色有很强的沟通。很明显，质量是QPW组织的核心价值。这是被市场所证实的，因为产品在行业中有很高的质量。值得注意的是，占领市场的速度和效率也是关键的价值；这个组织是我们见过的产品能按进度时间发布，开发人员有着最高的生产效率的组织。质量与生产效率不一定是相对的。

雇用质量保证模式包括这些关键点：

顾客参与是QA的关键因素。虽然开发人员可能感觉他们把所有东西都做对了，但是顾客一针见血指出的现实帮助开发人员意识到开发完美的软件是不可能的。

很多企业推迟质量到后期阶段才考虑，或者把QA等同于在开发过程的后期才进行的测试。然而，成功依赖于高质量的工作，尽早的反馈对发现根本性的质量问题是非常重要的。

因此：

让QA成为中心角色。一旦开发有东西可进行测试就与开发紧密地绑定在一起。测试计划的开发可以与编码并行，但是开发人员是宣告系统可以准备进入测试的人。QA组织应该在开发之外，换而言之，测试的计划和报告不应该向开发组织负责。

（3）引入客户质量模式

如果你想管理一个能适应客户输入的增量的过程，而且你想你的客户感觉你爱他们，那么把客户引入到你准备好的项目管理和QA中来。

也许最重要的质量的组成部分是顾客满意。实际上，很多人会说那是唯一有用的组成部分。因此，顾客角色在你的组织中的位置表明了你的组织中质量的重要程度。在你的组织和你的顾客之间存在什么信息流呢？我们发现在一个拥有很强的质量文化的组织中，存在良好沟通的客户角色或适当的代理角色。简而言之，开发人员可以学习到顾客的需要，顾客可以得到需要的支持。引入客户质量模式包括下面的方面：

开发组织通过鼓励关键开发角色，或者组织中的角色，与顾客的沟通，来确保和维持顾客满意是非常重要的。沟通不是某个“顾客满意”小组的责任；而是整个组织结构上下全体的需要。

因此：

紧密绑定顾客角色与开发人员和架构师角色的关系，而不仅仅是与QA或市场角色。简而言子，开发人员和架构师必须自由地、经常地与顾客交流。当条件允许时，在客户他们自己的环境中来让顾客参与，而不是把他们带到你的环境中来。

让这个交互过程发生需要两个方面：机会和文化。开发人员必须有机会（和方法）去与顾客沟通。为了建立信赖和自由的沟通渠道，他们应该亲自见到顾客。

但是如果组织文化在客户与开发人员之间建立起一道墙的话，这些访问会是肤浅的。特别是，如果系统需求必须经过长期的正式过程才能得到确认，那么开发人员会受到阻碍而不能及时地向顾客反馈他们的请求。因此，组织必须建立起让开发人员拥有一定的自由度向顾客响应的文化。但是我们不是说所有的需求控制都应该委托给开发人员来做。规则还是必须的。

（4）客户代表质量模式

如果你需要顾客的回答，但是没有顾客可以随时回答你的问题，那么在你的组织中建立一个客户代表角色。

因为他们会熟悉大部分的客户的问题，并且善于与顾客交流，客户支持人员通常在给予顾客帮助方面要比开发人员更有效。相应地，当顾客解析他们的需求时，他们的愿望需要跟别的顾客的请求、业务需要相协调。直接的、任意地访问开发人员 – 即使非常谨慎 – 也会导致混乱。

这是为什么极端的顾客参与模式 – 保持顾客在开发现场，通常不被推荐的一个原因。另外，这通常也是不实际的。但是如果顾客不能马上回答你的问题，你怎么能保持满足顾客的需要呢？你可以让某个人站在顾客那边。客户代表能接触各种真实顾客并能平衡和过滤他们的请求。他代表了一个单一的、连贯的顾客观点，因此开发人员不会同时被拖向很多不同的方向。

客户代表质量模式包括：

与顾客交互观点和澄清问题是非常重要的。然而，顾客可能不是随时都在身边。

对于开发人员来说，往往存在猜测顾客需求的诱惑。开发人员往往假设用户的行为与他们的设计一致。然而，往往总是有其他的应用软件的思考方式，某些可能会与开发人员的观点不吻合。

因此：

在项目组中创建一个代表顾客的角色，给予这个角色像顾客一样考虑的权利和义务。像对待真正的顾客一样对待这个客户代表。

如果组织有用户体验工程师，他们是最好的顾客代表。他们的重点是在用户交互，但是开发界面也存在很多难点。

（5）架构师控制产品模式

如果一个产品有很长的生命周期，那么赋予架构师展望未来的权利，并作为架构风格的长期保持者。

每个产品都有外部和内部质量。系统不仅仅要满足顾客的需要，还要满足系统的开发人员和维护人员目前和将来的需要。内部质量也一样主要由组织的价值和文化来决定的。例如，我们都知道项目的好的设计和文档会在崇拜进度面前牺牲。当然，我们总是对自己承诺我们后面会回来修正问题，但是往往很少这样做。

重视内部系统质量的组织有着长远的视角。他们想公司成功 – 不仅仅是当前季度的成功，而是将来很多年的成功。他们为了后面的回报重视目前的投入。这显然要通过一个卓越的架构角色来实现，因为架构设计和维护一个系统架构都需要很高的内部质量。架构角色与项目组的利益相关方有着很强的沟通并且是系统的技术架构的主要引导力量。

这是架构控制产品模式的组成部分：

虽然产品是由某些个体设计的，一个项目必须努力让产品的设计优雅并且内聚性强。有些项目可能通过集中控制的方式来达到，但是这种控制被大部分开发组认为是专制的。一个人不能做所有的事情，没有一个人可以很好地预见未来。

而且，需要某种程度的架构远见。有些领域技术是通过开发组的范围来分布的，系统的观点 – 尤其是创建普通的对话框和机构的设计原则 – 通常会从这些与个体思想或小组相关联的概念性的整体得到益处。

因此：

创建一个架构师角色作为一个为项目定义架构风格原则的体现，并且定义符合这种风格的广泛的领域专门技术。架构师角色应该建议并对开发人员角色产生影响并应该与他们紧密地沟通。架构师角色是开发组成员之间的主要桥梁。

架构师同样应该与顾客紧密联系。

（6）架构和实现模式

如果架构师呆在象牙塔里面，他与现实是脱节的，然而，某些人需要把高层次的观点与实际结合起来。因此，要确保架构师参与到每天的实现过程中来。

架构是抽象的活动，但是架构需要具体的实现。如果架构与系统的具体实现方面脱节的话，架构是不容易被实现的。而这些会使架构师的所有好的工作失效。因此，架构师的观点必须与实现融合。最简单、最好的方式是让架构师写代码。不应该很多 – 毕竟，架构师有很多其它的责任 – 但是必须足以让架构师明白自己的实现环境。

架构和实现模式包括：

软件项目必须是在不牺牲实用的深度和对实用性的注意的前提下放宽领导范围。

虽然开发人员在单独的设计和实现决定方面很在行，但是一个项目需要总体的、指导性的、策略性的、技术性的指引。指引通常来自架构师。然而，很多软件架构师限于思考和对抽象概念的说明，而抽象是忽略无知的正式形式之一。

因此：

除了建议、指导和与开发人员沟通外，架构师还应该参与到实现中来。

架构师应该有组织地参与到开发中来并编写代码。架构师可能与一个开发人员一起实现某个模块，通过结对编程的开发方式。

（7）代码拥有者模式

如果你需要在角色中内建对代码的责任以及领域知识，那么给大家以代码的整体质量的责任。

以所拥有的为骄傲会导致更高的质量。这在软件开发中也是成立的。在专注于质量的组织，人们对所负责的系统而自豪。实际上，大部分软件对于一个专家来说太大了，因此对代码的拥有分布于员工之间。作为代码的拥有者，你对代码非常了解，能帮助别人理解它，并最终对它的质量负责。当然，你不需要管理所有附加的代码或对代码的修改；事实上，这通常是大家不愿意的。但是你是确保这些代码不会引起重大系统问题的人。

代码责任制与其它领域的责任制是一样的。在我们搬家的时候，我的妻子紧紧地盯着搬运工打包她的精致的瓷器。为了缓解她的神经，搬运工对她承诺她的瓷器会完好无损地到达新家。为了证明他对安全打包的责任，他封好箱子后，清楚地在上面签上他的名字以保证不会损坏。就像你能想象到的，那些瓷器完好无损地到达了新家。

代码拥有模式可以解读为：

如果那是每个人的责任，那么结果是每个人都不会负责。

不是每个人在任何时候都知道所有的东西。即使是架构师也不能熟练地清楚项目的所有方方面面。

因此：

系统的每一个模块都由其中一位开发人员拥有。

注意拥有意味着对质量的责任以及对这个模块的整体架构设计，从而鼓励拥有者要获得对模块的深入理解。

（8）质量：在于意识的改变

这些是我们在组织中看到的一些能产生高质量软件的模式。还有其他的模式。

也许你已经在你的组织中看到这些模式的核心价值。希望你的组织仅仅拥戴质量而不仅仅是口头上赞成。文化的元素 – 组织中的角色、沟通、仪式、传统、语言 – 会给你一些线索。

大部分组织支持改进和改变，而改进是健康组织的组成部分。但是重大的、动摇核心价值的改变通常是不成功的。大部分核心文化的改变包括艰难的价值转移。这通常需要长期的或者遇到危机导致对价值的深深反省才能成功。如果你的组织是这样的，那么要做好失败的准备。

但是不要失望。有些企业使用有组织性的模式和有组织的学习来形成文化的转变。从小的开始；不要尝试一下子改变太多东西。经过一段时间，你会学到什么是有效的什么是无效的。

最后记住，当面对价值和文化时，质量只是很多价值驱动因素之一。所有这些价值之间的影响可以是丰富的和复杂的。如果你改变你自己的角色、沟通或仪式，改变会在其他的价值方面得到反映。毕竟，没有什么价值是孤立的。