1.2   软件与博弈

博弈（game）不只是给孩子玩的游戏，尽管孩子玩的游戏也是博弈。很多人都创造并使用博弈，包括小说家、数学家和企业战略专家。

1.2.1   博弈的类型

你们可以玩字谜游戏（做动作以猜测一个隐藏于动作之后的短语），可以玩井字游戏（tic-tac-toe）或跳棋、扑克牌或桥牌，可以玩捉迷藏或乒乓球，也可以玩一个由“有一次，我去旅行……”开始的故事接龙游戏。如果你有年纪一点的孩子，那么可以在客厅地板上玩摔跤游戏。

博弈分为很多种：零和（zero-sum）博弈、非零和（non-zero-sum）博弈、位置（non-zero-sum）博弈、竞争（competitive）博弈、合作（cooperative）博弈、有限（finite）博弈以及无限（infinite）博弈，图1-1只列举了其中的一部分。作为一种能帮助我们明确软件开发可能是哪一种博弈的方式，让我们来看一下这些选择。

零和博弈（zero-sum game）：双方对立，如果一方胜利，另一方就失败。跳棋、井字棋、桥牌和网球都是这种博弈的例子。软件开发显然不是一个零和博弈。

非零和博弈（non-zero-sum game）：有多个赢家或多个输家。在那个冬天的夜晚，你考虑要玩的很多游戏都是非零和博弈，包括扑克、parcheesi和捉迷藏。软件开发也是一种非零和博弈。

位置博弈（positional game）：可以通过查看板上记的分数随时了解博弈的整体状态。国际象棋和井字棋就是这种博弈。桥牌不是位置博弈，因为那些打出的牌不能显示出是哪个人把它们打出来的。

有些人试图将软件开发作为一个位置博弈来进行，这就要求有文档能反映出项目的历史和当前状态。他们的计划是：如果有人离开项目，就会有一个替代的人能够加入到团队中阅读文档，然后拾起别人丢下的工作。我们随后将证明这对于软件开发不是一个高效率的博弈策略。

（实际上，位置博弈比这里的简单描述所表达的东西要有趣得多。在John Conway的《On Numbers and Games》（1976）一书中，展示了那些两个人玩的位置博弈如何形成所有数字的超集，包括实数、虚数、有限数和超限数。他直接由两个人玩的位置博弈构建了一个数字的概念。）

这些都是竞争博弈（competitive game），博弈中有很清楚的输赢概念。

在合作博弈（cooperative game）中，人们要么进行直到一起获胜，要么继续博弈直到他们认为不值得进行为止。前者是追求目标（goal-seeking）的合作博弈，后者是不追求目标（non-goal-seeking）的合作博弈。讲故事、玩爵士乐和地毯摔跤都是不追求目标的合作博弈。在后一种博弈中，玩家并不追求以尽可能快地达到一个目标作为博弈的结束。只有当足够多的人玩累了并退出时，他们才会结束。

（表演动作的）猜谜游戏、攀岩和软件开发都是追求目标的合作博弈（再次参见图1-1）。

所有这些都是有限博弈（finite game），即总会结束的博弈。在无限博弈（infinite game）中，玩家的首要目的是保持博弈的继续进行。组织、公司和国家参与的是这种博弈。他们的核心目的是保持存在。

一个人的职业也是一种无限博弈。一个想要让职业继续的人会采取一些步骤，以使他的那种职业经验能够继续。

通常，一个人或者公司在一个特定项目中表现得出色，是为了在下一次博弈中取得最好的位置。就像一个叫做So long, sucker的牌类游戏一样，这种团队和联盟会不断地发生变化，但又不做任何告知。

1.2.2   软件与攀岩

在我所见过的所有可以和软件开发进行比较的对照者中，攀岩是最贴切的。有这样一个对照者，对于与我们的主题拉开一定距离和打开一个我们可以重新应用到软件开发上的一个词汇表来说，是很有用的。攀岩不是软件开发的隐喻，而是一个对照伙伴，是同类博弈中的另一个成员。

