查字典图书网
查字典图书网
本章内容: 2001年7月1日:“迟到的规范书:生活现实或先天不足” 2002年6月1日:“闲置人手” 2004年6月1日:“我们开会的时候” 2006年7月1日:“停止写规范书,跟功能小组呆在一起” 2007年2月1日:“糟糕的规范书:该指责谁?” 正如我在第2章的“精益:比帕斯雀牛肉还好”栏目中所说的那样,浪费和灾难在工作中常常相依相伴。关于这一点,没什么比组织的沟通(本章的几个栏目都会涉及这个话题),以及项目之间的自由时间的合理使用来得更为明显。这些领域影响的不仅仅是个人,而且是整个团队。因此,它们的影响也是成倍于其他领域的影响。 在我的恐怖字典中,规格说明文档(规范书)和会议始终占据着特殊的位置。我想可能是因为工程师花了太多的时间在会议上,而且常常还是在讨论规范书的原因吧。尽管我很希望这两样东西在我们熟知的世界中消失,但它们之所以存在必定还是有它们的用途的。我们能做的,是要关注那个真实的用途,而把其他多余的东西统统抛弃。 在这一章中,I. M. Wright介绍了一些策略去消除常见的低下效率。第一个栏目谈到了最后时刻的规范书变更。第二个栏目解决了项目之间的空闲时间的合理使用问题。第三个栏目聚焦在如何尽力消除会议的弊病。最后两个栏目竭力想彻底抛弃规范书,如果那不可行,至少也要让规范书短小精悍一点。 其他栏目在组织沟通方面会有更加充分的论述——从跨团队协商到跟非技术人员交流的方方面面。那些栏目还介绍了“个人”可以采取的改进措施。但本章这些栏目重在讲述“组织”能够采取的措施,以便最好地使用它们有限的时间。 ——Eric 2001年7月1日:“迟到的规范书:生活现实或先天不足” 你已经达到了“编码完成”(Code Compete)的阶段,你正在全力修复Bug,这时候看看你的邮箱里收到了什么?啊,太有趣了,居然是一份新的规范书!把它一脚揣开,如何?请稍等,这可是以前的规范书不小心遗漏掉的一个关键功能,或者像我们常说的那样,“代码本身就是规范书。” 作者注:编码完成(Code Compete),是指开发者认为对于某个功能所有必要的实现代码都已经签入到源代码控制系统的一种状态。通常这只是一个主观判断,而更好的做法实际上应该基于质量标准来度量(那时候经常称作为“Feature Compete”,即“功能完成”)。 可以想象,测试人员被激怒了。因为他们没有及时拿到规范书,并且他们觉得“被排除在了项目开发周期之外”。实在太晚了!代码的表现跟规范书不符,但他们还没测试过。开发人员也感到焦躁不安,因为他们原以为功能已经完成了,但实际上测试人员却在疯狂抱怨他们实现的是一个“错误”的东西,这将导致大量的返工。更糟糕的是,开发人员当初实现的功能根本就没有在文档中被正确定义好。于是,大家对新的规范书展开争论,发现漏洞,然后再更改,搅动实现代码,直到项目失败——而这时候本该是产品的稳定化阶段。这下大家都“开心”了!