代码之道-第1部分

快捷操作: 按键盘上方向键 ← 或 → 可快速上下翻页 按键盘上的 Enter 键可回到本书目录页 按键盘上方向键 ↑ 可回到本页顶部! 如果本书没有阅读完，想下次继续接着阅读，可使用上方 "收藏到我的浏览器" 功能 和 "加入书签" 功能！




献给当初对我说“为什么不由你来写？”的人：Bill　Bowlus（1）
你手上拿着的是一本关于最佳实务的书。它会比较乏味。但也许会比较有意义，你能从中得到知识，读后甚至对你产生些许影响，但读起来肯定还是干巴巴而无趣的。为什么这么说呢？
　　最佳实务的书是乏味的，因为这个“最佳”是跟具体的项目、具体的人、他们的目标以及偏好紧密相关的。一个实务是不是“最佳”，大家可能看法不一。作者必须把实务列举出来让读者自己来选，并分析在什么时候、因为什么原因作出最佳选择。虽然这种做法是现实的、负责任的，但也是令人厌烦的，最终无法取悦读者。为释疑而设计的案例研究会使文字有味一些，但作者仍必须把选择的机会留给读者，否则作者就会显得傲慢、教条并且死板。
　　然而人们喜欢看到傲慢、教条、死板的学者之间的针锋相对。大家喜欢引用学者们的观点片段，与朋友和同事一起讨论。为什么不把这些最佳实务当作观点栏来争论呢？惟一的条件，就是要有人愿意将自己扮演成一个思想保守的傻瓜。
　　本书的由来
　　2001年4月，在我历经了Bank　Leumi、Jet　Propulsion　Laboratory、GRAFTEK、Silicon　Graphics、Boeing等公司总共16年的职业程序员生涯，再在微软做了6年的程序员和经理之后，我转入了微软内部的一个以在公司范围内传播最佳实务为职责的团队。当时这个组正在运作发行名叫《Interface》月刊网络杂志的一个项目。它很有意义，且富有知识性，但同样也是干巴巴而无趣的。我那时建议增加一个观点栏目。
　　我的上司Bill　Bowlus建议由我来写。我拒绝了。作为一个半大孩子，我努力成为一个协调员，撮合多方产生成果。成为一个爱唠叨的实务学者会毁掉我的名誉和效力。因此，我当时的想法是说服一个大家公认的小心眼的工程师来写，他可能是我在微软以前6年工作经历中接触过的一位固执的开发经理。
　　但Bill指出，我有22年的开发经验，4年的开发管理经验，写作技巧也还行，而且有足够的态度来做这件事。我只需要放下自身的心理包袱。另外，其他的开发经理都忙于常规的工作，不可能每个月来为我们写观点。最后Bill和我想出了一个用假名撰稿的点子，于是I。　M。　Wright的“Hard　Code”栏目诞生了。
　　从2001年6月开始，我使用“I。　M。　Wright，微软逍遥的开发经理”这个署名为微软的开发者和他们的经理写了49个“Hard　Code”观点栏。这些栏目的标签行都打上了“绝对诚实，重拳出击”的标语。每个月，成千上万的微软工程师和经理都在读这些栏目。
　　前16个栏目在《Interface》内部网络杂志上发表了。随后同事（Mark　Ashley和Liza　White）给我分配了更多的主题。我和《Interface》的美工Todd　Timmcke还一起制作了作者的很多搞怪照片。当网络杂志停刊的时候，我才得以喘息的机会，但也停止了写作。
　　14个月之后，在我们组的同事Amy　Hamilton　（Blair）、Dia　Reeves、Linda　Caputo、Shannon　Evans和Marc　Wilson的帮助下，我又开始在内部站点上发表我的栏目。去年11月份，我将所有的栏目转移到了一个内部的SharePoint博客上。
　　2007年春天，正当我打算休掉几年前奖励给我的假期的时候，我现在的经理Cedric　Coco给了我在休假期间将“Hard　Code”出版成书的授权。而微软出版社的Ben　Ryan也同意了。
　　除了我已经提及的人，我还想感谢《Interface》的其他成员（Susan　Fario、Bruce　Fenske、Ann　Hoegemeier、John　Spilker和John　Swenson），其他帮助过本书出版的人（Suzanne　Sowinska、Alex　Blanton、Scott　Berkun、Devon　Musgrave和Valerie　Wolley），支持我的管理层（Cedric　Coco、Scott　Charney和John　Devaan），我现在的和以前的、复审过我的栏目并提出过很多主题的团队成员（William　Adams、Alan　Auerbach、Adam　Barr、Eric　Bush、Scott　Cheney、Jennifer　Hamilton、Corey　Ladas、David　Norris、Bernie　Thompson、James　Waletzky、Don　Willits和Mitch　Wyle），我才华出众的中学英语老师（Alan　Shapiro），以及那些慷慨给予我反馈的读者们。特别地，我还要感谢我的妻子Karen和我的儿子Alex和Peter，他们让我做任何事情都充满信心。书　包　网　txt小说上传分享