让我们来看一下与攀岩相关的词汇和短语是如何与软件开发相关的。

合作和追求目标（cooperative and goal-seeking）。攀岩团队在一起工作是为了达到顶峰。他们评估攀登时所根据的是：在一起攀岩的情况如何，以及自己得到了多少快乐，而成功的第一度量是他们是否达到了顶峰。达到终点是首要的目标，当他们达到顶峰时，博弈就结束了。

（如果你是一个攀岩者，那你可能会在此打断我。对于很多攀岩者来说，达到攀登终点的时刻是一个伤感的时刻，因为它意味着博弈的结束。一般来说，合作博弈都是这样。当达到终点时，博弈也就结束了，但是如果队员们这次收获了很多的快乐，他们也可能不想结束。类似地，有时软件开发人员也不想结束他们的设计，因为那样他们工作中的快乐也将结束了。）

承受负荷（load bearing）。攀岩者实际上必须用他们的手和脚来支撑自身的重量。这是二者比较时尤其有价值的一点：软件必须能运行，并且产生合理的响应。尽管多个解决方案都是可能的方案，但不是每个方案都可行。

团队（team）。攀岩通常是以团队的形式完成的。有单独的攀岩者，但是在正常的环境下，攀岩者会为了攀岩的目的而组成一个团队。

有天分的人（Individuals with talent）。有些人天生就比别人善于攀岩。有些人永远也不会攀登。

技能敏感（skill-sensitive ）。攀岩者必须精通某一方面。新手只能进行简单的攀登。经过训练，攀登者就能够向难度更高的攀登发起攻击。

训练（training）。攀岩者会持续训练某种需要使用的技术。

工具（tool）。重要的攀岩需要工具：粉笔、卡子、护具、绳索、挂钩等等。重要的是在正确的时刻拿到正确的工具。不用工具进行非常短距离的攀登也是可能的。然而，攀登的距离越长，工具的选择就越重要。

有限的资源（resource-limited ）。攀登通常需要在夜幕降临之前或天气变化之前完成。攀登者们制定的攀登计划要适合他们的时间预算和体能预算。

计划（plan）。无论是翻过巨石、进行单索攀登，还是进行多天的攀登，攀登者总会制定一个计划。攀登得越长，计划就必须有越多的可扩展性，即便是该团队知道计划会不充分，甚至是弄错了地方。

随机应变（improvised）。即使攀登是一次计划最精密的探险，未预见到的、不可预见到的、纯属偶然的障碍也是会到来；除非攀登很短或者人们之前已经攀登过若干次了。因此，攀登者必须准备好随时修改原来的计划，这就是随机应变。

乐趣（fun）。攀登者因为攀登有乐趣所以去攀登。攀登者在攀登时体验了流畅的感觉（Csikszentmihalyi 1991），这种完全的消遣是攀登有趣的原因之一。类似地，程序员通常也对他们的工作乐在其中，其中一部分快乐就是得到了设计或编程的流畅感。在攀岩中的流畅感既是身体上的又是精神上的，而编程中的流畅感只是精神上的。

挑战（challenging）。攀登者因为有挑战而攀登：他们真的能达到顶峰吗？程序员也经常渴望得到这种挑战。如果程序员没有觉得他们的任务具有挑战性，那就可能退出或开始使用他们认为有挑战性的设计元素来装饰系统（这与叙事诗集项目中曾提到过的某些诗人非常相像）。

危险（dangerous）。危险可能是不能从攀登借用到软件开发上的一个方面。如果你运气不好，你就可能死掉。攀岩者可以自豪地说：如果小心谨慎，攀登还没有开车那么危险。然而，我从来没有听到过程序员表示过需要拿编程的危险与开车的危险做比较。

人们已经将软件开发与很多其他一些事情做过比较，包括数学、科学、工程、戏剧、建造桥梁和法律。尽管通过研究其中任何一种比较，人们都能获得一些见识，但对于我们理解比较中所涉及的因素来说，只有与攀登的比较才是最有用的。

1.2.3   创造和沟通的博弈

