画蛇添足(The Second-System Effect)
如果将制订功能规格说明的责任从开发快速,成本低廉的产品的责任中分离出来,那么有什么样的准则和机制来约束结构师的创造性热情呢?答案是结构师和建筑人员之间彻底仔细和谐的交流。
□结构师的交互准则和机制
实际情况中,尽早交流和持续沟通能使结构师有较好的成本意识,以及使开发人员获得对设计的信心,并且不会混淆各自的责任分工。
面对估算过高的难题,结构师有两个选择:削减设计或者建议成本更低的实现方法。--挑战估算的成果。
成本更低的实现方法:结构师是在向开发人员的做事方式提出挑战。想要成功,结构师必须
1)牢记是开发人员承担创造性和发明性的实现责任,所以结构师只能建议,而不能支配
2)时刻准备着为所指定的说明建议一种实现的方法,同样准备接受其他任何能达到目标的方法
3) 对上述的建议保持低调和平静
4) 准备放弃坚持所作的改进建议
一般开发人员会反对体系结构上的修改建议。通常他是对的——当正在实现产品时,某些特性的修改会造成意料不到的成本开销。
□自律——开发第二个系统所带来的后果
在设计第一个项目时,会面对不断产生的装饰和润色功能。这些功能都被搁置在一边,作为下一个项目的内容。
第二个系统是设计师们所设计的最危险的系统,一种普遍倾向是过分地设计第二个系统。向系统添加很多修饰功能和想法。
开发第二个系统所引起的后果(second-system effect)与纯粹的功能修饰和增强明显不同,也就是说存在对某些技术进行细化、精炼的趋势。
结构师如何避免画蛇添足——开发第二个系统所引起的后果(second-system effect)?
是的,他无法跳过二次系统。但他可以有意识关注那些系统的特殊危险,运用特别的自我约束准则,来避免那些功能上的修饰。根据系统基本理念及目的变更,舍弃一些功能。
一个可以开阔结构师眼界的准则是为每个小功能分配一个值:每次改进,功能x不超过m字节的内存和n微秒。这些值会在一开始作为决策的向导,在物理实现期间充当指南和对所有人的警示。
项目经理如何避免画蛇添足(second-system effect)?
他必须坚持至少拥有两个系统以上开发经验结构师的决定。同时,保持对特殊诱惑的警觉。他可以不断提出正确的问题,确保原则上的概念和目标在详细设计中得到完整的体现。
贯彻执行(Passing the Word)
□文档化的规格说明——手册
手册是产品的外部规格说明,它描述和规定了用户所见的每一个细节。同样的它也是结构师主要的工作产物。
手册不但要描述包括所有界面在内的用户可见的一切,它同时还要避免描述用户看不见的事物。后者是编程实现人员的工作范畴,而实现人员的设计和创造是不应该被限制的。体系结构设计人员必须为自己描述的任何特征准备一种实现方法,但是他不应该试图支配具体的实现过程。
规格说明的风格必须清晰完整和准确。用户常常会单独提到某个定义,所以每条说明都必须重复所有的基本要素,所以所有文字都要相互一致。这往往使手册读起来枯燥乏味,但是精确比生动更加重要。
如果想保持文字和产品之间的一致性,则必须由一个或两个人来完成将其结论转换成书面规格说明的工作。
对于在整个设计中,保证这些看似琐碎的问题处理原则上的一致性,决不是一件无关紧要的事情。
□形式化定义
形式化定义是精确的,它们倾向于更加完整;差异得更加明显,可以更快地完成。但是形式化定义的缺点是不易理解。
记叙性文字则可以显示结构性的原则,描述阶段上或层次上的结构,以及提供例子。它可以很容易地表达异常和强调对比的关系它可以解释原因。
将来的规格说明同时包括形式化和记叙性定义两种方式。但必须以一种作为标准,另一种作为辅助描述,并照此明确地进行划分。
□会议和大会
我们把会议分成两个级别:周例会和年度大会--这实际上是一种非常有效的方式。
周例会是每周半天的会议,由所有的结构师,加上硬件和软件实现人员代表和市场计划人员参与,由首席系统结构师主持。
该会议重点是创新,而不仅仅是结论。该小组试图发现解决问题的新方法,然后少数解决方案会被传递给一个和几个结构师,详细地记录到书面的变更建议说明书中。
接着会对详细的变更建议做出决策。这会经历几个反复过程,实现人员和用户会仔细地进行考虑,正面和负面的意见都会被很好地描述。如果达成了共识,非常好;如果没有,则由首席结构师来决定。
周例会的决策会给出迅捷的结论,允许工作继续进行。如果任何人对结果过于不高兴,可以立刻诉诸于项目经理。
随着时间的推移,一些决定没有很好地贯彻,一些小事情并没有被某个参与者真正地接受,其他决定造成了未曾遇到的问题。对于这些问题,有时周例会没有重新考虑,慢慢地,很多小要求,公开问题或者不愉快会堆积起来。为解决这些堆积起来的问题,我们会举行年度大会,典型的年度大会会持续两周。
□多重实现
机器和手册之间往往会在某一天出现不一致,人们通常会忽略手册。因为与机器相比,手册更容易改动,并且成本更低。
当存在多重实现时,情况就不是这样。这时,如实地遵从手册更新机器所造成的延迟和成本的消耗,比根据机器调整手册要低。
□电话日志
一种有用的机制是由结构师保存电话日志。日志中,他记录了每一个问题和相应的回答。每周,对若干结构师的日志进行合并,重新整理,并发布给用户和实现人员。这种机制很不正式,但非常快捷和易于理解。
□产品测试
在最后的分析中,用户是独立的监督人员。在残酷的现实使用环境中,每个细微缺陷都将无从遁形。产品-测试小组则是顾客的代理人,专门寻找缺陷。
细心的产品测试人员总会发现一些没有贯彻执行、设计决策没有正确理解或准确实现的地方。出于这方面的原因,设立测试小组是使设计决策得以贯彻执行的必要手段,同样也是需要尽早着手,与设计同时实施的重要环节。