用游戏的心情工作并不是罪过 法则26建把工作当作游戏吧
191 这个游戏能给你什么好处？多玩玩它，练习它，感受 它的趣味，并且喜欢它。如此一来，软件创造本身的趣味 会使僵硬、骄横和严肃都消失，这样最好。在布局时期，每件事情都按步就班进行并不是成功的 保证。本篇的目的是告诉你如何在发挥团队最大潜能之前， 准备好你的团队。本篇并不是成功的公式，而是伟大的先 决条件。如果每件事都能在布局时期就照本书的法则进行， 那么以后仍然会如此进行，协助你的团队成长起来。
Part 第二篇 中程时期
Two
中程时期
195 本书为了帮助读者建立清楚的观念，将软件开发过程 划分成四个阶段，然而在实际运作上真的很难这样 做，各个阶段彼此都有重复的部分。在本篇中，我不设章节段落，因为这一部分的内容用各项法则来说明比较清楚。 因此请不要以为我在每个阶段所用的法则仅适用于该阶 段。事实上，我所提出的法则都是观念，适用范围是整个 的软件开发过程，好的开发团队应该随时随地注意每一个 法则是否被实践。而在起始阶段所提的各项法则，如果你 有做到的话，你会发现在孕育阶段更容易实践它们，因为 你已经练习过这些方法。在起始阶段的主要目的是让团队凝聚并建立对团体与 产品的目标，而蕴育阶段则是充满对目标的期望、不确定 和挣扎，所有的事情都是一片混沌，并且充满对可能失败 的恐惧。这时候，毅力是最重要的。暂且不管你的团队是 多成熟，暂且不管你经历过多少次这种场面，或是产品出 炉时会有多伟大，孕育阶段总是可怕而乱糟糟的，你随时 都可能遭遇意外打击或是想象不到的失败，但绝对要坚持 下去。你很可能会有那种心情：但愿有条路让我逃离这一切， 每个项目都会有这种时候。每件事情都无法确定，于是组
196
员的心情开始恶劣，冷嘲热讽、消极抵抗都来了，几个月 下来不见天日的辛勤工作，使得组员好似得了坏血病。这 场灾难似乎永无休止，可怕啊！ 深呼吸一下，进入孕育阶段吧！
中程时期 下载
法则 27
Be like the doctors 用医生的方法
198
当病人已经药石罔效时，医生通常会对病情有所保留， 避免病人太过悲观或恐惧，并且尽量鼓励病人保持希望， 最好能让病人有个期望完成的目标。软件开发在这方面也 很像医学，它不是完全能用科学来解决一切。只是很不幸， 到目前为止，一般人还不了解软件开发是一门艺术─是 必须具有技术专长的艺术。现在，你得学着用医生的方法。医生绝对不会斩钉截 铁地断言什么医疗行为一定会有什么样的结果，反而是以 一种自在且充满信心的口吻说：“试试看吧，一切都还没 有确定呢。”反观软件项目经理人，常常在还不确定是否 可行时，就率尔对团队保证产品的特色、时间等等。更糟 的是，医生往往是在整体系统大都健全的情况下，对其中 的一部分功能做医疗；而软件开发则常常得面对全新的、 从来没有运作过的系统，不确定性更高。
当然，任何情况都是有可能的，即使 是再简单的医疗行为，都可能有风险。
另外一件应该向医生学习的事情是，即使是再小再简 法则27建用医生的方法
199 单的医疗行为，都带着几分风险，所以医生会说：“当然， 任何情况都是有可能的，治愈率再高我都不能跟你说百分 之百没问题。”如果这样说都还不能让组员明白任何未来 的事都有不确定性、都有风险，那我也只好束手无策。我们必须记住，面对软件开发的不确定性，总会有方 法可以试试看。就像医生会试着让病人了解任何医疗行为 都有风险一般，管理者也应该让组员了解，任何项目都有 不确定性和风险。
“一切都还没有确定呢。” 下载
法则 28
Remember the triangle: features, resources, times 软件开发金三角：特 色、资源和时间 法则28建软件开发金三角：特色、资源和时间
201 作为一位软件开发的领导人，你得集中注意力在三件 事情：资源（人和钱）、特色（产品与其品质）和时间。 这三件事是软件开发的核心，其他的都是外围。资源、特 色和时间是三角形的三个边，任何一边的变化，都会影响 到另外一边或两边。所以如果时间落后了，去看你的三角 形，看看对特色和资源的影响；当有人谈到可以增加什么 功能特色时，你得立刻谈起时间和资源，以显得你思虑周 详反应敏捷。所以，管理者的第一要务是把这个三角形放 在心里，随时利用这个模式来思考问题，你会发现答案都 在这个三角形内。“好吧，我的时间落后了，我得利用另 外两个边来弥补，或是三边都得调整，我可以少一点特色， 我也可以加一点资源，或是修改一下时间。”由于人、时 间和特色都是你最关心的，所以你对这个三角形有具体的 概念，很快地，你就会发现这个三角形对你的思考帮助非 常大。
202
软件开发的金三角 法则28建软件开发金三角：特色、资源和时间
203 还有一点要记得，时间落后时，你只有四种选择：增 加时间、减少特色、增加资源或三者同时进行。但人是不 可以随便增加的。
不可加派人手？ 你是否听说过，加派人手是个错误的决策？在 佛莱德·布鲁克有关软件开发的经典著作《人力资源 之钥》（The Mythical Man-Month）中，用了很大的篇 幅来阐述他的论点：在软件开发项目中不当地增加人 手，反而会使工作进行更慢。布鲁克的观点被证明是 非常正确的，但我们应该了解的是，布鲁克是在写一 本书，而不是写一部适用的律法。然而，传统的教育使得人们用太过单纯的理解 方式，使得布鲁克真正的睿智多少被曲解─绝对不 要在进行到一半的开发团队增加人手，重点是“进行 中的团队”。虽然布鲁克十之八九是对的，但却成了 太多管理者的借口，理直气壮地决定不加派人手。是 的，增加人手是很难管理（人员应该在项目开始前就 规划妥当），通常也不是个好办法，只有在非不得已 时才考虑，但不是被禁止的。 下载
法则 29
Don't know what you don't know 不懂别装懂 法则29建不懂别装懂
205 对于不懂的事情，千万别装懂，或是看起来似乎懂， 也不要接受别人不懂却装懂。不懂却装懂一定会造成团队 管理上的困扰，这一点几乎没有例外，你若犯了这种错误， 一定会尝到它的苦果。在每个阶段的每一个人，一定有某 些重要的事情是他不知道的，这应该是被允许的。去掩饰 你不懂的事情只会造成别人在认知上的偏差，结果反而导 致不知道那些事情可以相信，那些不能相信。如果你勇于 承认自己不懂的事情，就不会掉进这个泥淖。人们会觉得对于重要的事情，我如果不知道就很丢 脸，这是天性。而在软件开发过程中，太多东西是大家 不知道的，因此，管理者或开发人员就很容易有这种不 懂装懂的倾向。好的开发团队应该有一张清单，上面列 着我们目前不知道的事情，这样才比较容易掌握到底什 么事情会不确定。抗拒“我都知道”的骄傲天性，是需 要团队士气和心理上的勇气的。对于管理者而言，称许 承认不懂的勇敢组员更加困难，尤其是这个事实已经被 文饰过的时候。虚假的文饰是面对未知事情的错误防卫 心理。
206
虚假的文饰是面对未知事情的错误 防卫心理。
我非常建议管理者重视组员了解自己什么地方不知 道，而不是被迫或自愿去掩饰。要让你的团队明白他们从 未检视过自己的未知，但要从现在开始练习承认自己不懂 的事情；一般来说，在团队成立的初期或转变阶段会比较 容易做到。我们没有时间拐弯抹角。最后，大家会明白成 功比较重要，牺牲一点点面子或是受到幻灭的打击又有什 么关系呢？你坚持组员必须面对不确定性，承认自己不知道，最 后会将无知变成知识。领导者的任务是让大家全都明白不 确定性是绝对的事实，必须强迫大家去面对它、适应它。 为了大家好，团队应该学会在不确定的环境中生存，并且 兴旺起来。既然要写在书里，就让我们说这是正式的规定：当有 一件事是不确定时，就直接说明这个事实，即使不确定的 事情是何时能够推出新版。不必担心，没有项目经理会因 法则29建不懂别装懂
207 为承认自己不知道的事情而被撤换。
知之为知之，不知为不知，是知也
208
不必说大家都晓得，我的属下会因为知道自己不懂什 么而获得我的加分，因为知道自己不懂，才会去求知。我 宁愿知道什么不足，这样我才知道什么事情可能会绊倒我， 我的同事和属下最好也明白这些。软件开发项目的目标并不是事前做好正确的规划，而 是每天都得在事情从未知到已知的时候，做出正确的抉择。 如果你明明不知道某件事却假装知道，你就无法在事情从 未知到已知的时候得到正确的信息，也就可能会做出错误 的决策。当信息证明你错了，你一定觉得非常难过。于是 你会更加害怕信息，而别人就以为你在抗拒事实，最后你 将陷入恶性循环。只有当你知道不确定性在那里时，你才有可能解决 它；那些没有被发现的确定事情，会把你绊倒。相形之下， 承认你不知道是比被击倒要好得多了。当你不知道事情该如何完成，当你内心有个声音在 质问你、在困惑你─面对它吧！不必害怕承认了自己 不懂就显得很笨，你一定会因此而学到某件事情的。在 你内心不断萦回的声音，事实上是团队还没浮现的怀 疑，而你收到了无形的信号。也许当你告诉别人时，得 到的回答是：“对啊，我也在怀疑同样的事情。”当然， 法则29建不懂别装懂
209 偶尔别人会认为你是不理性的空穴来风，没关系，那是 你在不确定的环境中必须付出的小代价（如果命中率实 在太低，也许你得看看心理医生，但至少不会令你延误 就医吧）。
表里一致 表里一致是一种平衡与调和。你是否说一套做 一套？或是想一套说一套？或是意念和行为不一致？ 我们的言谈真的是我们想说的话吗？我们是否让别人 牵着鼻子走？我们的行为和我们的感受与意愿是否一 致？当我们说要做，是不是要去做呢？我们是真的同 意，还是假装一下让别人以为我们同意？一致性是诚实与伪善的区别所在。当我在做某 一件事情的时候，我是因为这件事本身值得做，还是 因为它对别人似乎有点价值？我是诚实说明自己的看 法，还是比较倾向保护自己？当我认为某件事情是个 好主意时，我是否会去做呢？我是真的相信，还是让 别人以为我相信？一致性也是实情之所在。惟一比说出实情更难 的是了解实情。当周围所有的人都认定某件事情是对
210
的，但我实在不能证明，只有直觉地怀疑那是错的， 而团体思考模式尚未建立时，我能不能说出我的看法， 然后去发掘真相呢？
明人勿处暗室 下载
法则 30
Don't go dark 建立适当的检查点
212
假设在你接近检查点日期时询问开发人员：“情况如 何？跟得上进度吗？”他回答：“最近六个星期都进行得非常顺利，但是今 天的进度呢，是六个月前该做完的事。”不，落后不是一天造成的，落后不是到了项目快结束 时才出现的，也不是到检查点前一天才发生的，它每天都 在发生，每小时都会发生。每一次你泡一壶香浓的咖啡， 每一次你回个电子邮件、组装一部计算机、抓一只难解的 虫，都是落后发生的时候。为了对付进度落后的问题，你必须把一个大型的开发 工作切分成细细的小段，每一小段都是一个检查点，每一 个检查点都必须能够看出来有没有延误。检查点的间隔周 期应该多长呢？如果太长，检查点的效果不够；如果太短， 工作可能无法分割得这么细。软件不像堆积木那样简单， 程序之间的关系是立体的、动态的，倒是很像庖丁解牛。 在我的小组中，我们为此来来回回争论不休：五天？十 天？三周？根据我的经验，三周足以使情况失去控制。每家公司适合的检查周期并不一定。我们的做法是， 让组员和组员之间彼此协议，一方应在期限之内做出该 做的东西交给另一方，否则对方无法及时开始，如此就 法则30建建立适当的检查点
213 形成了适当的工作切割点，而且一有延误，我们立刻会 知道。比方说，我们知道这个星期的进度落后了一天， 一天可不是小事，这是非常必要知道的，这总比进度落 后了半年我们才知道要好得多了，万一到了那种落后程 度时，恐怕连计算落后多久都来不及了，全世界最糟糕 的事情莫过于此。全世界最糟糕的事情，是你迷失了，迷失在软件开发 的金字塔中。在孕育阶段你很可能有这种完全被搞迷糊的 经验：“我不知道该做什么才对，我不知道现在是离目标 更近或更远，我只知道现在的状况糟透了，我所做的每一 项措施似乎只有把事情搞砸，我只能确定每一件事情都搞 砸了”这种可怕的感觉是来自纵容黑箱工作─让工 作在没有人检查的状况下进行。把你的灯打开吧，让你的 组员在透明的环境工作，一天完成一天份量的工作。
迷失在软件中 我不必浪费时间向你说明开发进度落后是多么 严重的问题，你完全明白，否则你就不会在本书中找 寻答案。随便找个软件开发人员或项目经理问问看， 他们有没有经历过进度严重落后的问题，答案只可能
214
有两种：一是有，一是表面上没有但事实上有。表面 上没有但进度延误是因为原本估计的进度表过于宽 松，所以能补偿落后的进度，或是大幅降低目标作为 代价。更恼人的问题是，有多少项目经理或开发人员 感觉自己迷失在软件开发的金字塔中？大概凡是软件开发从业人员都能理解这个问题 的涵义，迷失是极可怕的感觉。空有满坑满谷的理论 帮你计算项目进度的指标，却完全没有办法让你摆脱 郁闷，每一个人都觉得闷闷的，你开始失去敏锐的判 断力，即使是有点疯狂的档案结构方式也被认真考虑， 焦虑、畏惧、烦恼、沮丧，偶尔又觉得挺有希望的。 你根本已经不知道自己在干什么，事情做得怎么样， 问题到底在那里，你的每一个动作都是大失败，你完 全束手无策。于是，你开始有一种信心溃散的直觉，自己一 定是能力不足才会搞成这样。接着，每一个人都会发 现你的恐惧，对你的信心也因此而消失；组员已经不 信任你，你还想如何领导他们？ 这些，正是每个项目经理人的锥心之痛。 法则30建建立适当的检查点
215
迷失在软件中
216
现在，基于检查点的重要性，你告诉开发人员：“我 们要每周做一次进度检查。”有人反映这样的管理太细了。 为了让这些人能够真正接受这样的管理方式，你得向他们 说明，还有其他的人等着这份程序完成才能开始做事─ 文件要撰写、品保人员要评核，而且还有其他的开发人员 也需要得知本阶段的执行结果，才能撰写或测试相关的程 序。团队成员彼此之间的工作时程有上下游和回馈的关系， 彼此互相依赖彼此的进度，于是形成了实施检查点的动机， 而不是靠管理者的铁腕来强制。有些产品的功能特色需要长达数个月或数年的时间才 能完成，但是时程的掌握是与任务大小无关的，因为任何 的进度延误都是一点一滴累积出来。也就是说，工作的切 割必须够细，万一其中一小段发生延误，可以在短期内立 即赶上。事实上，一个星期的检查周期已经够长了，想想 看，如果要在下一个星期内补赶进度，你是否做得到。因 此，即使管得太罗嗦，让组员讨厌你，但为了整体进度能 够如期完成还是不得不如此；而且如果大家都把时程当作 是最重要的，那么大家都会觉得时程表让人有成就感，而 比较不介意检查的麻烦。 此外，同事之间在进度上的互相依赖和承诺，也是顺 法则30建建立适当的检查点
217 利执行检查点的要素之一。就像产品设计的目标是让每位 成员都参与，每个人都贡献出自己最好的想法，检查点的 实施也是同样的道理，每个人都实践自己的承诺，这个制 度就能成功。比方说，开发人员玛丽答应文件撰稿人乔伊 星期五给他写好的程序，于是玛丽个人的信用就成了工作 的一部分，这时候玛丽会自动自发地如期完成；另一方面， 如果管理者比尔命令开发人员哈瓦德负责的程序必须在周 五前完成，那么哈瓦德心中对威权的反感成了工作的一部 分，而比尔对自己管理者形象的不安全感，也同样成了工 作的一部分。这又是创造智能财产过程中有趣的现象：每 个人的心理状态对成果都有直接影响，没有人例外。我在前文所提的表里一致，对于软件开发的影响就是 进度问题，每个人都重视自己的承诺和信用，彼此没有隐 瞒，而检查点的实施就会很顺利。对于那成千上万的小段 工作，就靠彼此的承诺和信用来维系。这和整体目标的大 小没有关系，倒和组员是否表里一致、勇于面对不确定性 很有关系。 下载
法则 31
Beware of a guy in a room 留心没有检查点的组员 法则31建留心没有检查点的组员
219
留心没有检查点的组员
220
法则31是法则30的特例，但有必要独立说明。 曾经有一次（其实是三次，但我实在惭愧得不敢把三个故事都说出来），我把最困难的工作分配给团队里最最 优秀的人才威廉，大家都知道他是最有经验、最有创造力、 技术能力最强的人，我们拥有他是上帝的恩宠。没有人怀 疑他的天份与判断力。当威廉开始他最具挑战性的工作时，他回房关上门， 此时陪伴他的只有水族箱、重金属音乐与莫扎特的旋律、 泡泡糖和星际争霸战的海报，以及 6箱果汁和可乐，一切 就绪后，他开始工作了。其他的组员都对他充满信心，非 常庆幸我们拥有威廉这样的天才可以扛下这么艰巨的任 务。在门外我们听到他快速敲击键盘的声音日夜不停，心 中在微笑，虽然没有人知道在关上的门内是多么伟大的程 序，但我们都觉得有高手威廉辛勤地为公司的命运打拼， 真是大家的福气。
他的前额出现了斗大的汗珠，显然 压力很大。 法则31建留心没有检查点的组员
221 （而这是前所未有的乐观情况，我们的目标很清楚， 我们的安全控管做得很好，我们的团队是最优秀的人所组 成，虽然我们偶尔来杯即溶咖啡，但我们都深信自己在做 一项伟大的计划，别人的批评我们充耳不闻。）渐渐地，我们开始看出威廉遇到了困难。他渐渐不回 家了，鱼也不喂了，音乐也停止了，斗大的汗珠出现在他 的额头，泡泡糖愈吹愈小，威廉显然是进度落后了。 整个工作只有威廉的部分没有检查点，他只要在完成 时交出作品就行了，当其他的人都已经如期完成份内的工 作，我们不得不敲敲他的门：“威廉，做得怎样了？”里 面是一阵迟疑，然后听到他说：“还不错。”“什么时候可 以完成呢？”经过更长的停顿，我们几乎听到泪水流下的声音，威廉哽咽着回答：“就快了。” 我们知道他说的“快”，其实还早得很。现在全公司的人都只能呆呆站着干等，一点也帮不上忙。而我，身为 主管和项目负责人，面临了困难的抉择：我可以开除威廉， 但考虑到他是惟一能够解救我们的人，惟一真正了解当前 困难之所在的人，所以我不加思索地决定，让威廉继续完 成他的工作，他毕竟是团对中最优秀的人才，也是团队中 惟一能够掌握这个问题里里外外的人。
222
我惟一能做的，只有替他买更多的 可乐。
另一个比较好的方法是给他加点压力，让他搞清楚自 己身系团队的危急存亡，所有组员和他们的家庭都指望他 不凡的脑袋和飞快的手指，我们得催逼他做出个像样的东 西出来。但我稍微三思，就觉得这也不是个好办法，对生产力 没有帮助。我没有办法摆脱这个困境了，我只能往好的方 面想：威廉会完成他的工作的，只要他没死或离职。经过 这次教训，他大概再也不敢为我工作了。现在我惟一能做 的事只有帮他买更多的可乐，其他什么办法都没有！当然，如果你有一位大天才关起房门埋头苦干，你或 许会有更具独特创意的结果，一种是健康型，一种是病态 型。病态型的闭关修炼是大天才无法在任何一关做出成品， 却能在期限的最后五分钟交出奇迹似的杰作；健康型的闭 关修炼是大天才免除一切世俗的干扰，全心致力于工作， 由于他的工作创意程度太高，完全得靠他的心理、情绪等 法则31建留心没有检查点的组员
223 内在的心智力量，这时候团队合作对他来说没有什么帮助， 反而有打扰之虞。像这种天才型的特殊程序设计师，为了清静而把自己 关在房间里很长的时间，而没有人知道他的工作进展，也 许是有发挥创造力的必要，但这对于如期推出产品而言是 冒着极大的风险，无论他多么优秀，领导者都不该把重要 的工作交托给他，除非让他与其他的开发人员一起接受定 期检查工作进度，而且对时限绝不宽贷。可惜有些天赋才 智恣意奔驰的人无法忍受这样的限制。在软件业中，这种 人确实存在，他可以做一些无法想象的创举（在实验室 里），掀起一波技术的飞跃，但他绝对不会出现在矢志如 期推出产品的开发团队中。不论是健康的或病态的闭关修炼者，允许一位开发人 员关在房间里没有人知道他的工作进度，结果通常会是开 发团队的致命伤。所以，一定得竭尽所能地避免这种情况， 绝对不要允许“没有检查点的组员”，否则你难逃失败。 下载
法则 32
If you build it, it will ship 软件要经常建构，就 能顺利推出 法则32建软件要经常建构，就能顺利推出
225 (软件通常是由许多许多程序组成的；程序写好 后，经过编译器产生执行码，这个动作叫 c o m p i l e， 通常如果是小而独立的程序，可选直接选择编译成可 执行档，但是以软件包或 C + +之类的大型软件而言， 程序数目都在数百个以上，通常每个程序都是编译成 对象文件，即object code，然后众多不同的程序依一 定的结构关系组合成一个软件，这个组合的动作叫作 建构，b u i l d，产生的结果是真正可执行的完整软件。 每一套软件的建构方式多多少少都有些不同，原则上， 被呼叫的程序或函数库要先b u i l d，主程序最后b u i l d。 —译者注）将程序建构成软件才能推出，这个自然，总不能卖给 顾客一个不可执行的原始程序代码吧！但我的意思是要能 够经常且定期地建构软件，并不是到了期限前一天才建构 那么一次。你必须随时都让整个软件的现状都能被大家看 见才行。(在很早以前曾经有过一个案例，各个程序都按 计划中的时间表进行撰写，个别程序的测试也完全正 确，但是到了最后却怎样也无法组合，各个程序就是 无法搭配。因为各个程序之间都有相互传递资料或先
226
后连结的关系，或是其中有一个程序内有个无伤大雅 的小瑕疵未被注意，但却在别的程序上造成大问题。 在写程序的过程中随时要注意我的程序能否跟其他所 有的程序相互配合，最好的办法就是常常 b u i l d，这 样才能做完整的测试。完整测试是 b u i l d最基本的目 的，所以作者就不刻意强调，但定期建构软件还有更 重要的益处。—译者注）你能想象几百位工匠蒙着眼睛盖一栋大楼吗？不知道 自己在盖大楼的那一部分，不知道这栋大楼现在盖到第几 层，只顾盖自己的部分，这种大楼怎会不垮呢？因此，经 常建构软件是非常必要的，这个法则的重点不仅是要在整 个开发过程中经常地、定期地建构软件，而且要尽可能建 构出现阶段最完整又最正确的软件，更重要的是建构出来 的结果要放在公开的地方，让每个人都能看到。软件也许不必每天都做建构，但是一定要经常且定期 做，而且不只是程序要做建构，安装程序和线上求助的部 分也要包括在内，然后将建构出来的结果放在公开的地方， 让品保人员可以评估每天的软件状况，也可以观察出它发 展的情形，或是陷于停滞。规律建构软件是一项最可靠的 指标，表示团队的运作是否正常，软件是否能够完成。 法则32建软件要经常建构，就能顺利推出
227
丑媳妇也要经常见公婆 软件的建构需要时间，程序也很复杂，值得你为它仔 细研拟最适当的策略。在微软内部有很多开发团队采取每 日建构的策略，并有专门的小组（build master）负责这项 工作。建构程序是很重要的，必须确定软件能够建构得起
228
来，没有失败或中断。在每一只程序置入（ c h e c k - i n）开 发环境时，会产生这一只程序需要的建构程序（通常是配 合适当选项的c o m p i l e），然后整合在整体的建构程序中。 于是其中任何一段建构程序发生问题的话，很容易找到由 谁来负责，所以组员的责任心和荣誉感会促使自己一定要 做出至少能够合格的程序，而每天的软件建构就会非常顺 利。当然你可以做得更严格，以我的经验，一天建构一次 是最有效率的方式（请参考下一个法则）。(有些软件公司每次的建构都是把所有的程序都 c o m p i l e一遍，然后b u i l d起来，有些则是将修改过的 程序c o m p i l e，再b u i l d上已有的软件。由于全部b u i l d 一次所需的时间可能太长，所以大部分的公司都采取 第二种方式。说得更口语一些，就是把其中的一块挖 下来改一改再嵌回去。当这段程序被认为 O K了，就 做置入的动作，c h e c k - i n；每隔一定的时间，就有专 人把这些被改过的程序compile和build。—译者注）另一方面，项目经理应该是拟定最佳化的建构策略， 而不是绝对性的每隔几天做一次建构。不一定要每天做， 应该是采取对软件最适合又最小的间隔，重点是在能够建 构出软件的前题下，用最短的时间间隔建构出软件。 法则32建软件要经常建构，就能顺利推出
229 老实说，我并不知道软件“应该”采取多长的建构周 期最好，但我非常相信大部分的软件公司在这方面都做得 不够。对某些开发团队而言，每天建构一次也许稍多，但 我很确定，对任何开发团队而言，每周建构一次绝对是最 起码的。项目经理一定要时常看见软件的整体状况，才能明 了现在正在做什么。即使你的工作分配和检查点设置得 非常好，各个组员之间的信任与承诺关系也非常理想， 但若是无法建构软件，则你对进度的掌握将仅限于想象 和猜测，而不是根据事实，所以你还是不能掌握软件开 发的真正状况。
每一次你建构软件，你就能算出错虫 数目有多少，你就能掌握软件开发 的进度，你就能看见功能日益成形。
再者，为了让软件能够建构出来，程序必须维持在 一定的品质水准，太夸张的错误要立刻被发现，而且不 可能将软件倒回去重来。因此，每隔固定时间建构软件，
230
才能够维持软件有一定的秩序和品质，这一点要让大家 都知道。更重要的是，定期建构软件就像是团队的心跳一样， 每天五点（比方说），大家都看到今天整个团队的工作成 果，每天都看得到今天的进步，这对团队士气有很大的 鼓舞。如果有一天软件建构失败，或是为了某种原因而 不做建构，马上就会引起大家的注意和紧张，一定要找 出原因来改正。如果建构经常失败，这就是整个项目失 败的前兆。但请不要搞混了，我所谓的软件建构，不是程序设计 师在自己的P C上做的小规模的建构，而是指正式的、公 开的建构，将大大小小的程序结合成软件，而且是每个人 都能看见、能执行的软件。品保人员可以对它做初步的测 试（sniff test），看看它的基本功能大致上有没有错误。如 果你每天都做软件建构，你就很有把握它至少不会当得惨 兮兮，而且大家可以看见它朝着目标一天天地迈进，功能 特色一天天地成形；而且每个人都测试着相同的软件，对 于软件的现状也就会有相同的认知。 经常建构软件还有其他的好处： 经常而公开地建构软件可以看出组员彼此之间真正 法则32建软件要经常建构，就能顺利推出
231 的信赖程度。只要有任何一个环节没有密合，软件 就建构不起来，检视建构的过程就像是检视组员之 间或是团队对外的关系，在任何地方发生问题都很 容易找到。 建构出来的软件可以显露出在设计时没有考虑到的 问题，例如执行效能、对象大小等等，这种问题万 一发现得太晚就来不及修改了。 软件的建构会很自然地让组员的脚步一致。一般 而言，建构软件最常见的问题是版本协调，最严重 的是各人有各人的版本，谁都不知道别人在做什么 版本，有了公开建构的软件，大家的版本就可以同 步了。 建构软件可以促使组员面对他想忽略的问题。团队 恒等于软件，所以目前的软件状态就是目前的团队 状态。当我遇到产品有问题时，我追问组员：“我 们软件建构的情况如何？”答案很多种，意思只有 一个：“我们花很多时间才能成功建构一次，有时 候长达两个星期，我们希望时间能够缩短，但是因 为某些某些原因，我们没有办法照计划来建构。” 是的，要频繁而规律地建构软件当然会有很多困难，
232
但是解决这些困难却能够带来健康的团队和顺利的开发。 开发人员必须得自律，自己仔细检查所有的功能都完善了 才把程序置入，程序不仅要在逻辑上执行正确，还得注意 体裁（程序段落清楚）和资源运用（内存用完了要释回）， 以及执行效能，如果个别的程序组件都很健全，就比较容 易建构软件，并且能够大大减少回溯检查的时间消耗。在开发过程中，很容易对软件的状况产生错觉，但 是如果你每天都建构一次软件，你看到的将会是具体的 事实。 下载
法则 33
Get a known state and stay there 掌握实际情况
234
这又是一个很简单又很有用的道理，引伸的意义是“每天都要有可以推出的产品”。 你必须对软件的实际状况知道得非常清楚，特别是要推出的时候，你必须知道它是什么模样，架构、特色、效 能特性等等。在你将它当成产品推出时，你必须知道所有 能够得知的情况。
如果你询问开发人员软件的状况， 他可能答对，但那是碰巧。
现在，假设有人要求你对刚推出的产品加进某一个特 色，你能够立刻掌握这个特色对软件的一切意义，那你就 会胸有成竹，因为你知道该怎么做才能加入这个特色，会 不会对现有架构产生重大的影响或冲突等等。你可以召集 一些开发人员和品保人员、文件人员，讨论一下就可以确 定大家对这项特色的了解，大家对自己的角色和任务范围 都非常清楚，然后你就可以说：“来吧，开始行动！”也许几天以后，也许一星期左右，那几位组员手上拿 着磁盘片来找你，告诉你新的特色做好了，只要安装这个 法则33建掌握实际情况
235 就可以把新的特色加入软件。并不困难，是不是？ 这是因为你能够充分掌握情况的缘故。你要知道，推出一个新版本就好像无数次不停地加上新的特色，然后推 出。这是最能让你理解组织软件开发活动的方式：将一群 各种角色的人组织成一组，负责一项功能特色；关键就在 让软件保持在你能充分掌握，又能够推出的状态。千万不 要让软件变成一堆凌乱的单元，千万不要让软件成为你不 清楚的状况，千万要抓紧对它的掌握，不要放松。想要掌握软件的状况，一定要有品保人员帮助你，你 需要有人专职负责检查软件的状况。如果你去询问开发人 员，他的答案也许是对的，但那只不过是碰巧猜对。开发 人员虽然是直接创造软件的人，但他们却无法知道软件全 面性的真实面貌，这还是得靠品保人员来评估衡量，让专 门的第三者来向你报告软件的状况。而且你每天都得亲自做点小的测试，一部分是自动的， 一部分是手动的；每周或每两周要把产品整个测过一遍， 确保你的软件随时都在可以推出的状态。什么叫做“掌握软件的状况”呢？就是在某一特定的 时间点，对于每一个产品组件的一切状态都有精确的信息。 因为有品保人员将各个组件都测试过，所以你能确知信息
236
是正确的。在你手上必须有一张清单，上面清楚列出各个 测试通过和没通过的功能、错虫数目、错虫发现率和清除 率，和一些其他重要的数据。我们要注重数据管理，像变动率（ c h u r n）就是很好 的数据，你可以看出有多少的程序代码增减，当然还有许 多其他的数据可以参考，都挺有用的。但重点是，你决定 要看那几项数据，就得每天去测量它们。
预定的目标能够确实完成，就可以 推出。
然而，并不是由品保人员去评估决定软件是否可以推 出。由于开发是团队全体的责任，软件是否可以推出在每 个人的心里都有数，这应该是不会有争议的─原本设定 的目标能够确实完成，就可以推出。当你终于在每一项预 定功能上面打勾表示完成时，你会拥有那种真正的成就感（还有你的报酬），难怪你愿意为这个勾勾去努力。 但先决条件是你能掌握软件的状况，而且维持有关软 件的最新信息。你必须善用你的品保人员来做到这一点。 法则33建掌握实际情况
237 时时刻刻对软件的状况清楚掌握其实是相当困难的， 你必须有一群非常优秀的品保人员。很多软件公司只有很 少或没有真正的品保人员，所以永远无法掌握软件的状况， 事实上，一个现代化的软件开发团队是不能没有品保的。
记录里程碑 这一段主要是对法则3 3的补充说明。我在此特别要针 对这些软件开发的观念作详尽的说明，这些都是我多年来 不断摸索、思考、创见、旁征博引以及求来的，是我与多 位极聪明的同事，犯过不少大错所换取到的。你想在软件产业中占有一席之地吗？你想有点不凡的 进步，不是吗？所以你必须做个“里程碑”（m i l e s t o n e） 的记号，表示你现在到达了某个目标，但你还要前进到下 一个里程碑。里程碑一定要有一种衡量的标准，否则很难达到，所 以不要设定一个无法精确定义的目标。你的每一个目标， 不论大小，都应该有个专属的档案来做记录，你的资源投 入一定不能模糊随便。 下载
法则 34
Use ZD milestones 零缺点里程碑 法则34建零缺点里程碑
239 在发展中的软件本质上是无形的、捉摸不定的。一部 分存在于开发人员的脑袋，一部分是在媒体里边看不见的 字节，一部分以纸张的形式散见于各个计划中的文字，更 有一部分是完全不知道的潜意识，随时都在变化，要到适 当的时机才会被激发出来。而团体的潜意识，不论是创造 性或是病态性，在无形中都表现在组员的日常活动和每天 所做的决定中。正如前文所述，软件恒等于团队，所以团 队的一切状况都表现在软件之中，软件就是团队活生生的 投影。
零缺点不代表软件中没有错虫，也 不表示没有遗漏的功能。
如果想把软件的开发活动管理得当，就得让软件定 期“整装待发”，这时候大家对软件所付出一切有形无形 的努力就可见分晓，同时也可以分析那看不见的潜意识 究竟是创造性或病态性。当以各种形式分散在各处的软 件组件建构成一整体之后，你可以得到完整的软件状况 信息，看看下回应该改进什么。然而，即便是经常建构
240
软件的好处那么多，这件事背后所需的一切─包括产品 的设计、发展程序和团队内心潜藏的各种动力，实在是 件复杂无比的工作。
软件推出就是最后一个里程碑。
暂且不管多么复杂，为了让开发工作能够顺利进行， 你至少要让组员把手上的工作划出一个成形的句点，并且 要有勇气面对一切麻烦的问题，同时也让组员加强对软件 现状的了解，让组员更有信心、更有能力预测自己付出什 么程度的努力会有什么样的结果。一开始大家都会很痛苦， 但慢慢能够培养出这些能力，对这些场面应付自如，开发 工作也会顺利起来（请参看法则3）。很多微软的开发团队使用“零缺点里程碑”（Z e r o Defects milestone）的方式来了解软件现状，简称“ Z D” 里程碑。所谓零缺点，并不代表软件中没有错虫，也不表 示没有遗漏的功能，而是指团队的成品达到了事先规划的 品质水准，也经过测试验证，就是零缺点里程碑。在 Visual C++的团队中，我们每一次推出产品通常会预先规 法则34建零缺点里程碑
241 划三到四个里程碑，一个产品周期正常是一年左右。 当然，最后一个、也是最高的里程碑就是软件推出， 但是其他的里程碑绝对是同等重要。我们在法则3 3中倡导，软件应该随时保持可以推出的 状态，而且每天如此、永远如此，这是个理想，但事实上 即使没有进度落后的现象，有时候也会做不到这一点，因 为你 偶 尔 会 需 要 倒 回 头 一 些 ， 去 处 理 前 面 的 问 题（regressive things），像是将前面为了换新功能而暂时替代 的东西要移除掉（好像在道路修筑过程中要另辟一条暂时 的便道才能维持畅通，确定修好了之后便道就得拆除）。 而零缺点里程碑，就像是经过较长的时间后的某一点，要 确保软件的状态必须达到预期的品质水准，好似定期大扫 除或大检修一样，不要把小缺点久留。一个里程碑大约是六星期到两个月，当这个日期到了， 除非里程目标已经达成，所有的开发活动都不能跨越这个 里程碑往下走。因此，里程目标常常被称为“中间产品”（d e l i v e r a b l e s），而且是大家都能看得到的。达成里程目标 之后，新的里程随即开始。这个原则说来容易做来难，如果你有充分授权的开发 团队，团队中的各个成员可以共同确定里程目标达成，管
242
理者没什么事要操心。每一次的里程目标都由品保人员事 先设计好验证的准则，事先沟通每一个通过验证的品质水 准细节，而且大家都同意、有共识。也就是说，这个中间 产品的品质水准是由组员协商出来的，而不是管理者命令 出来的。每一个中间产品都有事先定义好的验证准则，注 明每一项准则应该在什么时候通过，这许许多多的验证准 则会由项目经理集合起来，就是里程碑。采用“零缺点里程碑”最大的好处是，每当有进度延 误时，能够立即发现并在最短的时间内补上，也可以确保 问题能够防微杜渐，及时处理。如果你每一两个月就有一 次里程碑，你就得把进度延误控制在这个里程碑之内。你 在一个里程碑内所发生的进度延误总比整个项目少，也比 较容易赶上，这比到了最后推出时才发现要好得多了。每 一次里程碑都确实达到，也就给你一个确定的信息；若是 预定的里程碑日期到了，软件却又再过了 n周才达到应有 的品质水准，你至少有个立场来催促团队加把劲儿：“我 不知道我们最后的推出日期会延误多久，但这次的里程碑 已经确定我们落后了n周。” 下载
法则 35
Nobody reaches the ZD mile- stone until everybody does 所有组员一起到达零 缺点里程碑
244
如果有一个工作小组遇到的困难比较多，以致前进的 速度比较慢，而其他的小组已经完成份内的工作时，最好 让其他人支持比较慢的这一组；团队工作应该平均分配， 其中有一组做得特别快或慢都不是很好的现象，毕竟，团 队工作是全部都做完才能算完成，只要有一部分尚未完成 就等于失败。 有一种很不好的情况是（我真的遇到过这种情况）“落井下石”：比较快的小组发现比较慢的小组在开发关键 性技术时遇到困难，可能会使整个里程碑延后时，反而主 张在这一部分加入更多的特色。避免这种情况的办法是， 领导者必须让整个团队共同担负达到里程碑的责任，除非 每一人都达到了里程碑，否则就等于没有人达到里程碑。 下载
法则 36
Every milestone deserves a no-blame postmortem 完成每个里程碑后，心 平气和地检讨
246
每完成一个里程碑后，紧接着应该做一次检讨，这并 不需要花很多的时间，却能让团队下一次更好。当我们认 为做到了百分之百，是不是真的没有任何遗漏？好的检讨 绝不是指责任何人拖累进度。项目经理可以召集一个会议， 每一个特色小组中至少有一人参加，或是请大家有任何心 得都不要客气，发个电子邮件告诉项目经理，检讨会最后 的结果再由项目经理发电子邮件给每一个人分享。尤其是 做得特别好的事情，应该在检讨会中强调，大家以后就更 知道怎么做会最好。在每个里程碑之后立即做一次检讨， 是一个群体学习的最好方法。在里程碑之后责难某人或某小组拖累大家的进度，是 愚蠢的自我伤害。讨论进度延误的目的仅限于：研究下次 如何避免，加强大家对延误的警觉心，以及万一延误时最 好的补救方法。进度延误的不利后果发生在属于大家的软 件事业，不是管理者该去判断或核准的。延误势必增加公 司的经营成本，团队成员不会天真到以为自己不受影响， 所以管理者不必刻意惩罚，只要让团队明白延误对大家的 伤害，下次就会特别小心了。 法则36建完成每个里程碑后，心平气和地检讨
247
责难任何人拖累大家的进度是愚蠢 的行为，就好像责怪叶子不可以从 树上掉下来一样没有意义。
对于个别组员而言，延误进度是不好，但也具有某些 教育意义。一般来说，只要是健康的团队，不论成员的素 质高低或是延误的情形严重与否，发生延误的组员都会觉 得不好意思，而主动试着解决它，他会尝试修正对自己的 期望，改善自己的工作效率或工作方法。管理者应该帮助 他，责难他是愚蠢的行为，就好像责怪某一片叶子怎么可 以从树上掉下来一样没有意义。如果你在每一次的里程碑之后都做了足够的反省，而 且你的组员都吸收了里程碑给他们的教育，你的团队一定 会逐渐成熟，最后每一次的里程碑都会准确无误地达成。 下载
法则 37
Stick to both the letter and the spirit of the milestones 把握里程碑的实质意 义与精神 法则37建把握里程碑的实质意义与精神
249 里程碑的做法在成本上是比较高的，而且团队得承受 比较大的痛苦，但这是惟一能够确保开发成功的方式。团 队成员为了协调出里程碑的衡量准则，所付出的时间精力 就是里程碑的额外成本；为了能具体标示出里程碑不得不 修改特色，团队的理想被打了点折扣，内心多少有点失望 心痛。而更多的痛苦是来自于设法使大家都专注在里程碑 上，协调大家对里程碑产生一致的价值观，为了里程碑愿 意付出额外的时间和努力，即使真正的推出时间还早得很， 我们却要劳师动众地练习、经历这个大家都辛苦的中间产 品“假推出”。然而“零缺点里程碑”所带来的好处远超过这一切所 付出的代价，每个人所获得的经验和成长也远超过这些痛 苦。实施零缺点里程碑可以让软件评核的过程在开发初期 就开始，藉此可以带来团队的共识；对事实的了解和包容 成了最高的团队价值，因为有太多人对人、群组对群组的 信赖和承诺，不是实践就是食言。里程碑内容的定义，就 是大家对自己工作的期望。从某个意义来说，里程碑就代 表了团队承诺的信赖度。经过项目初期的几次里程碑之后，在团队中已经培养 出对里程碑的使命感，能够准确地判断自己可以实现什么
250
承诺，在这样的时间限制之下，那些事情可以完成，那些 不能。我曾经经历过几次“字面上的里程碑”，团队把里 程碑当作形式和教条，而不去实践里程碑的实质意义和精 神，这是很糟糕的。以我的经验，凡是健康的团队，都会 对“一致性”（请参考法则2 9）有很强烈的感受力，会极 力避免任何欺骗自己或逃避现实的事情，完全自发地希望 一切都是真实的，而不是被迫遵守任何传统的教条或规定。 健康的团队喜欢里程碑和组员之间有一致性，不要形式化 的里程碑，或是过度严格而做不到的里程碑。说实话这是 一个成功开发团队的重要品德，我曾经看过组员之间互相 挑战对方，是不是在欺骗自己承诺做不到的事；在健康的 团队中，组员能够“嗅”得出来彼此是否在说大话。
我曾经听过组员之间彼此挑战，是 否在初期的里程碑目标上太过高估 自己。
在项目初期的里程碑，把要求放低一点是可以接受的， 比较困难的特色不要求在这个里程碑中完成、品质水准不 法则37建把握里程碑的实质意义与精神
251 必那么高、资源可以多用一些，这些都不要紧，可以当作 团队成长的代价。反而是忽视已经发生的问题而不予补救， 或是对于团队成长的问题自欺欺人，才是致命的大错误。 只有在项目初期不断自我检验，团队才能成长，在往后的 里程碑中才能学会掌握软件成功的诀窍。 下载
法则 38

返回书籍页