外观
03.画蛇添足、贯彻执行、为什么巴比伦塔会失败？
约 5201 字大约 17 分钟
人月神话项目管理devops个人
2022-06-04
第5章 画蛇添足
如果将制定功能规格说明的责任从开发快速、成本低廉的产品的责任中分离出来，那么有什么样的准则和机制来约束结构师的创造性激情呢？
Part 1 结构师的交互准则和机制
面对估算过高的难题，结构师有两个选择：削减设计或者采用成本更低的实现方法。后者是固有的主观感性反应。此时，结构师是在向开发人员的做事方式提出挑战。想要成功，结构师必须：
★ 牢记是开发人员承担创造性和发明性的实现责任，所以结构师只能建议，而不能支配；
★ 时刻准备着为所指定的说明建议一种实现的方法，同样准备接受其他任何能达到目标的方法；
★ 对上述的建议保持低调和不公开；
★ 准备放弃坚持所作的改进建议。
Part 2 自律 --- 开发第二个系统所带来的后果
结构师如何避免开发第二个系统所引起的后果，从而避免画蛇添足？
① 有意识地关注这个系统的特殊危险
② 运用特别的自我约束准则，来避免那些功能上的过于修饰
③ 根据系统基本理念及目的变更，舍弃一些功能。
项目经理如何避免开发第二个系统所引起的后果，从而避免画蛇添足？
① 至少拥有两个系统以上开发经验结构师的决定
② 保持对特殊诱惑的警觉
③ 可以不断提出正确的问题，确保原则上的概念和目标在详细设计中得到完整的体现
作者总结
5.1 尽早交流和持续沟通能使结构师有较好的成本意识，以及使开发人员获得对设计的信心，并且不会混淆各自的责任分工。
5.2 结构师如何成功地影响实现：
- 牢记是开发人员承担创造性的实现责任；结构师只能提出建议。
- 时刻准备着为所指定的说明建议一种实现的方法，准备接受任何其他可行的方法。
- 对上述的建议保持低调和平静。
- 准备对所建议的改进放弃坚持。
- 听取开发人员在体系结构上改进的建议。
5.3 第二个系统是人们所设计的最危险的系统，通常的倾向是过分地进行设计。
5.4 OS/360 是典型的画蛇添足（second-system effect）的例子。 [Windows NT 似乎是90 年代的例子。 ]
5.5 为功能分配一个字节和微秒的优先权值是一个很有价值的规范化方法。
第6章 贯彻执行
假设一个项目经理已经拥有行事规范、富有经验的结构师和许多编程实现人员，那么，他如何确保每个人听到、理解并实现结构师的决策？对于一个由1000人开发的系统，一个10个结构师的小组如何保持系统概念上的完整性？
Part 1 文档化的规格说明 --- 手册
① 手册是产品的外部规格说明，它描述和规定了用户所见的每一个细节。
② 体系结构设计人员必须为自己描述的任何特性准备一种实现方法，但是他不应该试图支配具体的实现过程。
③ 规格说明的风格必须清晰、完整和准确。
④ 保持文字和产品之间的一致性，则必须由一个或两个人来完成将其结论转换成书面规格说明的工作。
Part 2 形式化定义
① 规格说明应同时包括形式化和记叙性定义两种方式。
② 如果同时具有两种方式，则必须以一种作为标准，另一种作为辅助描述，并照此明确地进行划分。
③ 关于实际使用标准是形式化描述还是叙述性文字这一点而言，使用实现作为形式化定义特别容易引起混淆，特别是在程序化的仿真中。另外，当实现充当标准时，还必须防止对实现的任何修改。
Part 3 直接整合
① 建立模块间接口语法，这项技术是设计被传递参数或共享存储器的声明，并要求编程实现在编译时的一些操作来包含这些声明。
② 如果整个接口仅仅通过符号名称进行引用， 那么需要修改声明的时候， 可以通过增加或插入新变量，或者重新编译受影响的程序。这种方法不需要修改程序内容。
Part 4 会议和大会
① 分成两个级别：周例会和年度大会
② 周例会是每周半天的会议，由所有的结构师，硬件和软件实现人员代表以及市场计划人员参与，由首席系统结构师主持。任何人可以提出问题和修改意见，但是建议书通常是以书面形式在会议之前分发。
③ 这种会议的卓有成效是由于以下几种原因。
(1) 数月内，相同小组 --- 结构师、用户和实现人员---每周交流一次。大家对项目相关的内容比较了解，不需要安排额外时间对人员进行培训。
(2) 上述小组十分睿智和敏锐，深刻理解所面对的问题，并且其与产品密切相关。没有人是“顾问”的角色，每个人都要承担义务。
(3) 当问题出现时，在界线的内部和外部同时寻求解决方案。
(4) 正式的书面建议集中注意力，强制了决策的制定，避免会议稿纪要方式的不一致。
(5) 明确地授予首席结构师决策的权力，避免了妥协和拖延。
Part 5 多重实现
① 多重实现的同时带来了策略上的平等性。不停实现之间严格要求相互兼容。
② 机器和手册之间会往往会在某一天出现不一致，人们通常会忽略手册。
Part 6 电话日志
① 对于存疑的实现人员，应是鼓励他们打电话询问，而不是变猜边工作。
② 由结构师保存电话日志。日志中，他记录了每一个问题和相应的回答。 每周，对若干结构师的日志进行合并，重新整理，并发布给用户和实现人员。
Part 7 产品测试
① 设立测试小组是使设计决策得以贯彻执行的必要手段，同样也是需要尽早着手，与设计同时实施的重要环节。
作者总结
6.1 即使是大型的设计团队，设计结果也必须由一个或两个人来完成，以确保这些决定是一致的。
6.2 必须明确定义体系结构中与先前定义不同的地方，重新定义的详细程度应该与原先的说明一致。
6.3 考虑到精确性，需要形式化的设计定义，同样需要记叙性定义来加深理解。
6.4 必须采用形式化定义和记叙性定义中的一种作为标准，另一种作为辅助措施；它们都可以作为表达的标准。
6.5 设计实现，包括模拟仿真，可以充当一种形式化定义的方法；这种方法有一些严重的缺点。
6.6 直接整合是一种强制推行软件的结构性标准的方法。[硬件上也是如此—考虑内建在 ROM 中的 Mac WIMP 接口。]
6.7 如果起初至少有两种以上的实现，那么（体系结构） 定义会更加整洁，会更加规范。
6.8 允许体系结构师对实现人员的询问做出电话应答解释是非常重要的，并且必须进行日志记录和整理发布。 [电子邮件是一种可选的介质。]
6.9 项目经理最好的朋友就是他每天要面对的敌人——独立的产品测试机构/小组。
第7章 为什么巴比伦塔会失败？
Part 1 巴比伦塔的管理教训
① 具备了所有的这些条件， 为什么项目还会失败呢？他们还缺乏些什么？
两个方面——交流， 以及交流的结果——组织。
Part 2 大型编程项目中的交流
① 团队如何进行相互之间的交流沟通呢？
a.非正式途径
清晰定义小组内部的相互关系和充分利用电话，能鼓励大量的电话沟通，从而达到对所书写文档的共同理解。
b.会议
常规项目会议。会议中，团队一个接一个地进行简要的技术陈述。这种方式非常有用，能澄清成百上千的细小误解。
c.工作手册。
在项目的开始阶段，应该准备正式的项目工作手册。
② 项目工作手册
a.是什么。
（1）项目工作手册不是独立的一篇文档，它是对项目必须产出的一系列文档进行组织的一种结构。
（2）项目所有的文档都必须是该结构的一部分。这包括目的、外部规格说明、接口说明、技术标准、内部说明和管理备忘录。
b.为什么。
（1）技术说明几乎是必不可少的。
如果某人就硬件和软件的某部分，去查看一系列相关的用户手册。
正确的文档结构非常重要。事先将项目工作手册设计好，能保证文档的结构本身是规范的，而不是杂乱无章的。
（2）控制信息发布。
控制信息发布并不是为了限制信息，而是确保信息能到达所有需要它的人的手中。
每个工作人员可以通过标题列表或树状的索引结构来检索是否有他所需要的信息。
c.处理机制。
同许多其它的软件管理问题一样，随着项目规模的扩大，技术备忘录的问题以非线性趋势增长。对结构化工作手册的需要和手册规模上的要求都紧迫了许多。那么，用什么样的机制来处理呢？
- 工作手册的实时更新是非常关键的。
- 文档变更的强调有若干个步骤。
- 理解的问题可以通过持续的文档维护来解决。
- 必须在页面上标记发生改变的文本，例如，使用页边上的竖线标记每行变化的文字。
- 分发的变更页附带独立的总结性文字，对变更的重要性以及批注进行记录
d.现在如何入手？
采用可以直接访问的文件。
（1）在文件中，记录修订日期记录和标记变更标识条。每个用户可以从一个显示终端（打印机太慢了）来查阅。每日维护的变更小结以“后进先出”的方式保存，在一个固定的地方提供访问。
（2）注意工作手册本身没有发生变化。它还是所有项目文档的集合，根据某种经过细致考虑的规则组织在一起。唯一发生改变的地方是分发机制和查询方法。
Part 3 大型编程项目的组织架构
团队组织的目的是减少不必要交流和合作的数量， 因此良好的团队组织是解决上述交流问题的关键措施。
① 减少交流的方法是人力划分和限定职责范围。当使用人力划分和职责限定时，树状管理结构所映出对详细交流的需要会相应减少。
② 树状组织架构是作为权力和责任的结构出现。其基本原理—管理角色的非重复性—导致了管理结构是树状的。
③ 考虑一下树状编程队伍，以及要使它行之有效，每棵子树所必须具备的基本要素。它们是：
1. 任务
2.产品负责人
3. 技术主管和结构师
4. 进度
5. 人力的划分
6. 各部分之间的接口定义
④ 产品负责人的角色是什么？
组建团队，划分工作及制订进度表。一直保障必要的资源。与团队外部，向上和水平地沟通。他建立团队内部的沟通和报告方式。最后，他确保进度目标的实现，根据环境的变化调整资源和团队的构架。
⑤ 技术主管的角色是什么？
对设计进行构思，识别系统的子部分，指明从外部看上去的样子，勾画它的内部结构。提供整个设计的一致性和概念完整性；控制系统的复杂程度。当某个技术问题出现时，提供问题的解决方案，或者根据需要调整系统设计。的沟通交流在团队中是首要的。他的工作几乎完全是技术性的。
⑥ 团队的搭建必须根据参与的人员来组织，存在三种可能的关系，它们都在实践中得到了成功的应用。
（1）产品负责人和技术主管是同一个人。
这种方式非常容易应用在很小型的队伍中。
在大型的项目中则不容易得到应用。原因有两个：
第一，同时具有管理技能和技术技能的人很难找到。思考者很少，实干家更少，思考者－实干家太少了。
第二，大型项目中，每个角色都必须全职工作，甚至还要加班。对负责人来说，很难在承担全部管理责任的同时， 还能抽出时间进行技术工作。对技术主管来说，很难在保证设计的概念完整性，没有任何妥协的前提下，担任管理工作。
（2）产品负责人作为总指挥， 技术主管充当其左右手。
这种方法有一些困难。很难在技术主管不参与任何管理工作的同时，建立在技术决策上的权威。
产品负责人必须预先声明技术主管的技术权威，在即将出现的绝大部分测试用例中，他必须支持后者的技术决定。 要达到这一点，产品责任人和技术主管必须在基本的技术理论上具有相似观点；他们必须在主要的技术问题出现之前，私下讨论它们；产品责任人必须对技术主管的技术才能表现出尊重。这种组合可以使工作很有效。不幸的是它很少被应用。不过，它至少有一个好处，即项目经理可以使用并不很擅长管理的技术天才来完成工作。
（3）技术主管作为总指挥，产品负责人充当其左右手。
我猜测最后一种安排对小型的团队是最好的选择，如同在第 3 章《外科手术队伍》一文中所述。
对于真正大型项目中的一些开发队伍，我认为产品负责人作为管理者是更合适的安排。
⑦ 交流和交流的结果——组织，是成功的关键。交流和组织的技能需要管理者仔细考虑，相关经验的积累和能力的提高同软件技术本身一样重要。
作者总结
7.1 巴比伦塔项目的失败是因为缺乏交流，以及交流的结果—组织。
交流
7.2 因为左手不知道右手在做什么，从而进度灾难、功能的不合理和系统缺陷纷纷出现。由于对其他人的各种假设，团队成员之间的理解开始出现偏差。
7.3 团队应该以尽可能多的方式进行相互之间的交流：非正式、常规项目会议，会上进行简要的技术陈述、共享的正式项目工作手册。以及电子邮件。
项目工作手册
7.4 项目工作手册不是独立的一篇文档，它是对项目必须产生的一系列文档进行组织的一种结构。
7.5 项目所有的文档都必须是该（工作手册）结构的一部分。
7.6 需要尽早和仔细地设计工作手册结构。
7.7 事先制订了良好结构的工作手册，可以将后来书写的文字放置在合适的章节中，并且可以提高产品手册的质量。
7.8 每一个团队成员应该了解所有的材料（工作手册）。[我想说的是，每个团队成员应该能够看到所有材料，网页即可满足要求。]
7.9 实时更新是至关重要的。
7.10 工作手册的使用者应该将注意力集中在上次阅读后的变更，以及关于这些变更重要性的评述。
7.11 OS/360 项目工作手册开始采用的是纸介质，后来换成了微缩胶片。
7.12 今天[即使在 1975 年]，共享的电子手册是能更好达到所有这些目标、更加低廉、更加简单的机制。
7.13 仍然需要用变更条和修订日期[或具备同等功能的方法]来标记文字；仍然需要后进先出（LIFO）的电子化变更小结。
7.14 Parnas 强烈地认为使每个人看到每件事的目标是完全错误的；各个部分应该被封装，从而没有人需要或者允许看到其他部分的内部结构，只需要了解接口。
7.15 Parnas 的建议的确是灾难的处方。 [Parnas 让我认可了该观点，使我彻底地改变了想法。]
组织架构
7.16 团队组织的目标是为了减少必要的交流和协作量。
7.17 为了减少交流，组织结构包括了人力划分（division of labor）和限定职责范围（specialization of function）。
7.18 传统的树状组织结构反映了权力的结构原理——不允许双重领导。
7.19 组织中的交流是网状，而不是树状结构，因而所有的特殊组织机制（往往体现成组织结构图中的虚线部分）都是为了进行调整，以克服树状组织结构中交流缺乏的困难。
7.20 每个子项目具有两个领导角色—产品负责人、 技术主管或结构师。这两个角色的职能有着很大的区别，需要不同的技能。
7.21 两种角色中的任意组合可以是非常有效的：
- 产品负责人和技术主管是同一个人。
- 产品负责人作为总指挥，技术主管充当其左右手。
技术主管作为总指挥，产品负责人充当其左右手。