献给当初对我说“为什么不由你来写？”的人：Bill　Bowlus（2）
本书的读者
　　组成本书的49个观点栏最初是写给微软的开发者和他们的经理看的，尽管它们也是我过去在软件行业6个不同的公司、28年的工作经验中提炼出来的。编辑和我一起修正了表达语言，注解了那些微软内部的特殊用语，使得本书适合于所有软件工程师和工程经理阅读。
　　我在这些栏目中表达的观点是我个人的，不代表我现在和以前任职过的任何一家公司，包括微软。我在栏目中的注解以及本简介中的言论同样都是我个人的，与公司无关。
　　本书的组织方式
　　根据主题的不同，我把所有栏目分成了10个章节。前6章剖析了软件开发流程，接下来3章重点讨论人的问题，最后1章批判软件业务运转方式。用于解决这些问题的工具、技巧和建议遍布全书。本书的最后还附有术语表和索引方便大家参考。
　　每一章的各个栏目均按照当初在微软内部发表的时间顺序排列。每章开头我都给出了一个简短的介绍，随后就是当初我以I。　M。　Wright名义发表的栏目内容。编辑成书的时候，我还适时在栏目中加上了“作者注”，以解释微软的术语，提供更新内容或者额外的背景知识。
　　编辑和我尽力保持了原有栏目的完整性。我们做的，仅仅是纠正语法和内部引用。称得上改动的其实只有一处：就是将原来一个叫“你被解雇了”的栏目标题改成了“最艰难的工作”，因为以前那个标题太容易让人误解了。
　　每个栏目都以一段激昂的演说开场，然后就是问题根源的分析，最后以我对这个问题如何改善的建议结束。我酷爱文字游戏、头韵和通俗文化，因此栏目中充斥着对这些东西的引用。特别是大部分栏目的标题和副标题都直接取材于歌词、电影对白和有名的谚语。是的，我自娱自乐，但撰写这些栏目确实给我带来了些许乐趣以及痛快的宣泄。希望你也会喜欢！
　　系统要求
　　本书提供的工具都是微软的Office　Excel　2003和Office　Word　2003格式的。只要你的电脑上安装有Word和Excel的浏览器，你就能使用这些文件。你也可以从如下站点下载这两个浏览器：
　　微软的组织结构
　　因为这些栏目最初是写给微软的内部员工看的，因此简要了解一下微软以及我在工作中扮演的角色会有助于更好地理解这些文字。
　　目前，微软的产品开发分成三大业务部门，总共有大概25条产品线，超过450个产品单元，和众多的功能团队。这些部门是平台产品与服务部门、微软商业部门、娱乐与设备部门。部门内的产品线是由相关的产品套件整合在一起形成的，比如Office　System和Visual　Studio。
　　每条产品线包含了大约20个独立的产品单元。通常情况下，这些产品单元共享源代码控制、建造、安装、工作条款跟踪和项目协调，包括价值主张、里程碑安排、发布管理和工程支持。除了这些协调服务之外，产品单元还有高度的自主权，可以对产品、流程和人员作出自己的安排。
　　一个典型的产品单元通常有一个产品单元经理（PUM，Product　Unit　Manager）和三个工程工种经理：部门项目经理（GPM，Group　Program　Manager）、开发经理（Development　Manager）和测试经理（Test　Manager）。其他工程工种，比如用户体验、内容发布（比如在线帮助）、实施，可能单独对某个产品单元负责，也可能在产品线或者整个部门中共享。
　　每个工种都要抽出一个或多个代表，以组成一个叫功能团队的虚拟组织，来开发具体的产品功能。这些人的工作仍然汇报给各自的工种经理。有些功能团队选择敏捷方法，有些喜欢精益模型，有些采用传统的软件工程模型，有些则根据实际情况混合了上述多种方法。
　　微软怎么能包容所有这些多样性和产品的区域自治、还能为朝着一个共同的目标有效地工作呢？这就要靠产品线公共的项目协调了。举例来说，产品线的价值主张为所有的产品单元和他们的功能团队设置并统一关键应用范例、质量尺度和框架体系。
　　为了促进跨部门和产品线的协调和共享，特别是为提高质量和效率，微软还设立了一个组织叫Microsoft　Trustworthy　puting　and　Excellence。它是我的上级组织。具体来说，我的工作职责是，要让微软全球超过1万名的开发者在构建令人兴奋的、高质量的用户体验时，能够做得更加开心、更富有效力。不用说，这是一项长期的工作。