我们已经看到软件开发是一个群体博弈，它是追求目标、有限及合作的博弈。团队由出资人、管理者、使用专家、领域专家、设计师、测试人员以及写作人员组成，他们在一起工作的目标就是生产出一个可工作并且有用的系统。在大多数情况下，团队成员的目标是尽可能快地生产出系统，但是他们可能更喜欢关注于：易于使用、成本、没有缺陷或避免负债。

这是一种有限博弈，因为当达到目标时博弈就结束了。有时，系统的交付标志着这一终结点；而有时，结束则比这来得晚一些。对于开发的投资通常会随着系统交付的时间而改变，新的投资会定义一场新的博弈。新一轮的博弈可能是为了改进系统、替换系统、构建完全不同的系统，也可能是为了解散这组人。

这是一种合作博弈，因为团队中的人需要通过互相帮助才能达到目标。对于他们作为一个团队的质量的度量是：在博弈中，他们合作和沟通的如何。使用这一度量是因为它在多大程度上影响了达到目标。

如果这是一种目标导向的合作博弈，那么博弈是由什么组成的？博弈中的步骤又是由什么组成的？

开发人所要面对的任务是：他们要处理一个他们并不完全理解的问题，一个活在情绪、希望和思想中的问题，一个会随着他们的进行而发生改变的问题。他们需要

·理解问题空间。

·想象一些在可行的技术空间内解决问题的机制。

·用一种可执行的语言来把这一思维构想表达出来，而这一语言缺少很多表达方面的特性，而这一点对于一个系统来说则是无法原谅的错误。

若要在这种情形下工作，他们需要：

使用一些道具和设备将他们的思想引出来，或产生一些可以帮助他们理解问题或构造解决方案的想法。

·为后加入的那些人留下一些标识物的踪迹，留下标识物用于监控和测试他们的进度和他们的理解程度，当他们回顾自己的那部分工作时，会再次使用这些标识物。

因此，软件开发是一个创造和沟通的合作博弈。除了人们的想法及与同事和计算机沟通这些想法之外，这一博弈中没有别的东西。

回顾一下这个领域的文献，我们发现有几个人以前写过这样的文章。Peter Naur在1985年的《Programming as Theory Building》一文中，Pelle Ehn在《Scandinavian Design: On Participation and Skill》（1992）一文和他那本已经绝版的巨著《Work-Oriented Design of Software Artifacts 》（1988）一书中都写到过。Naur和Ehn阐述得非常好，所以我把这两篇文章几乎全部放在了附录B中。Robert Glass和他的同事在《Software Tasks: Intellectual or Clerical?》（1992）中也写到了这个问题，Fred Brooks把它视作一个非常难的任务，因此他写了《No Silver Bullet》（1995）一文。

本章的剩余部分将为这一创造和沟通的合作博弈勾画出其潜在的结果。而本书的剩余部分则将仔细研究这些结果。

1.2.4   软件与工程化

把软件开发视作一个分步骤的博弈是有益处的，因为这样做给了我们一种方式，我们可以按照这种方式对项目做出重要的和有利的决策。相反，把软件开发说成工程化（engineering）或构建模型不能帮助我们做出这样的有利决策。

使用工程作为参考的问题在于：我们作为一个团体，不知道这意味着什么。没有对工程的共同理解，就很难让人们工作得“更工程化一些”。在我的经验中，人们大部分使用工程化一词来建立一种因“没有把某件事做充分，也不清楚某件事是什么”而内疚的感觉。

什么是“工程化”？字典中的定义很清楚，它是：“科学和数学的应用，通过这种应用将自然界中的物质属性和能量源变得对人类有用”（Merriam-Webster誷 Collegiate Dictionary ，第11版，2003）。

这一定义没有解释什么是进行工程化（doing engineering）。在我的经验中，“进行工程化”包括为所面临的相互冲突的需求建立一个折衷的解决方案。然而，另一个人写信给我说：“工程化的基本概念是以可重复的一致的方式来解决问题”。这混淆了进行工程化的行为和进行工程化的结果，这是一个常见的错误。

