[人月神话]读书笔记4--项目中的交流沟通&&项目估算

为什么巴比伦塔会失败？（Why Did the Tower of Babel Fail）

巴比伦塔是人类继诺亚方舟之后第二大工程壮举，但巴比伦塔同时也是第一个彻底失败的工程。
巴比伦塔失败的原因有两个方面：交流，以及交流的结果——组织。他们无法相互交谈，从而无法合作。当合作无法进行时，工作陷入了停顿。

□大型编程项目中的交流
 现在其实也是这样的情况。因为左手不知道右手在做什么，所以进度灾难，功能的不合理和系统缺陷纷纷出现。

　1，非正式途径
　清晰定义小组内部的相互关系和充分利用电话，能鼓励大量的电话沟通，从而达到对所书写文档的共同理解。

  2，会议
  常规项目会议。会议中，团队一个接一个地进行简要的技术陈述。这种方式非常有用，能澄清成百上千的细小误解。

  3，工作手册。
  在项目的开始阶段，应该准备正式的项目工作手册。技术说明必不可少的两个原因：备忘录功能，对产品提出建议或者解释设计。第二是控制信息发布。控制信息发布并不是为了限制信息，而是确保信息到达所有需要他的人手中。

□项目工作手册
　项目工作手册不是独立的一篇文档，它是对项目必须产出的一系列文档进行组织的一种结构。
　包括目的、外部规格说明、接口说明、技术标准、内部说明和管理备忘录。
  “未来产品”的质量手册将诞生于“今天产品” 的备忘录
  使用项目手册的第二个原因是控制信息发布。控制信息发布并不是为了限制信息，而是确保信息能到达所有需要它的人的手中。

　编程人员仅了解自己负责的部分，而不是整个系统的开发细节时，工作效率最高。这种方法的先决条件是精确和完整地定义所有接口。这的确是一个彻底的解决方法。如果处理得好，的确是能解决很多灾难。一个好的信息系统不但能暴露接口错误，还能有助于改正错误。

□大型编程项目的组织架构
　如果项目有n个工作人员，则有（n2 - n）/ 2个相互交流的接口，有将近2n个必须合作的潜在团队。团队组织的目的是减少不必要交流和合作的数量。因此良好的团队组织是解决上述交流问题的关键措施。

　减少交流的方法是人力划分（division of labor）和限定职责范围（specialization of function）。
　树状组织架构是作为权力和责任的结构出现。其基本原理——管理角色的非重复性——导致了管理结构是树状的。但是交流的结构并未限制得如此严格，树状结构几乎不能用来描述交流沟通，因为交流是通过网状结构进行的。
　每棵子树所必须具备的基本要素。
　1. 任务（a mission）
　2. 产品负责人（a producer）
　　他组建团队，划分工作及制订进度表。他要求，并一直要求必要的资源。这意味着他主要的工作是与团队外部，向上和水平地沟通。
　3. 技术主管和结构师（a technical director or architect）
    他对设计进行构思，识别系统的子部分，指明外部看上去的样子，勾画它的内部结构。他提供整个设计的一致性和概念完整性；他控制系统的复杂程度。当某个技术问题出现时，他提供问题的解决方案，或者根据需要调整系统设计。
　　他是“攻坚小组中的独行侠”（inside-man at the skunk works.）。他的沟通交流在团队中是首要的。他的工作几乎完全是技术性的。
　4. 进度（a schedule）
　5. 人力的划分（a division of labor）
　6. 各部分之间的接口定义（interface definitions among the parts）
　
　一、产品负责人和技术主管是同一个人。
　　非常容易应用在很小型的队伍中，可能是三个或六个开发人员。
　二、产品负责人作为总指挥，技术主管充当其左右手。
　　很难在技术主管不参与任何管理工作的同时，建立在技术决策上的权威。产品负责人必须预先声明技术主管的技术权威。产品责任人必须对技术主管的技术才能表现出尊重。项目经理可以使用并不很擅长管理的技术天才来完成工作。
　三、技术主管作为总指挥，产品负责人充当其左右手
　　

　交流和交流的结果——组织，是成功的关键。交流和组织的技能需要管理者仔细考虑，相关经验的积累和能力的提高同软件技术本身一样重要。

胸有成竹（Calling the Shot）

仅仅通过对编码部分的估计，然后应用上述比率，是无法得到对整个任务的估计的。编码大约只占了问题的六分之一左右，编码估计或者比率的错误可能会导致不合理的荒谬结果。小型项目数据的外推是没有意义的。就好像把100码短跑记录外推，得出人类可以在3分钟之内跑完1英里的结论一样。工作量是规模的幂函数。
工作量=（常数）×（指令的数量）1.5

□Portman的数据
他发现他的编程队伍落后进度大约1/2，每项工作花费的时间大约是估计的两倍。这些估计通常是非常仔细地，由很多富有经验的团队完成。估算失误的原因主要有：机器的当机时间，高优先级的无关琐碎工作，会议，文字工作，公司业务，疾病，事假等。
琐碎的工作占多少时间要事先确认好。项目估算不能对每个人年的技术工作时间数量做出不现实的假设。

□Aron的数据
他根据程序员（和系统部分）之间的交互划分这些系统，得到了如下的生产率：
非常少的交互 10,000指令每人年
少量的交互   5,000
较多的交互   1,500

□OS/360的数据
  生产率会根据任务本身复杂度和困难程度表现出显著差异。在复杂程度估计这片“沼泽”上的指导原则是：编译器的复杂度是批处理程序的三倍，操作系统复杂度是编译器的三倍。

□Corbato的数据
对常用编程语句而言。生产率似乎是固定的。这个固定的生产率包括了编程中需要注释，并可能存在错误的情况.
使用适当的高级语言，编程的生产率可以提高5倍。