献给当初对我说“为什么不由你来写？”的人：Bill　Bowlus（3）
我的团队每月将开发部门的领导层聚集在一起，谈论问题并指导我们的工作。我们研究公司范围内乃至整个行业内的工程方法，以期找到新的机会和领域去提高。我们通过网络共享工具、最佳实务，以及实施职业生涯指导。我们举办各种活动和奖项评比，与各种团队商讨，为开发中的各个级别、各种角色提供技术培训。非常棒的工作！另外，我每月还在写着观点栏。
　　示范工具和文档
　　本书提到的示范工具和文档，作为本书的附属内容，都可以通过如下地址下载到：
　　在线资料列表
　　工具 栏目 章节
　　Sprint　backlog：　；
　　 敏捷子弹 2
　　Product　backlog：　；
　　 敏捷子弹 2
　　Spec　template：　Spec　 糟糕的规范书：该指责谁？ 3
　　Spec　checklist：　Spec　 糟糕的规范书：该指责谁？ 3
　　Pugh　Concept　Selection：；
　　 复审一下这个 5
　　Inspection　Worksheet：　；　 复审一下这个 5
　　Interview　Role　Playing；　a　how…to　guide：
　　 面试流程之外 9
　　本书的支持
　　为了保证本书及其附属内容的准确无误，我们尽了最大的努力。本书所有的修正和改动都会搜集起来并放到微软的知识库中去。微软出版社通过如下站点对本书及其附属内容提供支持：。
　　问题和意见
　　如果你对本书及其附属内容有任何意见、建议或问题，并且通过访问上述站点仍然无法解决，请给微软出版社发送电子邮件：　mspinput@，或者按照如下方式邮寄：
　　Microsoft　Press
　　Attn：　I。　M。　Wright’s　“Hard　Code”　Editor
　　One　Microsoft　Way
　　Redmond；　WA　98052…6399
　　请注意，上面的地址对微软的软件产品不提供支持。
　　书包　网　。　想看书来

读者对I。　M。　Wright’s　“Hard　Code”栏目的喝彩
任何大型组织都有危险成为自身文化的牺牲品。关于世界应该是什么样子或者事情应该怎样去做的神话，最后证明都是一个个自圆其说的预言。任何组织都会有这种倾向，但它对于需要不断创新才能繁荣的技术公司来说，却是个致命杀手。Eric　Brechner做了件难以置信的事——他亮出了手术刀，深深地切入了组织内部看似无关紧要的东西。他毫不吝啬地打出了重拳——偶尔也会故意玷污自己的名声。尽管有一些隐语和例子对于微软内部的员工更有吸引力，但他的智慧和至理名言，大都可以成为整个软件行业的财富。
　　——Clemens　Szyperski，首要架构师
　　“I。　M。　Wright”写的关于开发时间表的文章真的是太棒了！它在我所属部门参与的基础设施项目上同样适用。
　　——Ian　Puttergill，部门经理
　　你没有受到任何死亡威胁，是吗？
　　——Tracey　Meltzer，高级测试主管
　　这一定是个笑话——很坦率地说，这类纯粹的谬论危机四伏。
　　——Chad　Dellinger，企业架构师
　　Eric是我本人崇拜的英雄——很大程度上是因为他长期以来一直代表着开发社区的一种声音。
　　——Chad　Dellinger，企业架构师
　　软件工程师很容易就会迷失在他们的代码中，甚至更糟糕的是，他们迷失在过程中。那正是他们迫切需要Eric在“Hard　Code”中提出的实用建议的时候。
　　——David　Greenspoon，总经理
　　我刚刚读完这个月的栏目……我不得不指出，这是我第一次认为你正在推行一个对公司完全错误并且带有灾难性的想法。
　　——David　Greenspoon，总经理
　　Eric你真了不起？　几个月之前，我跟我的产品单元经理和一些开发主管恰恰进行过这样的一次对话。
　　——Scott　Cottrille，首要开发经理
　　我真的很喜欢这些栏目。它们是如此实用，而且还很全面！我喜欢它们的另外一个原因是，当我在指导初级开发人员的时候，我可以把这些栏目推荐给他们；他们也会记住这些栏目，因为它们都是那么地有趣。
　　——Malia　Ansberry，高级软件工程师
　　Eric，干得好！我觉得你在这个栏目中说得非常中肯。我想，该给管理者传递这样的信息，“不要害怕试验。”事情的真实情况跟理想化的理论之间差别是非常大的。
　　——Bob　Fries，合作伙伴开发经理
　　我只是想让你知道我有多喜欢你写的文字——它们充满智慧、见解深刻，你还神奇地把本来很严肃的问题变得如此有趣（采用的方法很不错）。
　　——Niels　Hilmar　Madsen，开发者传教士
　　你那篇关于死亡行军的栏目来的正是时候。我们正打算在未来几周内开会讨论功能削减的事情呢！那些我们以前付出很大代价才学到的教训，不知怎么回事，总是轻易就被忘记了；你的栏目对大家起到了很好的提醒作用。
　　——Bruce　Morgan，首要开发经理
　　我想让你知道的是，我真的很喜欢并感谢你在EE站点上发表的所有文章。不过，直到今天，当我读了“停止写规范书”这个栏目之后，我不得不说，我强烈不同意你的观点。
　　——Cheng　Wei，项目经理
　　你到底是谁？你跟Eric　Brechner都做了些什么？
　　——Olof　Hellman，软件工程师
　　Eric，我刚刚读完你写的那篇叫“不恰当的比较”的文章。你不知道我有多感激你！你实际上把这个观点传达给了公司里面成千上万的人……你致力于正确领导和管理团队，并把其中的奥秘跟大家分享，对于你的这种热情我真的非常欣赏！
　　——Teresa　Horgan，商务项目经理
　　