进行工程化工作的结果是工厂，在工厂运营的时候，会有专门的人仔细监控所生产的产品的质量和数量上的变化。

进行工程化工作的行为是一个未清楚定义的创造性过程，工业的工程师通过这个过程来创造一个制造工厂的设计。这一过程不在统计控制之下进行，也不对产出的质量和数量进行度量。像软件开发一样，它也是一个创造和沟通的博弈，不同背景的人聚集在一起搞出一个可用的设计来。

当人们说“让软件开发更像工程一些”时，他们通常是要说“让它更像经营工厂那样，进行统计方式的质量控制”。但是我们已经看到了，经营工厂并不是进行工程化的行动。

“进行工程化”的另一方面就是：在手册中查找以前的解决方案。

没有人期望设计桥梁的市政工程师能发明一个新的结构。只要指定了河流和预测出的交通流量，他们就会去取土壤样品，然后使用手册来查找一个最简单的结构，用来在检验过的土壤之上跨越给定的距离建立一座能够承受所要求的负载的桥。他们的工作以数百年来众多的已知方案为基础。

这一点勉强符合软件开发的当前状态。我们还处在这样一个阶段：每个团队的设计都应该比别的团队好，而技术在飞快地变化，所以没有现成的参考手册。随着时间的推移，将会出现更多的这种参考手册。然而在今天，系统中的差异仍然比共同点更多。

让我们回过头来把“工程化”视作“思考并做出折衷”。这是更合适的说法。我们愿意让我们的软件开发者思考并理解他们所选择的折中。然而，这种说法不能为管理项目提供指导。

1.2.5   软件与模型构建

在最近的10年中，很多人都在提倡模型构建，包括Ivar Jacobson，他宣称：“软件开发就是模型构建”。

把软件开发刻画为工程化，并不能为管理项目提供大量的指导，而把它刻画成模型构建，则直接会导致不适当的项目决策。

如果软件开发是模型构建，那么对于软件或开发过程的质量的度量就应该是模型的质量、它们相对现实世界的保真度以及它们的完全程度。然而，全世界几十个成功的项目团队告诉我：

“我们所要表达的东西的有趣部分没有记录在那些模型里。有趣的部分是我们一边在白板上画一边跟对方说的东西。

我们没有时间创建精美或完整的模型。我们往往根本没有时间创建模型。”

我发现，在那些人们在勤奋地创建模型的项目中，软件都没能交付。对于模型的关注阻碍了软件的开发。

构造模型不是项目的目的。只有当它能帮助赢得这次博弈的时候，构建模型才令人感兴趣。

博弈的目的是交付软件。任何其他活动都是次要的。模型就像任何一种沟通一样，只要它能使下一个人继续他的工作，这个模型就足够了。

应当对团队的工作产品进行度量的是它们在向目标组传达信息方面的充足性。模型不完全、画图时使用了错误的语法以及实际上模型不像真实世界，这些都不是问题，只要他们能够传达充分的信息给接收者就行。

正如Jim Sawyer在一封讨论用例的电子邮件（Cockburn 2001c）中曾经精彩地说过：

“……只要模板感觉上不是那么正式，以至于在通往设计空间的路上，你就会迷失在满是蛀洞的递归下降之中。如果开始发生这种情况了，我说那就干脆剥去这裸露的小家伙并开始讲故事和在餐巾上乱画”。

沟通的效果比沟通的形式更重要。

与有些不成功的团队相比，有些成功的项目团队构建的模型更多、更精美。很多人由此得出了建模越多越好的结论。

与有些不成功的团队相比，有些成功的团队构建的模型更少、更马虎。另外一些人则由此得出了建模越少越好的结论。

这两种结论都没有根据。建模是团队沟通的一部分。过多建模和过少建模都可以。有时在餐巾上画个草图就足够了，而有时则需要更详细一些。

理解应进行多少建模以及在什么时候建模，正是本书的主题。应把软件开发作为一个有首要目标和次要目标的合作博弈来思考，这样会帮助你深刻地理解如何细化要构建的模型或者否确实需要构建模型。