人月神话.PNG
第六章 贯彻执行（项目团队拥有形式规范、富有经验的结构师和编程人员）
文档化的规格说明－手册，它描述和规定了用户所见的每一个细节；同样的，它也是结构师主要的工作产物。对实现人员而言，修改的阶段化是很重要的－在进度表上应该有带日期的版本信息。
手册不但要描述包括所有界面在内的用户可见的一切，它同时还要描述用户看不见的事物。后者是编程实现人员的工作范畴，而这里他的设计和创造自由是不应该被限制的。体系结构设计人员必须为自己描述任何特性准备一种实现方法，但是他不应该试图支配实现的过程。
规则说明的风格必须清晰、完整和准确。用户常常会单独提到某个定义，所以每条说明都必须重复所有的基本元素，所以所有文字都要相互一致。往往使手册读起来枯燥乏味，但是准确比生动更加重要。思路是大约十个人的想法，但如果想保持文字和产品之间的一致性，则必须由一个或两个人来完成将其结论转换成书面规格说明的工作。而且，将定义书写成文字，必须对很多原先并不是非常重要的问题进行判断，并得出结论。在整个设计中，保证这些看似琐碎的问题处理原则上的一致性，绝不是一件无关紧要的事情。定义了兼容性，描述将达到的目标，列举外观部分，必须在仔细定义规定什么的同时，定义未规定什么。
形式化定义：手册的作者必须注意到自己的思路和语言，达到所需要的准确程度。一种颇具吸引力的做法是使用形式化标记方法以达到精确度。形式化定义是精确的，倾向完整，缺点是不易理解-增强信心。记述性文字可以表达结构性原则，描述阶段上或层次上的结构，并提供实例-容易表达异常和强调对比的关系，而且可以解释原因-内容易于领会和讲授。如果同时使用形式化和记述性定义，则必须以一种作为标准，另一种作为辅助描述，并照此明确进行划分。在规定系统外部功能的同时，几乎所有的形式化定义均会用来描述和体现硬件系统或软件系统的某个设计实现。语法和规则的表达可以不需要具体的设计实现，但是特定的语义和意义通常会通过一段实现该功能的程序来定义-形式化定义仅仅用于外部功能，说明它们是什么。形式化设计是一种形式化定义的方法。
所有定义的问题都可以通过测试解决-使用实现来作为一种定义的方式有一些优点。首先，所有问题都可以通过试验清晰地得到答案，从来不需要争辩和商讨，回答是快捷迅速的。通过定义得出答案，从来不需要争辩和商讨，回答是快捷迅速的。通过定义得出的答案，总是同所要求的一样精确和正确。缺点包括实现可能更加过度地规定了外部功能-无效的语法通常会产生某些结果。作为一种定义，实现体现了过多的内容：它不但描述了系统必须做什么，同时还声明了自己到底做了些什么。使用实现作为形式化定义特别容易混淆。当实现作为标准时，还必须防止对实现的任何修改。
建立模块间接口语法，传递参数或共享存储器声明。数百人在场的大型磋商会议往往需要大规模和非常正式地召集：周例会和年度大会。周例会是每周半天的会议，由所有的结构师，加上软硬件实现人员代表和市场计划人员参与，由首席系统架构师主持。会议中，任何人可以提出问题和修改意见，但是建议书通常以书面形式在会议前分发，重点是创新，而不仅仅是结论。该小组试图发现解决问题的各种方法，然后少数解决方案会被传递给一个或多个结构师，详细记录到书面变更建议说明书中。接着会对详细的变更建议做出决策 -经历几个反复过程，实现人员和用户会仔细地进行考虑，正面和负面的意见都会被很好的描述。如果达成了共识非常好、如果没有则由首席架构师来决定。这需要花费时间，最终所发布的结论是正式和果断的。周例会的决策会给出迅捷的结论，使工作继续开展下去。如果任何人对结果过于不满，可以付诸于项目经理，这种会议的卓有成效是由于：
数月内，相同小组-结构师、用户和实现人员-每周交流一次。因此，大家对项目相关的内容比较了解，不需要安排额外时间对人员进行培训。
小组十分睿智和敏锐，深刻理解所面对的问题，并且与产品密切相关。没有人是“顾问”的角色，每个人都要承担义务。
当问题出现时，在界线的内外部同时寻求解决方案。
正式的书面建议集中了注意力，强制了决策的制定，避免了会议草稿纪要方式的不一致。
明确地授予首席结构师的权力，避免了妥协和拖延。
一些决定可能没有很好地贯彻，一些小事情并没有被参与者真正地接受，其他决定造成了未曾遇到的问题。这些问题，有时周例会并不赞同重新考虑，慢慢积少成多-为解决这些堆积起来的问题，举行年度或半年度大会，典型的年度大会会持续两周。出席人员包括体系结构小组和编程人员、实现人员的结构代表，同时包括编程经理、市场实现人员，由项目经理主持。典型的议程包括大约200个条目，大多数条目规模很小，它们列举在会议室周围的图表上，每个不同的声音都有机会得到表达，然后制定出决策。每天早晨，会议参与人员会在座位上发现更新了的手册说明，记录了前一天的各项决定。这些“收获的节日”不仅可以解决决策上的问题，而且使决策更容易被接受。每个人都在倾听，每个人都在参与，每个人对复杂约束和决策之间的互相关系有了更加透彻的理解。
无论规格说明已经多么精确，还是会出现无数结构理解和理解方面的问题。对于存在疑问的实现人员，应鼓励他们打电话询问相应的结构师，而不是一边自行猜测一边工作，这是一项很基本的措施 的（他们需要认识的是，上述问题的答案必须是可以告知每个人的权威性结论）。一种有用的机制是由结构师保存电话日志，日志中记录每个问题和相应的回答。每周对若干结构师的日志进行合并，重新整理，并分发给用户和实现人员-权威性结论。
产品测试小组是顾客的代言人，专门寻找缺陷。该小组根据规格说明检查机器和程序，充当麻烦的代言人，查明每个可能的缺陷和互相矛盾的地方。细心的产品测试人员总会发现一些没有贯彻执行、设计决策没有正确理解或准确实现的地方。因此，设立测试小组使设计决策得以贯彻执行的必要手段，同样也需要尽早着手，与设计同时实施。
第七章 为什么巴比伦塔会失败
巴比伦塔项目到底有多好的先决条件？他们是否有：清晰的目标？人力？材料？足够的时间？足够的技术？这些都有，为什么还会失败呢？他们还缺乏些什么？两个方面-交流，以及交流的结果-组织。他们无法互相交谈，从而无法合作。合作无法进行时，工作陷入了停顿。
团队如何进行互相之间的交流沟通呢？通过所有可能的途径：非正式途径（清晰定义小组内部的互相关系和充分利用电话，能鼓励大量的电话沟通，从而达到对所书写文档的共同理解）、会议（常规项目会议，团队一个接一个地进行简要的技术陈述-澄清成百上千的细小错误）、工作手册（不是一篇文档，它是对项目必须产出的一系列文档进行组织的一种结构）。
项目所有的文档都必须是该结构的一部分。这包括目的、外部规格说明、接口说明、技术标准、内部说明和管理备忘录。需要正确的文档结构：事先将项目手册设计好，能保证文档本身是规范的，而不是杂乱无章的。有了文档结构，后来书写的文字就可以放置在合适的章节里；使用项目手册第二个原因是控制信息发布，并不是为限制信息，而是确保信息能到达所有需要它的人的手中。
项目手册的第一步是对所有的备忘录编号，从而每个工作人员可以通过标题列表来检索是否有他所需要的信息-也可以使用树状的索引结构。而且如果需要的话，可以使用树结构中的子树来维护发布列表。
工作手册每个办公室都有，实时更新，合页夹的方式-微缩胶片，作为文字工作手册的补充。
当编程人员仅了解自己负责的部分，而不是整个系统开发细节时，工作效率最高，此方法的先决条件是精确和完整地定义所有接口。一个好的信息系统不但能暴露接口错误，还能有助于改正错误。
大型编程项目的组织架构：团队组织的目的是减少所需的交流和合作的数量，因此良好的团队组织是解决上述问题的关键措施。减少交流的方法是人力划分和限定职责范围。编程队伍必须具备的基本要素：任务、产品负责人、技术主管或结构师、进度、人力划分、各部分之间接口定义。团队的搭配必须根据参与的人员来组织，而不是将人员纯粹地按照理论进行安排。
产品负责人组建团队，划分工作及制定进度表。争取并一直保证必要的资源。这意味着他主要的工作是与团队外部进行向上的沟通和水平的沟通。他建立团队内部的沟通和报告方式，他确保进度目标的实现，根据环境变化调整资源和团队架构。
技术主管对设计进行构思，识别系统的子部分，指明从外部看上去的样子，勾画它的内部结构。他提供整个设计的一致性和概念完整性；他控制系统的复杂程度。当某个技术问题出现时，他提供解决问题的解决方案，或者根据需要调整系统设计-攻坚小组中的独行侠。他的沟通交流在团队中是首要的，他的工作几乎完全是技术性的，沟通能力强。
产品负责人和技术主管是同一个人的实践，一般3-6个开发人员。大型团队不容易，同时具有管理技能和技术技能的人很难找到-思考者很少，实干家更少；大型团队每个角色都必须全职工作，甚至还要抽出时间进行技术工作。
产品负责人作为总指挥，技术主管充当其左右手-技术主管不参与任何管理工作不可能，建立在其技术权威。产品负责人必须预先声明技术主管的技术权威，他们必须在主要的技术问题出现之前，私下先讨论这些问题：产品责任人必须对技术主管的技术才能表现出尊重。一些技巧，微妙状态特征暗示体现主管微信。
技术主管作为总指挥，产品负责人充当其左右手。作者更倾向于产品负责人作为管理者更合适的安排。交流和交流的结果-组织，是成功的关键。交流和组织的技能需要管理者仔细考虑，相关经验的积累和能力的提高同软件技术本身一样重要。
第八章 胸有成竹
编码大约只占问题的1/6左右，编码估计或者比率的错误可能会导致不合理的荒谬结果。计划、编制文档、测试、系统集成和培训的时间必须被考虑在内。构建独立小型程序的数据并不适合于编程系统产品。工作量＝常数*指令的数量1.5（工作量是规模的幂函数），保存所使用时间的日志-仅用50%的工作周来进行实际的编程和调试，其余的时间包括机器的宕机时间、高优先级无关琐碎工作、会议、文字工作、公司业务、疾病、事假等。项目估算对每个人年的技术工作时间数量做出了不现实的假设。
汇编：控制程序的生产率大约600-800（经过调试的指令）/人年、语言翻译小组生产率大约2000-3000/人年，包括小组计划、代码构件测试、系统测试和一些支持性活动。生产率会根据任务本身复杂度和困难程度表现出显著差异：编译器复杂度是批处理程序的3倍，操作系统的复杂度是编译器的3倍。系统中每个语句对应的手写代码的3-5个指令！这意味着两个重要的结论：对常用编程语句而言，生产率似乎是固定的。这个固定的生产率包括编程中需要注释，并可能存在错误的情况；使用适当的高级语言，编程的生产率可以提高5倍。
第九章 削足适履
作为成本的程序空间，应该从整体上进行评价，没有人可以自始至终提倡更紧密的软硬件设计集成的同时，又仅仅就规模本身对软件系统提出批评。规模是软件系统产品用户成本中的一个组成部分，开发人员必须设置规模的目标，控制规模，考虑减少规模的方法，不必要的规模是不可取的。
对项目经理而言，规模控制既是技术工作的一部分，也是管理工作的一部分。他必须研究用户和用户需求，以设置待开发系统的规模。由于规模-速度权衡方案的结果在很大范围内变化，规模目标的设置是一件颇具技巧的事情，需要对每个可用方案有深刻的了解。聪明的项目经理还会给自己预留一些空间，在工作推行时分配。即使所有工作都完成得相当仔细，我们依然从中得到一些痛苦的教训。
第一个教训，仅对核心程序设定规模目标是不够的，必须把所有方面规模都编入预算-内存或磁盘使用。在为每个单元设立核心规模的同时，我们没有同时设置访问的预算-单元核心未达到要求，会分解成覆盖模块，增加了程序的整体规模，并降低了运行速度。
第二个教训，每个模块分配功能前，已编制预算。导致任何在规模上碰到问题的程序员，会检查已经的代码可否推给其他人。在指名模块有多大的同时，确切定义模块的功能。
第三个教训，局部优化导向和缺乏沟通是最大的危险。在整个实现过程中，系统结构师必须保持持续的警觉，确保连贯的系统完整性。除了监督机制外，是实现人员自身的态度问题-培养开发人员从系统整体出发、面向用户的态度是软件编程管理人员最重要的职能。
空间的预算和控制并不能使程序规模减少，为实现这一目标，需要一些创造性和技能。其中一个技巧是用功能交换尺寸：速度不变，更多功能需要更多空间，设计人员必须决定用户可选项目的粗细程度。内存受限的后果是即使最精密的功能模块，它的适用范围也难以得到推广。第二个技能是考虑空间-时间的折衷：对于给定功能，空间越多，速度越快。
项目经理可以做两件事来帮助他的团队取得良好的空间-时间折衷。一是确保他们在编程技能上得到培训，而不仅仅是依赖他们自己的才能和先前的经验-特别是使用新语言或者新机器时，熟练使用往往需要快速学习和经验的广泛共享，也许它应该伴随新技术特别的奖励或者表扬。二是认识到编程需要技术积累，需要开发很多公共单元构件-每个项目要从能用于队列、搜索、散列和排序的例程或者宏库。对于每项功能，库至少应该有两个程序实现：运行速度较快和短小精炼的。上述的公共库开发是一件重要的实现工作，它可以与系统设计工作并行进行。
数据的表现形式是编程的根本-精湛的技艺出自创造，精炼、充分和快速的程序都是如此。技艺改进的结果往往是战略上的突破，不仅仅是技巧上的提高，比如新的算法。战略上突破通常来自数据或表的重新表达。由于缺乏空间而绞尽脑汁的编程人员，常常能通过从自己的代码中挣脱出来，回顾、分析实际情况，仔细思考程序的数据，最终获得非常好的结果。实际上，数据的表现形式是编程的根本。
第十章 提纲挈领
每份文档的准备工作是集中考虑，并使各种讨论意见明朗化的主要时刻。如果不是这样，项目往往会处于无休止的混乱状态，文档的跟踪维护是项目监督和预警的机制。文档本身可以作为检查列表、状态控制，也可以作为汇报基础。
如果要制造一台机器，哪些是关键的文档？
目标：定义待满足的目标和需要，定义迫切需要的资源、约束和优先级；
技术说明：计算机手册加性能规格说明，它是在计划新产品时第一个产生，并且最后完成的文档。
进度
预算：不仅仅是约束，预算的存在会迫使技术决策的制定。否则技术决策很容易被忽略
组织结构图
工作空间的分配
报价、预测、价格：这三个因素互相牵制，决定了项目的成败。为了进行市场预测，首先需要制定产品性能说明和确定假设的价格。价格vs预测值，提高性能和支持更高的市场预测-成本必须降低以获得更低的报价，这个循环的压力常常是激励市场人员和工程师工作的最佳动力。
大学科系的文档：目标、课程描述、学位要求、研究报告（申请基金需要计划）、课程表和课程安排、预算、教室分配、教师和研究生助手的分配，任何管理任务关注焦点都是时间、地点、人员、项目内容和资金。
不论项目的规模大小，项目经理聪明的做法都是：首先立刻正式生成若干正式的小文档，以作为自己的数据基础，然后再要求和其他经理类似的文档。标杆内容如下：
内容：目标。定义待完成的目标、迫切需要的资源、约束和优先级
内容：产品技术说明。以建议书开始，以用户手册和内部文档结束。速度和空间说明是关键的部分
时间：进度
资金：预算
地点：工作空间分配
人员：组织图
为什么要有正式的文档？第一，书面记录决策是必要的-只有记录下来，分歧才会明朗，矛盾才会突出-上百次细小决定答疑解惑。第二，沟通渠道，许多经理普遍认可的策略，完全不为团队成员认知，项目经理的基本职责是使每个人都向着相同的方向前进，主要职责是沟通而不是决定。最后，文档可以作为基础数据和检查列表，通过周期性回顾，他能清楚项目所处的状态，以及哪些重点需要进行更改和调整。
作者不太同意完全信息管理系统，计算机输入查询就会有结果。一个原因是只有一小部分管理人员的时间-可能只有20%，用来从自己头脑外部获取信息。其他工作是沟通：倾听、报告、讲授、规劝、讨论和鼓励。不过，对于基于数据的部分，少数关键文档是至关重要的，可以满足绝大多数需要。项目经理的任务是制定计划，并实现计划。但只有书面计划是精确和可以沟通的。计划中包括了时间、地点、人员、项目内容和资金。 通过一开始就遵循文档开展工作，项目经理更清晰和快速地设定自己的方向-将文档作为工具友好地利用起来。
网友评论