人月神话读书笔记03

本次阅读第七章 

我过去是怎么做的

在编程之前没有清晰的目标，写到什么就去做什么

这种做法为什么不好

思路不够清晰，导致编程没有逻辑性

如何解决：

7. 为什么巴比伦塔会失败？

关于巴比伦塔的故事：维基百科 Tower of Babel

7.1 巴比伦塔的管理教训

据《创世纪》记载，巴比伦塔是人类继诺亚方舟之后的第二大工程壮举，但巴比伦塔 同时也是第一个彻底失败的工程。 这个故事在很多方面和不同层次都是非常深刻和富有教育意义的。让我们将它仅仅作 为纯粹的工程项目，来看看有什么值得学习的教训。这个项目到底有多好的先决条件？他们 是否有：

1. 清晰的目标？是的，尽管幼稚得近乎不可能。而且，项目早在遇到这个基本的限制 之前，就已经失败了。
2. 人力？非常充足。
3. 材料？在美索不达米亚有着丰富的泥土和柏油沥青。
4. 足够的时间？没有任何时间限制的迹象。
5. 足够的技术？是的，金字塔、锥形的结构本身就是稳定的，可以很好分散压力负载。 对砖石建筑技术，人们有过深刻的研究。同样，项目远在达到技术限制之间，就已经失败了。

那么，既然他们具备了所有的这些条件，为什么项目还会失败呢？他们还缺乏些什么？ 两个方面——交流，以及交流的结果——组织。他们无法相互交谈，从而无法合作。当合作无法进行时，工作陷入了停顿。通过史书的字里行间，我们推测交流的缺乏导致了争辩、沮丧和群体猜忌。很快，部落开始分裂——大家选择了孤立，而不是互相争吵。

7.2 大型编程项目中的交流

现在，其实也是这样的情况。因为左手不知道右手在做什么，所以进度灾难、功能的不合理和系统缺陷纷纷出现。

那么，团队如何进行相互之间的交流沟通呢？通过所有可能的途径。

• 非正式途径 清晰定义小组内部的相互关系和充分利用电话，能鼓励大量的电话沟通，从而达到对 所书写文档的共同理解。
• 会议 常规项目会议。会议中，团队一个接一个地进行简要的技术陈述。这种方式非常有用， 能澄清成百上千的细小误解。
• 工作手册。 在项目的开始阶段，应该准备正式的项目工作手册。理所应当，我们专门用一节来讨论它。

7.3 项目工作手册

项目工作手册是什么？。项目工作手册不是独立的一篇文档，它是对项目必须产出的一系列文档进行 组织的一种结构。

项目所有的文档都必须是该结构的一部分。这包括目的、外部规格说明、接口说明、 技术标准、内部说明和管理备忘录。

为什么需要项目工作手册？。技术说明几乎是必不可少的。如果某人就硬件和软件的某部分，去查看一系 列相关的用户手册。他发现的不仅仅是思路，而且还有能追溯到最早备忘录的许多文字和章 节，这些备忘录对产品提出建议或者解释设计。对于技术作者而言，文章的剪裁粘贴与钢笔 一样有用。

基于上述理由，再加上“未来产品”的质量手册将诞生于“今天产品” 的备忘录，所 以正确的文档结构非常重要。事先将项目工作手册设计好，能保证文档的结构本身是规范的， 而不是杂乱无章的。另外，有了文档结构，后来书写的文字就可以放置在合适的章节中。 使用项目手册的第二个原因是控制信息发布。控制信息发布并不是为了限制信息，而是确保信息能到达所有需要它的人的手中。

7.4 大型编程项目的组织架构

如果项目有 n 个工作人员，则有（n 2 - n）/ 2 个相互交流的接口，有将近 2 n 个必须合作的潜在团队。团队组织的目的是减少不必要交流和合作的数量，因此良好的团队组织是解决上述交流问题的关键措施。 减少交流的方法是人力划分（division of labor）和限定职责范围（specialization of function）。当使用人力划分和职责限定时，树状管理结构所映出对详细交流的需要会相应减少。

