嵋榛岫ㄆ谡倏鞲鲋鞴苄纬梢桓鲎橹蔷墼谝黄鹛致酃娣妒樯系穆┒椿蛘呶侍猓⑶乙宰橹拿逖罢医饩龇桨浮Ｖ鞴艿南钅烤砑锹蓟嵋榻峁⑶曳⒂始嬷鐾哦印�
这种方法的优点是：委员会议把该包含的人都包含了进来，达成了最终决议，记录在档，并且拿这些最终决议跟团队沟通。缺点是：委员会议也是可怕的噩梦。它们通常比较冗长、令人厌烦、使人筋疲力尽。它们占用了关键资源的巨大周期，阻碍了工作进展，成为了最要命的一种瓶颈——自我伤害和自我永续不断。
电子书 分享网站
规范书变更请求
我最喜欢的方法是“规范书变更请求”（SCR，Spec Change Request），它还有一个扭曲的名字叫“设计变更请求”（DCR，Design Change Request）。这种方法是委员会议和走廊会议的组合，同时带有一些关键的改进。假设你现在想去改变规范书或者给规范书增加新的内容，你的这个想法可能是你自己想出来的，也可能源于一次走廊对话，也可能受到了一次主管会议的启发。
不管你是项目经理、开发、测试或实施人员，你都可以把你的想法写到e…mail中去，并且e…mail的标题定为“SCR： … ”。在e…mail结尾的地方，你用粗体字写下这么一句话，“除非有人强烈反对，否则这就是最新采纳的规范书。”然后，你把这封e…mail发给最直接受这个变更影响的项目经理、开发、测试和实施人员。几天之后，当你根据他们的建议做完了必要的修改，你就可以把你的SCR发给团队中剩下的所有人，并且把它放到RAID中或者一个公共目录中，跟其他SCR一起跟踪。
译者注：关于RAID，参见本书最后的“术语表”。
这里的关键是，规范书的变更现在文档化了，并且得到了相关人员的复审，而且不会阻碍工作的进展。反对几乎总是例外，不会有很多。开发人员在任何时候都可以继续工作，这里只是一个权衡问题——动手做之前花更多的时间等待是否有反对，或者冒着后来被反对的风险马上就动手做。典型情况下，开发人员会一直等待，直到SCR经过了初始的几次修改后发给团队全体成员的时候才动手做。
预防是最好的治疗
当然，最理想的是规范书从一开始就不会迟到，至少你不能被它蒙蔽。这里就用得着T…I…M…E图表了。在T…I…M…E图表中，第一份规范书展示了对整个项目的设计。它不是简单的需求文档，也不是数个小型规范书的集合，而是项目的一个高级规范书，很像是开发主管写的那种高级架构文档。这个规范书应该展示项目将具有的功能和用户界面，以及它们怎样在一起协作，而把细节留给以后的规范书。所有后来的规范书和功能都必须参考这个高级规范书。
这样的话，开发、测试和实施人员就可以制定计划去说明未来所有的功能了。他们能够生产出集成得更好的产品，使用户体验更加流畅。项目经理也可以使用第一份规范书去安排剩下的其他规范书，先做优先级高的，而不必担心遗漏什么东西或者做出让别人吃惊的事情来。这种理想终究使T…I…M…E产生了（难以抗拒）。
作者注：T…I…M…E（Totally Inclusive Mutually Exclusive）图表是由Donald Wood首先提出的，但它从未像我的同事Rick Andrews最初预期的那样流行过。然而，微软现在的价值主张、远景文档、跨产品案例和仔细设计的原型都能达到同样的目的。
电子书 分享网站
宝宝做了件极坏的事情（1）
2002年6月1日：“闲置人手”
你的开发团队两周前达到了“零Bug反弹”（ZBB，Zero Bug Bounce）， 你突然意识到，你又迎来了一个“工作淡季”。任何从事零售软件产品开发、并且碰到过零Bug反弹的开发人员都知道这个“工作淡季”。但如果你的团队是提供互联网服务的，你现在可以停止阅读了。（等一下，你一开始读本栏目的时间哪来的？回去干活！）
作者注：零Bug反弹（ZBB，Zero Bug Bounce）描述了第一次出现项目中的所有功能都完成了、并且所有工作条款都解决了的那个时刻。这个时刻很少会长时间持续。通过进一步的系统测试，通常在1小时之内就会有新的问题暴露出来，随后团队又必须埋头去工作。尽管如此，零Bug反弹意味着项目在可预见的将来就要结束了。
零Bug反弹标志着项目状态从“瓶颈在开发方”到“瓶颈在测试方”的转变（“瓶颈在项目经理”没有类似的这种转变）。在处理完产品出货后最初几周内的一批新发现的Bug之后，大部分开发团队进入了“时而加速，时而等待”的模式——当有新Bug分配过来的时候奋力去解决它，否则就闲着不知道该做什么了。
最可怕的是，“工作淡季”有时候可能从零Bug反弹开始，一直持续到下一个版本产品的第一个里程碑。这在大项目中可能有几个月之多！开发经理手上总是忙着各种各样的事情，因而很容易就会忽略，其实三分之二的团队成员都闲在那里。你知道他们怎么说闲置人手的——嗯，不是很好听！
以下是闲置的开发人员经常做的一些坏事：
？ 抢修Bug。零Bug反弹之后，你的团队应该处于“禁闭”状态，这意味着，所有Bug在被修复之前都要通过分诊会议的慎重考量。闲置的开发人员有时坐在他们的位置上，敲击RAID（现在叫Product Studio）上的F5功能键等待Bug的出现。如果通过这种方式没有发现Bug，他们就会把视线转到正在被分诊讨论的那些Bug上，挑一个有趣一点的，然后开始研究它。在你知道之前，他们可能已经有了一个修复方案，并且正伺机悄悄地把代码签入进去呢……这就是抢修Bug！一个有自尊的开发者不应该做这样的事情。
作者注：在软件工程中，Bug通常是指代码中的错误。然而，微软内部使用“Bug”这个词泛指跟产品相关的所有增加、删除或者修改。但大家对外一般称这些为“工作条款”，其中有一些也可能是代码错误。我更喜欢“工作条款”的说法，这样就能把那些真正的Bug区分出来。
谁知道分诊团队是否会决定修复那个Bug呢？谁知道那个Bug是否被正确地修复了，并且也不会引起相关的另一个更大的或者小一点的Bug呢？对于潜在的重大问题投入一点调研是可以的，但绝对不要抢先去修复！
？ 修复尚未报出来的Bug。现在有一个Bug通过了分诊，你正在进行修复。这时你注意到，在你修改的代码附近有其他更多的Bug（通常这些Bug是由以前的修复引起的）。但不知怎么搞的，这些Bug还没有被人报出来。你看到了这些代码，而其中的错误也尽收你眼底。为什么不一起把它们都修复了呢？喂！就此打住！！！
开发团队通过代码复审来避免这种可怕的事情。在“可信计算”时代，团队应该在整个项目周期内复审每一次代码签入。当团队处于“禁闭”状态时，要保证有3双眼睛（即代码改动者本人和另外两个开发者）同时审查每一次的代码改动。至于开发人员在修复一个Bug时发现的其他Bug，则要通过如下方式来跟踪：先把它报出来、登记到Bug数据库中，然后再分诊……
作者注：《凯文与霍布斯》连环漫画系列中有这么一个故事：凯文对一只苍蝇慈悲为怀，打开前门让它飞出去。结果呢？这只苍蝇非但没有飞出去，反而另外3只苍蝇飞了进来。这就是为什么你必须在项目逼近尾声时，要对每一个Bug进行研究和分诊的原因了。我的团队曾经在我们的产品发布前一个月的时候改变了一个参数的值，结果一周之后，全公司的测试人员都发现：只要打开CD托盘，所有的应用程序都会停止响应。最后，我们往回追踪到那个看起来无关紧要的参数，并把那个改动撤销了才解决问题。这种事情真实地发生在我们的周围，只是你未必知道而已。 。。
宝宝做了件极坏的事情（2）
？ 修复标为“延期”的Bug。大家知道，被标为“延期”的Bug在产品发布给制造商（RTM，Release To Manufacturing）之前是不能去修复的。那么，是不是应该在计划下一版产品的时候去修复它们呢？不对！当初在项目的进行过程中，产品的相关团队对“哪些Bug对我们的客户影响最大，因此必须在发布之前修复”作了判断，但这种判断在产品没有真正发布之前是无法验证的。当产品发布之后，你就没必要再去猜了。“产品支持服务”（PSS，Product Support Services）、Watson和“微软咨询服务”（MCS，Microsoft Consulting Services）会告诉你的，而且它们非常坦诚。那些标为“延期”的Bug只具有参考价值，用于理解为什么这些Bug当初没有要求去修复。注意，你不要再一次去猜测已经真实存在的客户。你要做的是，关注用户反馈，修复真正影响用户的那些Bug。
？ 重写“丑陋”的代码。开发人员讨厌“丑陋”的代码。这些代码常常麻烦不断，可读性差，难以维护。因此，当开发人员手头有空的时候，他们经常自言自语：“哈，我手头没有规范书，因此不能开发新的东西。我为什么不趁此机会重写那些讨厌的丑陋代码呢？”他们知道，如果给第二次机会的话，他们能够做得更好。他们也的确可以做到。他们可以在第二次的时候，重写出漂亮得多、清晰得多的代码，而且比第一次写的时候少了很多Bug。
令人遗憾的是，重写的代码实际上将比当前的丑陋代码带来更多的Bug。因为当前的丑陋代码是在第一次编写的基础上，经过了几个月甚至是几年的测试和修复之后才达到的质量水准。
有时候重写是必要的。重写可以提高代码的性能、扩展性、可靠性、安全性、或者对于新技术的适应能力。在这些情况下，应该把重写当作一个功能来对待；像处理其他功能一样，写一份规范书，然后为它制定时间表。否则，不要做代码重写这种愚蠢的事情，它只会重新引入一大堆令人讨厌的Bug，而且还对客户价值没有丝毫的贡献。
作者注：我的上述观点同样适用于“重构”（Refactoring），尽管我很讨厌提到它。哪怕重构是在你毫无察觉的情况下由电脑自动完成的。这并不是说你不应该进行定期的代码重构或复审，而是说，你不应该随意地做这些事情。做不做都应该由团队来做决定，并且要保证手头有足够的“单元测试”来防止引入大量的新Bug。如何正确地做这些事情才是关键。
？ 在编码风格上争论不休。谈到最消耗开发团队时间的事情，在空格、括号、匈牙利命名法等问题上的争论必定在前5名之列。请记住：使用一种一致的编码风格对你代码库的质量和可维护性大有裨益，而你的团队具体使用哪种风格一点都不重要。你是开发经理，你来选一个并坚持使用它。谁说这也需要民主？！
txt小说上传分享
告诉我该做什么
关于闲散时间的阴暗面我已经说得够多的了。在这个清静时期，你的开发团队可以做些什么有建设性的事情呢？
很自然，测试团队会坚持说，在产品发布给制造商之前的这段时间里，开发人员应该帮着找Bug。而项目管理团队会坚持说，在产品发布给制造商之后，开发人员应该花时间去阅读和复审规范书。不过，这些事情对开发团队来说没有太多实际的工作量、不具有吸引力、也无法让他们开心。
那么，开发人员在“工作淡季”到底可以做些什么呢？下面是我的一些想法：
？ 分析Bug。分析团队在过去的一个产品开发周期中修复过的所有Bug，找出其中的规律。哪些是个人常犯的错误？哪些是团队犯的错误？团队中的每个成员下次需要注意点什么，才能开发出更好的产品？
？ 为部门开发一些工具。尽管开发人员通常不擅长发现Bug，但他们在开发用于帮助发现Bug的工具方面的能力却是超强的。他们还能开发一些工具用于使过程更加顺畅，比如源代码签入、安装、建造和支持。给源代码插桩或者开发一个好的测试用具，能够大大地促进开发与测试团队之间的关系。当然，你应该先到工具箱网站上去查一查，看看满足你需要的工具是否早已存在了。
？ 讨好项目经理，把他们的设计思想变成原型程序。开发原型程序是个好主意，只是不要在常规代码库上去做。尝试用另一种语言来写，或者至少要有独立的建造。在常规代码库上开发原型程序的最大问题是，项目经理和高层管理者会很自然地认为，