序
长期以来，我一直在阅读Eric　Brechner以I。　M。　Wright为笔名撰写的栏目。当我第一次见到作者本人的时候，我费了好大的劲才让自己相信，我是在跟同一个人说话。Wright先生非常地自以为是，然而站在我面前说话的人却那么谦虚、彬彬有礼、非常友好，他看起来更像Clark　Kent。（译者注：Clark　Kent是“超人”的名字，他具有超强的本领，是一个虚构的超级英雄，美国漫画中的经典人物。）
　　我很关注微软内部团队在软件开发的过程中，他们是如何去处理技术与人际交流之间的关系的；这类栏目总是我的最爱。看到大量的公司内幕被写了出来，我常常会感到吃惊——我不知道还有多少不为人知的故事没有说出来。
　　大型项目中的软件工程管理者面临着3个基本的问题。第一个是，程序代码太容易被改变了。跟机械或土木工程不一样，它们在现有系统上做一次改变总是要付出实实在在地拆毁某些东西的代价，而软件程序的改变只需要敲敲键盘就行了。如果对一座桥的桥墩或一架飞机的引擎做一个错误的结构性更改，由此产生的后果，即使不是专家也很容易就能看出来。然而，如果在一个现有程序上做修改，对于其风险，即使经验丰富的软件开发者进行了充分的讨论，其结果常常还是错的。
　　建筑隐喻实际上可以很好地适用于软件。基于程序代码在系统中所处的层次，它们可以被比作为“基础、框架和装饰”。“基础”代码具有高度的杠杆作用，它们的改动常常会引起严重的连锁反应。“装饰”代码比较容易改动，而且也需要被经常改动。问题是，累积了几年的改变之后，复杂的程序就跟历经过几次装修的房子差不多了——电源插座躲到了橱柜的后面，浴室风扇的出风口通向了厨房。再做任何改变的话，其副作用或最终的代价都是很难预知的。
　　第二个基本问题是，软件行业还太年轻，关于可复用组件的正确标准实际上还没有被发现或建立起来。大头钉是否应该放在离开16英寸的地方，以同时适应水平或垂直的4x8英尺的干垒墙或夹板？我们不仅在这类问题上还没有取得一致意见，甚至我们还没有决定，是否像大头钉、干垒墙和夹板这样的组合更可取，还是我们要去发明像泥浆、稻草、石头、钢铁和碳化纤维这样的组合。
　　最后一个问题实际上是第二个问题的另一种表现形式。每个项目中重复发明的软件组件，它们也被重复命名了。软件行业里对现有的概念发明新的名字是很常见的，即使用的名字相同，这些名字也以新的方式被重用。行业里有一个心照不宣的秘密：关于软件开发最佳方法的相当多的讨论，参与的实际上都是同一群人，只不过他们用了不同的名字，他们甚至对彼此正在说的东西都没有一个哪怕是很朦胧的想法。
　　表面上看来，这些都是很简单的问题。建立一些标准，然后强制实行它们。在快速进步的大容量、高价值、低成本的软件世界里，这可是一个让你的业务落败的捷径。实际情况是，软件最大的工程障碍，同时也是它最大的优势。无处不在的软件（运行在低成本的个人电脑和互联网上），已经使得以惊人的步伐去创新成为可能。
　　随着微软的成长，公司已经不再能在最佳工程实践的研究方面大量地投入，然后经过深思熟虑，挑选出其中具有最好质量的方法。个人电脑和Windows的成功，已经把公司从按传统方式做些小项目的形态转变出来，转而要去谱写开发有史以来最庞大、最复杂软件的新篇章。
　　为了能够创建出平衡风险与效率、创新的最佳系统，微软面临着持续不断的挣扎。考虑到我们的一些项目有着极度的复杂性，这些努力甚至可以称得上“英勇无畏”。在过去的一段时间以来，我们已经设置了专员、建立了专门的组织，他们都一心一意、致力于这个行业里最困难的事情——“软件发布”。我们已经学会了很多的民间传说、风俗、文化、工具、过程和大拇指规则（译者注：Rules　of　Thumb，是指没有经过科学实验、直接从实践中总结出来的方法和规则；它们在很多情况下都有用，但并不是放之四海皆准），那些都有助于我们建造和发布这个世界上最复杂的软件。但与此同时，每天都处理这些问题难免也让人心惊胆战、士气受挫。Eric的栏目正是大家跟我们一起分享和学习的极好方式。
　　Mike　Zintel，微软公司Windows　Live内核开发部门总监
　　2007年8月
　　第3章
　　根除低下的效率
　　本章内容：
　　2001年7月1日：“迟到的规范书：生活现实或先天不足”
　　2002年6月1日：“闲置人手”
　　2004年6月1日：“我们开会的时候”
　　2006年7月1日：“停止写规范书，跟功能小组呆在一起”
　　2007年2月1日：“糟糕的规范书：该指责谁？”
　　正如我在第2章的“精益：比帕斯雀牛肉还好”栏目中所说的那样，浪费和灾难在工作中常常相依相伴。关于这一点，没什么比组织的沟通（本章的几个栏目都会涉及这个话题），以及项目之间的自由时间的合理使用来得更为明显。这些领域影响的不仅仅是个人，而且是整个团队。因此，它们的影响也是成倍于其他领域的影响。
　　在我的恐怖字典中，规格说明文档（规范书）和会议始终占据着特殊的位置。我想可能是因为工程师花了太多的时间在会议上，而且常常还是在讨论规范书的原因吧。尽管我很希望这两样东西在我们熟知的世界中消失，但它们之所以存在必定还是有它们的用途的。我们能做的，是要关注那个真实的用途，而把其他多余的东西统统抛弃。
　　在这一章中，I。　M。　Wright介绍了一些策略去消除常见的低下效率。第一个栏目谈到了最后时刻的规范书变更。第二个栏目解决了项目之间的空闲时间的合理使用问题。第三个栏目聚焦在如何尽力消除会议的弊病。最后两个栏目竭力想彻底抛弃规范书，如果那不可行，至少也要让规范书短小精悍一点。
　　其他栏目在组织沟通方面会有更加充分的论述——从跨团队协商到跟非技术人员交流的方方面面。那些栏目还介绍了“个人”可以采取的改进措施。但本章这些栏目重在讲述“组织”能够采取的措施，以便最好地使用它们有限的时间。
　　——Eric
　　