事实上，树状组织架构是作为权力和责任的结构出现。其基本原理——管理角色的非重复性——导致了管理结构是树状的。但是交流的结构并未限制得如此严格，树状结构几乎不能用来描述交流沟通，因为交流是通过网状结构进行的。在很多工程活动领域，树状模拟结构不能很精确地用于描述一般团队、特别工作组、委员会，甚至是矩阵结构组织。 让我们考虑一下树状编程队伍，以及要使它行之有效，每棵子树所必须具备的基本要 素。它们是：

1. 任务（a mission）
2. 产品负责人（a producer）
3. 技术主管和结构师（a technical director or architect）
4. 进度（a schedule）
5. 人力的划分（a division of labor）
6. 各部分之间的接口定义（interface definitions among the parts）

所有这些是非常明显和约定俗成的，除了产品负责人和技术主管之间有一些区别。我 们先分析一下两个角色，然后再考虑它们之间的关系。

产品负责人的角色是什么？他组建团队，划分工作及制订进度表。他要求，并一直要 求必要的资源。这意味着他主要的工作是与团队外部，向上和水平地沟通。他建立团队内部 的沟通和报告方式。最后，他确保进度目标的实现，根据环境的变化调整资源和团队的构架。

那么技术主管的角色是什么？他对设计进行构思，识别系统的子部分，指明从外部看 上去的样子，勾画它的内部结构。他提供整个设计的一致性和概念完整性；他控制系统的复 杂程度。当某个技术问题出现时，他提供问题的解决方案，或者根据需要调整系统设计。用 Al Capp 所喜欢的一句谚语，他是“攻坚小组中的独行侠”（inside-man at the skunk works.）。 他的沟通交流在团队中是首要的。他的工作几乎完全是技术性的。

现在可以看到，这两种角色所需要的技能是非常不同的。这些技能可以按不同的方式 进行组合。产品负责人和技术主管所拥有的特殊技能可以用不同方式组合，组合结果控制和 支配了他们之间的关系。团队的搭建必须根据参与的人员来组织，而不是将人员纯粹地按照 - 45 - 理论进行安排。 存在三种可能的关系，它们都在实践中得到了成功的应用。

7.4.1 产品负责人和技术主管是同一个人

这种方式非常容易应用在很小型的队伍中，可能 是三个或六个开发人员。在大型的项目中则不容易得到应用。原因有两个：

• 第一，同时具有 管理技能和技术技能的人很难找到。思考者很少，实干家更少，既是思考者又是实干家的太少了。
• 第二，大型项目中，每个角色都必须全职工作，甚至还要加班。对负责人来说，很难在承担全部管理责任的同时，还能抽出时间进行技术工作。对技术主管来说，很难在保证设 计的概念完整性，没有任何妥协的前提下，担任管理工作。

7.4.2 产品负责人作为总指挥，技术主管充当其左右手

这种方法有一些困难。很难在技术 主管不参与任何管理工作的同时，建立在技术决策上的权威。 显然，产品负责人必须预先声明技术主管的技术权威，在即将出现的绝大部分测试用 例中，他必须支持后者的技术决定。要达到这一点，产品责任人和技术主管必须在基本的技 术理论上具有相似观点；他们必须在主要的技术问题出现之前，私下讨论它们；产品责任人必须对技术主管的技术才能表现出尊重。

这种组合可以使工作很有效。不幸的是它很少被应用。不过，它至少有一个好处，即 项目经理可以使用并不很擅长管理的技术天才来完成工作。

7.4.3 技术主管作为总指挥，产品负责人充当其左右手

这里引用了一个故事来说明此种应用情况，篇幅问题，不做摘录，书籍见：

豆瓣链接

Wikipedia

巴比伦塔可能是第一个工程上的彻底失败，但它不是最后一个。交流和交流的结果——组织，是成功的关键。交流和组织的技能需要管理者仔细考虑，相关经验的积累和能力的 提高同软件技术本身一样重要。