第3章
根除低下的效率
2001年7月1日：“迟到的规范书：生活现实或先天不足”
正如我在第2章的“精益：比五香熏牛肉还好”栏目中所说的那样，浪费和罪恶在工作中常常相依相伴。关于这一点，没什么比组织的沟通（本章的几个栏目都会涉及这个话题）以及项目之间的自由时间的合理使用来得更为明显。这些领域影响的不仅仅是个人，而是整个团队。因此，它们的影响也是成倍于其他领域的影响。
在我的恐怖字典中，规范文档（规范书）和会议始终占据着特殊的位置。我想可能是因为工程师花了太多的时间在会议上，而且常常还是在讨论规范书的原因吧。尽管我很希望这两样东西在我们熟知的世界中消失，但它们之所以存在必定还是有它们的用途的。我们能做的，是要关注那个真实的用途，而把其他多余的东西统统抛弃。
在这一章中，介绍了一些消除无谓的低效率的策略。第一个栏目解决规范文档临阵变更问题；第二个栏目解决了项目之间的空闲时间的合理使用问题；第三个栏目着重讲的是如何减少对会议的厌倦感；第四个栏目尝试彻底取消规范文档；第五个栏目试图尽量缩简规范文档；第六个栏目分析分布式开发；第七个栏目论证如何能正确地优化团队协作；第八个栏目论证如何利用检查列表及单片流方法进行过程改进；最后一个栏目主张当机立断，即使当时情况不明。
其他栏目对团队间沟通进行了大量的讨论——从跨团队协商到处理非技术性问题，无所不谈。另外还有一些讨论个人可以采取的提升自身能力的措施。但这些篇章对于团队该怎么做才能充分利用有限的时间这个问题的核心进行了充分的剖析。
——Eric
2001年7月1日：“迟到的规范书：生活现实或先天不足”
你已经达到了“编码完成”（Code Complete）的阶段，你正在全力修复Bug，这时候看看你的邮箱里收到了什么？啊，太有趣了，居然是一份新的规范书！把它一脚踹开，如何？请稍等，这可是以前的规范书不小心遗漏掉的一个关键功能，或者像我们常说的那样，“代码本身就是规范书。”
作者注：编码完成（Code Complete），是指开发者认为对于某个功能所有必要的实现代码都已经签入到源代码控制系统的一种状态。通常这只是一个主观判断，而更好的做法实际上应该基于质量标准来度量（那时候经常称为Feature Complete，即功能完成）。
可以想象，测试人员被激怒了。因为他们没有及时拿到规范书，并且他们觉得“他们被排除在了项目开发周期之外”。实在太晚了！代码的表现跟规范书不符，他们也没有对它进行测试。开发人员也感到焦躁不安，因为他们原以为功能已经完成了，但实际上测试人员却在疯狂抱怨他们实现的是一个“错误”的东西，这将导致大量的返工。更糟糕的是，开发人员由于编写了不合规范的功能而被揪住尾巴。但还是有更让人开心的，人们开始讨论这个新的规范文档，找出漏洞，进行修改，而最重要的是必要时将不稳定的代码丢进坟墓。
对于每次变更，搅动，搅动，搅动
也许在极端情况下，变更还不止一次。但这的确有可能发生。即使变更没有那么晚，规范书常常也是不完整的，或者在尚未被开发人员及时复审和检查之前就匆忙交付开发了。
结果怎么样呢？搅动代码，一次又一次地更改以前的实现。开发人员开始编码的时间太早了！规范书本身就有问题，因此代码自然也有问题。当有人指出这些问题的时候，特别会议召开了，但有人被遗漏了，因而缺席了这个会议，代码返工重写之后，那个被遗漏的人发现了其他地方的错误，于是需要召开更多的特别会议，就这样周而复始、永无宁日。
有什么办法可以解决这个问题呢？有些人可能会说：“项目经理是人渣，应该缠着他，直到他把工作做好。”这听起来有点残酷，哪怕是我也有这样的感觉。规范书来得太晚，这是生活的现实，问题在于你处理它的方式。我见到过有如下一些不同的方法。
作者注：我能想象，一些极限编程爱好者在那边嚷嚷了：“给他们一个房间！”（一个团队房间）。我在后面的一个栏目——“停止写规范书，跟功能小组呆在一起”，也会谈到这个观点。然而，微软是一个相当多样化的环境。不是每个团队都能呆在同一个地方的，文档通常是解决团队之间的相互依赖问题的必要手段。因此，也并不是一个解决方案能够解决所有的问题。
走廊会议
第一种方法是走廊会议。当一个开发人员发现手头的规范书存在漏洞，这时候项目经理正好路过，于是一个走廊会议就开始了，一些问题通过这种方式得到了解决。那个开发人员很开心地回到他自己的座位，想着他终于搞清楚了接下去该做什么。那个项目经理也回到了他的办公室，想着开发人员写出来的代码肯定能够反映他真正想要的东西。也许他们在想同一件事情，也许不是。也许测试和实施人员会同意他们的解决方案，也许不会。也许他们方方面面都考虑到了，也许他们不曾做到。也许这是最好的方式去处理变更，也许猴子会冲出我的……好吧，至少你知道了有这种方法。
委员会议
第二种方法是委员会议。对于这种会议，不同的团队有不同的称呼，但它主要是用于讨论规范书变更的主管级会议。通常这种会议会定期召开，各个主管形成一个组织，他们聚在一起讨论规范书上的漏洞或者问题，并且以组织的名义寻找解决方案。主管的项目经理记录会议结果，并且发邮件告知整个团队。
这种方法的优点是，委员会议把该包含的人都包含了进来，达成了最终决议，记录在档，并且拿这些最终决议跟团队沟通。缺点是，委员会议也是可怕的噩梦。它们通常比较冗长、令人厌烦、使人筋疲力尽。它们占用了大量的关键资源，阻碍了工作进展，成为了最要命的一种瓶颈——难以自拔，永无宁日。
规范书变更请求
我最喜欢的方法是“规范书变更请求”（Spec Change Request，SCR），它还有一个对等的名字叫“设计变更请求”（Design Change Request，DCR）。这种方法是委员会议和走廊会议的组合，同时带有一些关键的改进。假设你现在想去改变规范书或者给规范书增加新的内容，你的这个想法可能是你自己想出来的，也可能源于一次走廊对话，也可能受到了一次主管会议的启发。
不管你是项目经理、开发、测试或实施人员，你都可以把你的想法写到Email中去，并且Email的标题定为“SCR:<受影响的规范书><变更的简短描述>”。在Email结尾的地方，你用粗体字写下这么一句话，“除非有人强烈反对，否则这就是最新采纳的规范书。”然后，你把这封Email发给最直接受这个变更影响的项目经理、开发、测试和实施人员。几天之后，当你根据他们的建议做完了必要的修改，你就可以把你的SCR发给团队中剩下的所有人，并且把它跟其他SCR一起放到RAID中或者一个公共目录中。
这里的关键是，规范书的变更现在文档化了，并且得到了相关人员的复审，而且不会阻碍工作的进展。偶有反对的意见，不会有很多。开发人员在任何时候都可以继续工作，以遭遇反对的风险换取时间。典型情况下，开发人员会一直等待，直到SCR经过了初始的几次修改后发给团队全体成员的时候才动手做。
预防是最好的治疗
当然，最理想的是规范书从一开始就不会迟到，至少你不能被它蒙蔽。这里就用得着TIME图表了。在TIME图表中，第一份规范书展示了对整个项目的设计。它不是简单的需求文档，也不是数个小型规范书的集合，而是项目的一个高级规范书，很像是开发主管写的那种高级架构文档。这个规范书应该展示项目将具有的功能和用户界面，以及它们怎样在一起协作，而把细节留给以后的规范书。所有后来的规范书和功能都必须参考这个高级规范书。
这样的话，开发、测试和实施人员就可以制订计划去说明未来所有的功能了。他们能够生产出集成得更好的产品，使用户体验更加流畅。项目经理也可以使用第一份规范书去安排剩下的其他规范书，先做优先级高的，而不必担心遗漏什么东西或者做出让别人吃惊的事情来。这种想法终究使TIME产生了（难以抗拒）。
作者注：TIME（Totally Inclusive Mutually Exclusive）图表是由Donald Wood首先提出的，但它从未像我的同事Rick Andrews最初预期的那样流行过。然而，微软现在的价值主张、远景文档、跨产品案例和匠心独具的设计原型都能达到同样的目的。
扫一扫
127
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