对于每次变更，搅动，搅动，搅动
2001年7月1日：“迟到的规范书：生活现实或先天不足”
　　你已经达到了“编码完成”（Code　plete）的阶段，你正在全力修复Bug，这时候看看你的邮箱里收到了什么？啊，太有趣了，居然是一份新的规范书！把它一脚揣开，如何？请稍等，这可是以前的规范书不小心遗漏掉的一个关键功能，或者像我们常说的那样，“代码本身就是规范书。”
　　作者注：编码完成（Code　plete），是指开发者认为对于某个功能所有必要的实现代码都已经签入到源代码控制系统的一种状态。通常这只是一个主观判断，而更好的做法实际上应该基于质量标准来度量（那时候经常称作为“Feature　plete”，即“功能完成”）。
　　可以想象，测试人员被激怒了。因为他们没有及时拿到规范书，并且他们觉得“被排除在了项目开发周期之外”。实在太晚了！代码的表现跟规范书不符，但他们还没测试过。开发人员也感到焦躁不安，因为他们原以为功能已经完成了，但实际上测试人员却在疯狂抱怨他们实现的是一个“错误”的东西，这将导致大量的返工。更糟糕的是，开发人员当初实现的功能根本就没有在文档中被正确定义好。于是，大家对新的规范书展开争论，发现漏洞，然后再更改，搅动实现代码，直到项目失败——而这时候本该是产品的稳定化阶段。这下大家都“开心”了！
　　也许在极端情况下，变更还不止一次。但这的确有可能发生。即使变更没有那么晚，规范书常常也是不完整的，或者在尚未被开发人员及时复审和检查之前就匆忙交付开发了。
　　结果怎么样呢？搅动代码，一次又一次地更改以前的实现。开发人员开始编码的时间太早了！规范书本身就有问题，因此代码自然也有问题。当有人指出这些问题的时候，特别会议召开了，但有人被遗漏、缺席了这个会议，代码返工重写之后，那个被遗漏的人发现了其他地方的错误，于是需要召开更多的特别会议，就这样周而复始、永无宁日。
　　有什么办法可以解决这个问题呢？有些人可能会说：“项目经理是人渣，应该缠着他，直到他把工作做好。”这听起来有点残酷，哪怕是我也有这样的感觉。规范书来得太晚，这是生活的现实，问题在于你处理它的方式。我见到过有如下一些不同的方法。
　　作者注：我能想象，一些极限编程爱好者在那边嚷嚷了：“给他们一个房间！”（一个团队房间。）我在后面的一个栏目——“停止写规范书，跟功能小组呆在一起”——也会谈到这个观点。然而，微软是一个相当多样化的环境。不是每个团队都能呆在同一个地方的，文档通常是解决团队之间的相互依赖问题的必要手段。因此，也并不是一个解决方案能够解决所有的问题。
　　书　包　网　txt小说上传分享

