下载掌阅APP，畅读海量书库
立即打开
“质量”已经成为软件开发界的一句口号。但是，有些软件组织确实重视这个问题，有些则只是人云亦云；有些“质量措施”可以改变现状，而有些只是为了达到某种宣传效果。当大家都把软件质量放到第一位时，成熟度的问题就变得日益突出。这是因为，为了有效地保证软件质量，无论是个人成熟度还是组织成熟度，都是必须加以实施的。
当软件系统变得日益复杂和庞大时，就意味着软件开发管理者面临着新的挑战。软件组织可以通过不断实施规范化、久经考验的软件开发模式，来不断提高组织的“过程成熟度”级别。但让许多管理者感到困惑的是：是否应该按照开发角色的命名要求，让软件人员达到相应的个人成熟度呢？因为通常情况下，程序员、分析员和设计师基本上都是一类人，如果想要管好这样一群人，即使是最好的管理者，也必须费尽心机。如今软件开发组织所面对的最头痛的问题就是，对于这些宁可辞职也不愿协同工作的人，应该怎样实施管理呢？
尽管在软件开发这个领域中，“单干户”的数目众多，但绝大多数的软件还是通过团队开发得到的。某些团队的开发活动是分开进行的，而另外一些团队的开发活动是集中进行的。但是，不管怎样，只有极少数的软件是由个人独立开发完成的。
这是个显而易见的事实，并且没有引起普遍重视，因为这与大家长期以来形成的观念差别太大了。大家一直认为，在软件开发领域，占主导地位的都是那些充满神奇色彩的天才程序员，只要他们愿意，他们就能够单打独斗地进行软件开发，他们可以没日没夜地工作，然后，新的软件系统就诞生了。这些天才们充分地运用他们的想象和智力，开发出新的编程语言、新的开发工具、新的应用软件，这些极具独创性的软件让我们感到既幸福又痛苦。另外，让我们感到既幸福又痛苦的还有另外一群人。他们不属于那种才华特别出众的，可他们具有锲而不舍的精神，他们坚持采用他们自己的开发方式，不要协作，不要帮助，拒绝监控、方法论和讨论。
组织管理顾问们一般将这类人称为“牛仔”。牛仔实际上是倔强和桀骜不驯的代名词，这种人普遍存在于各个领域中。如今，在硅谷前沿有许多牛仔正在与汇编语言进行着搏斗。也有人将他们称为“人类美洲狮”（human cougar），因为他们的许多行为表现很像美洲狮——孤独而机警。他们是一些特立独行的人，要么按照他们自己的方式行事，要么就不干这件事。
如果对这种说法有什么疑问的话，那我可以把自己当做例子来解释。我自己就是一个特立独行的人，曾经有人就这么评价过我。事实上，是Paul Ward（一个从方法论学者转变为历史学家的人）在他的一本关于结构化分析的书（Ward 1992）中这样叫我的。他私下里向我保证，他绝对是褒义的。确实，在我的职业生涯中，我一直不是个循规蹈矩的人。现代软件工程中充斥着结构化设计的基本原则，通过CASE工具和集成开发环境可以得到数据流程图、结构图表等，这些都被视为正统的软件开发方法的标志，但以前并不是这种情况。难以置信的事实是，这些都曾经被当做是非正统的事物，甚至被当做是那些特立独行的人的胡思乱想。
我对这种标新立异的行为持支持态度，我的许多朋友都是特立独行的人。而且我相信，这种对新事物的强烈追求正是事物产生真正变革的源头，同时，我也意识到，这种行为也是造成许多愚蠢结果的源头。就算是爱因斯坦式的人物，你也不可能期望他的每一种想法最终都是可以接受的。有时，面对一个新的想法，你很难区分它是一个真的创新，还是一个幻想。但它必然是二者之一，无论怎样，都会丰富我们的生活——要么是真的有效，要么成为人们的笑柄。
当牛仔与坚持独立自主或个人主义并不是等同的概念。一个程序员是否使用某种特定的软件方法或者根本不按照任何软件开发方法进行程序设计，与他是否被视做牛仔并没有什么直接的联系。程序员之所以会被称为牛仔，是就他的思维体系和个人风格而言的。牛仔程序员具有以下特点：他们反对任何形式的标准、约束和规范，不喜欢受到他人的监控，也不喜欢和他人协同开发，追求创造性多过考虑软件的可用性和可靠性。
当然了，并不是每一个喜欢单独工作的程序员都叫牛仔。有些人从性格上来说比较内向，喜欢独来独往；有些人呢，称其为隐士可能更加合适；还有一些人不喜欢为他人工作，那样会让他们感到无法全身心地投入工作或受到压制，所以他们就自己开公司单干。我也经常一个人工作，常常一个人待在屋里，只有我的计算机陪着我，在这种情况下，我还真的干出了不少漂亮活儿呢。
为什么管理这些特立独行的人是一件重要的事情呢？为什么不能放任他们，随他们按照自己的意思工作，只把他们当做合同程序员或者独立的咨询人员呢？一方面，这种类型的人数目众多；另一方面，他们中的大部分都是非常出色的，如果能适当地加以约束，让他们可以协同工作，那将是一件极好的事情。牛仔程序员们可以对软件开发作出真正的贡献，好的管理者能够创造一种环境，以充分利用这种贡献，从而使组织和牛仔们实现双赢。
有的管理者鼓吹一种对牛仔们采取放任自流的管理方法，他们觉得如果把规范和标准强加到牛仔身上，那么对于这些才华横溢的程序员来说，是无法发挥他们的全部潜力的。
我认为管理者应该有更好的选择——至少我希望如此，如果采用这种无约束的管理方法，那么众多大型软件公司所开发的各种软件产品很有可能是低效的、不可靠的；如果用户使用这样开发出的大型软件产品，那他们就不得不忍受软件产品中的种种缺点，例如缓慢的系统，充斥整个系统的杂乱无章的各种句柄和钩子。
随着软件产品的规模和复杂性不断增长，对项目管理者来说，学会如何使用项目组中的这些牛仔程序员，就变得越来越重要了。就算是项目是按照团队合作的形式来实施的，好的项目管理者也可以为牛仔们找到一个恰当的位置。当然，这并不意味着让他们完全独立地进行工作，但是也没有必要让他们参与每次项目组会议或代码走查。
独立工作的人可以干得很好，但也有可能干得很差。他们能否把工作干好的关键取决于项目管理者对他们的使用方式。策略的一部分是将整个工作进行分解，并进行合理分配。把相对独立的工作分配给那些喜欢并且能够独立完成任务的人员，这些工作应该尽可能孤立，类似于一种黑盒形式，与其他工作之间只存在简单的接口和一些早已定义好的外部规范。对这些人来说，他们所承担的工作与系统的其他部分应该是一种松耦合的关系，不需要与他人进行协作或者频繁地沟通。
策略的另一部分就是进行细致的监督和审查，因为限制独立工作者和开发组中其他人员之间的相互依赖关系，并不意味着完全忽视这些人的存在。事实上，当软件系统的一部分是独立开发的时候，监控这些独立部分与其他部分之间的接口和相互关联就变得更加重要了。如果把工作交给了那些在家办公的人或者外面的合同工，管理者经常还能意识到监控的重要性；但是，他们往往会忽视那些坐在办公室里单独工作的人。
当团队内部按照一种公开的方式开展工作时，工作间的透明度增强了，这样有助于降低软件系统的缺陷并提高系统的质量（请参见第26章和第33章）。当团队中有些工作在某种程度上是独立开展时，就需要根据外部规范和实现质量等进行更为细致的审查，以此来保证工作的质量。单靠接收测试来保证软件质量的做法是不可取的，要真正保证质量，必须从代码级别上进行审查，使其符合清晰、可靠的一致性标准。
独立工作并不意味着可以不按照规范或者好的方法开展工作，只是说可以一个人单独工作而已，这只能被认为是很多人在一起工作而已。然而，从管理者的观点来看，如果团队中有独立工作的成员，那么使用系统化的开发方法就显得更加重要了。回归测试和代码走查在质量保证方面所能起的作用是有限的。既成事实之后的检查是不可能真正提高软件质量的，必须从软件开发的初期就开始注意这些问题。系统化和形式化的软件开发方法已经被证明是提高软件质量的有效手段。就算是那些最独立的牛仔程序员，如果他们也采用了某种系统化的开发方法，那么他们的工作成果也应该是可靠的。
为了让牛仔程序员们能够使用系统化的开发方法，管理者不得不就使用哪种方法的问题上与他们达成妥协，因为就算他们使用自己所喜欢的独特的开发方法，也要比不使用任何开发方法的效果好。
设计模式不但可以加快软件开发进度，提高软件开发质量，还有助于对系统开发进行描述，因为它可以部分地记录出开发者的思路，反映开发者是如何从问题出发直至找到解决方案的途径。对于那些可以作为子系统分配下去进行独立开发的工作，必须准备相应的设计文档——数据流程图、结构框图、结构流程图等。
其实，对于需要和牛仔程序员打交道的项目管理者来说，他们可以从下面的类比中得到启迪。牧场主们看管着牛群，注意着不要让它们跑得太远，阶段性地把它们召集起来，就这样，牧场主密切注视着牛仔和牛群。当然了，他们也会留神不要看得太紧，适当的时候放松一下，比如周末时让牛仔们自由活动一下。
Meilir Page-Jones描述了一个非常形象的过程，可以用来理解软件过程成熟度的演变。首先是无政府状态阶段，组织在进行软件开发时，不采用任何一种软件开发方法，甚至对那些明文规定也不理不睬，项目能否成功完全依赖于成员自身的能力；传说阶段，在这种组织中，以前项目的成功或者失败的经验口耳相传，慢慢地积累下来，形成了一定的规范；方法阶段，软件开发是基于某种系统的方法尽管还不是那么正规，但是已经比传说阶段要强得多了；度量阶段，组织基于测量数据来评估软件质量，并按照收集的测量数据来改进工作和开发过程；最后是工程阶段，软件开发变成了一种真正的工程规范，变成了一种可以持续改进的软件过程，所采用的方法并不是基于道听途说，而是通过分析和研究得到验证的理论，其中的设计决策和权衡是系统化的，并且产生自包含不断发展的知识体成果的模型和度量。
工程就是成熟的个体在成熟的组织中使用成熟的方法。无组织状态就是，你把一群牛仔关在一起，告诉他们要解决什么，然后就撒手不管了。
遗憾的是，当一群“特立独行的人”聚在一起时，他们往往会相互对立。当一群牛仔同时工作时，工作结果往往非常糟糕。如果不具备一些创造性的领导能力，一群牛仔程序员很有可能是极难管理的。
当牛仔与其他类型的人员一同工作时，他们会表现出一种破坏团队的倾向。有一些人可能会非常固执，拒绝参与团队的讨论会；另一些却会对自己感兴趣的话题大谈特谈，把时间白白浪费掉。通常情况下，他们对他人提出的建议都是十分苛刻的，往往会与团队中的其他人发生冲突。
在最坏的情况下，对抗会以这种方式结束：一方被推到墙角，承认自己是错误的。反过来，牛仔程序员可能会以一种挑剔的眼神看着剩下的成员，认为这群人在搞帮派主义，而编程水平低下，他们无法欣赏真正的天才程序员。
从团队建设和保证产品质量的目的出发，管理者必须知道如何阻止这种分裂现象的发生。直接对牛仔加以指责并不是一种好的领导风格；以领导的身份来压制牛仔是要冒很大风险的。牛仔以固执己见、极度自负、容易发怒而出名。如果管理者为了自己的脸面而直接与牛仔进行对抗，很有可能会使事情变得更糟。
对管理者来说，真正的挑战在于如何管理“特立独行的人”。有些管理者认为，应该将这些家伙赶出队伍，让他们自己去单干，但是这种方式并不总是有效的，而且不符合组织的利益。我的老板说过，管理者的职责就是尽一切努力消除团队中的障碍，让所有的人都能各尽其责，使他们挖掘出自身最大的潜力，我太幸运了。如果能按照这种观点来管理团队，那么那些“特立独行的人”就能够发挥他们的创造力，并为组织带来极大的益处。
有些组织能够容忍存在不同意见的成员，并从中受益，组织逐渐兴旺发达：而另外一些组织则不能容忍这些持不同意见的成员。能否做到这点，主要依赖于团队的组织方式（参见文献Constantine 1993c；Larson＆LaFasto 1989）。对于按照传统的自上而下的组织方式建立的团队，他们的工作分配形式也是自上而下的，所有的人员都是直接由上级进行领导，那么组织在处理这种“特立独行的人”和牛仔程序员问题时，会遇到很大的麻烦。这种基于传统组织策略的团队（参见第11章），一旦在工作中遇到意见对立的情况，工作就会受阻，无法顺利进行下去，而且，在基于这种组织管理风格的组织中，那些“特立独行的人”会被当做组织的叛逆者来对待。
另一方面，一种随心所欲的“突破”型团队组织方式（参见第12章）可以激发“特立独行的人”的积极性，因为这些人的独立精神和创造性正是这种组织所需要的。但在这里需要注意的是，如何才能从众多意见中找出真正具有独创性的意见。这种组织之所以能够干得更好，关键在于相互尊重，这样，每个人的能力都得到了认可。如果组织中的每个成员都能将他的同事视为具有良好职业素养的工作伙伴，那么在组织中就会形成良性竞争，而不会陷入相互之间的无谓混战。
那些能够在工作过程中形成技术性君子协定的团队（参见本书第一部分），也可以很好地处理与“特立独行的人”的关系。技术性君子协定就是团队成员思想的结晶，它充分考虑了每个人的意见，让每个人都觉得自己的意见得到了重视，但没必要让每个人赞同协定中的每个细节。
不应该把那些提出对立意见或批评指责的人视为对组织不忠诚的人，事实上，通常情况下，这种批评意见恰恰是一种最重要的信息，是最应该听取的。合理的批评和怀疑应该受到鼓励，而不是受到打击。团队解决问题能力的强弱，在很大程度上依赖于这种“负面反馈”，如果一个团队中拥有像“常驻的批评家”或者“爱唱反调的人”（devil's advocate）这类人员，或者能够辩证地对待反面意见和善意的批评，那么这个团队的表现一定会更出色（参见文献Constantine 1989；Priem＆Price 1991）。
管理者应该记住：当一个权威人士试图压制、控制反对派时，反对派也时刻在抵御着权威的控制。所以，不应该控制，而应该引导、合作。引导反对者并使团队获得利益的途径之一就是制度化。在其中一种方法里（参见文献Con-stantine 1989，1991a），批评者或者“爱唱反调的人”（devil's advocate）被视作是团队建设中的一个要素，可以使团队从批评建议中走向成功。在团队中，合理的批评建议是一种必要的激励机制，就像“牡蛎中的沙砾”一样，能够使所开发出的程序逐渐成为“珍珠”（参见文献Thomsett 1990）。可以把“特立独行的人”正式当做团队的一员，专门负责提出批评建议，他可以从不同的视角来发现问题、异常、局限性，同时确保团队能够认真考虑这些问题，并最终解决这些问题。
“特立独行的人”作为批评者，与作为被批评者相比，往往表现要出色得多。然而，当他们独立进行工作时，他们的工作必须受到检查和评审，虽然他们比较痛恨工作时被人打扰和他人对自己工作的不信任。如果需要对牛仔程序员进行批评时，最好采取非正式的私人行为，这样，他们更容易接收一些。对“特立独行的人”来说，分析和提出批评建议是一个比较吸引人的工作，而牛仔程序员则更喜欢创造性地解决那些他人无法解决的难题。
“特立独行的人”在工作中最有可能出现的问题就是自我欺骗。他们为了追求独创性，甚至可以牺牲软件的实用性。若让他们单独工作，则可以有效地限制这一点。
现在，我们了解到，多样性有助于团队解决问题和做出决策。几十年来，对团队动力学的研究表明，异质性总是能够战胜同质性。由男性和女性组成的团队在解决问题时，比由单一性别组成的团队表现得要好；团队中专家的种类越多，成员受培训的范围越广，团队的战斗力就越强。无论在性格、人际交往风格或者文化或者种族背景方面，多样性总是胜利者。
很明显，我们并不想摆脱所有的“闹独立的人”。我们希望在一个团队中拥有各种领导风格的人，并且希望拥有不同的成员，以对领导做出不同的反应——包括反对领导的人。在团队中，我们需要原动力、协调者、改革者，他们可以想出新的主意，我们也需要拥护者，以便推动工作的开展；同样，我们还需要批评者和怀疑者，他们可以随时泼冷水，让团队保持冷静，不要凭一时热情过于冲动。对领导的各种反对意见可以对领导起限制作用，不要让他们太放纵自己。
如果一个团队中没有反对者，没有任何的异议，只是简单化的统一，那么这对于团队的开拓进取没有任何好处。如果一个团队希望发挥最大的效能，争论是有效的，也是最基本的因素，通过争论来达到统一，会使结果更理想。
那么什么是软件圣贤呢？软件圣贤是这样的一个人，他能够把反对意见视为机会，并从挫折中看到希望；他是一个睿智的放牧老人，经历了风风雨雨，离开了孤单的大草原，回到了自己的家园；他是一个洗心革面的牛仔，不但懂得独立的重要性，还理解合作的重要性。
摘自《美国程序员》，1993年7月