走廊会议
第一种方法是走廊会议。当一个开发人员发现手头的规范书存在漏洞，这时候项目经理正好路过，于是一个走廊会议就开始了，一些问题通过这种方式得到了解决。那个开发人员很开心地回到他自己的座位，想着他终于搞清楚了接下去该做什么。那个项目经理也回到了他的办公室，想着开发人员写出来的代码肯定能够反映他真正想要的东西。也许他们在想同一件事情，也许不是。也许测试和实施人员会同意他们的解决方案，也许不会。也许他们方方面面都考虑到了，也许他们不曾做到。也许这是最好的方式去处理变更，也许猴子会冲出我的……好吧，至少你知道了有这种方法。
　　　。　想看书来

委员会议
第二种方法是委员会议。对于这种会议，不同的团队有不同的称呼，但它主要是用于讨论规范书变更的主管级会议。通常这种会议会定期召开，各个主管形成一个组织，他们聚在一起讨论规范书上的漏洞或者问题，并且以组织的名义寻找解决方案。主管的项目经理记录会议结果，并且发邮件告知整个团队。
　　这种方法的优点是：委员会议把该包含的人都包含了进来，达成了最终决议，记录在档，并且拿这些最终决议跟团队沟通。缺点是：委员会议也是可怕的噩梦。它们通常比较冗长、令人厌烦、使人筋疲力尽。它们占用了关键资源的巨大周期，阻碍了工作进展，成为了最要命的一种瓶颈——自我伤害和自我永续不断。
　　　电子书　分享网站

规范书变更请求
我最喜欢的方法是“规范书变更请求”（SCR，Spec　Change　Request），它还有一个扭曲的名字叫“设计变更请求”（DCR，Design　Change　Request）。这种方法是委员会议和走廊会议的组合，同时带有一些关键的改进。假设你现在想去改变规范书或者给规范书增加新的内容，你的这个想法可能是你自己想出来的，也可能源于一次走廊对话，也可能受到了一次主管会议的启发。
　　不管你是项目经理、开发、测试或实施人员，你都可以把你的想法写到e…mail中去，并且e…mail的标题定为“SCR：　　…　”。在e…mail结尾的地方，你用粗体字写下这么一句话，“除非有人强烈反对，否则这就是最新采纳的规范书。”然后，你把这封e…