人月神话--为什么巴比伦塔会失败
-
- 大型项目中的交流
- 因为交流的问题，随着工作的进行，许多小组慢慢地修改自己程序的功能、规模 和速度，他们明确或者隐含地更改了一些有效输入和输出结果用法上的约定。
- 团队如何进行相互之间的交流沟通呢？
- 非正式途径：清晰定义小组内部的相互关系和充分利用电话，能鼓励大量的电话沟通，从而达到对 所书写文档的共同理解。
- 会议：常规项目会议。会议中，团队一个接一个地进行简要的技术陈述。这种方式非常有用， 能澄清成百上千的细小误解。
- 工作手册：在项目的开始阶段，应该准备正式的项目工作手册。
- 项目工作手册
- 项目工作手册不是独立的一篇文档，它是对项目必须产出的一系列文档进行 组织的一种结构。
- 事先将项目工作手册设计好，能保证文档的结构本身是规范的。有了文档结构，后来书写的文字就可以放置在合适的章节中。 控制信息发布并不是为了限制信息，而是确保信息能到达所有需要它的人的手中。项目手册的第一步是对所有的备忘录编号，还有一种更好的组织方法，就是使用树状的索引结构，可以使用树结构中的子树来维护发布列表。
- 人员无可避免地散布在多个地点，对结 构化工作手册的需要和手册规模上的要求都紧迫了许多。
- 大型项目的组织架构
- 如果项目有n 个工作人员，则有（n 2 - n ）/ 2 个相互交流的接口，有将近2 n 个必须合 作的潜在团队。团队组织的目的是减少不必要交流和合作的数量，因此良好的团队组织是解 决上述交流问题的关键措施。
- 减少交流的方法是人力划分和限定职责范围。
- 当使用人力划分和职责限定时，树状管理结构所映出对详细交流的需要会相 应减少。管理角色的非 重复性——导致了管理结构是树状的。但是交流的结构并未限制得如此严格，树状结构几乎 不能用来描述交流沟通，因为交流是通过网状结构进行的。
- 任务、产品负责人、技术主管和结构师、进度、人力的划分、各部分间接口的定义
- 产品负责人：他组建团队，划分工作及制订进度表。他要求，并一直要 求必要的资源。这意味着他主要的工作是与团队外部，向上和水平地沟通。他建立团队内部 的沟通和报告方式。最后，他确保进度目标的实现，根据环境的变化调整资源和团队的构架。
- 技术主管：他对设计进行构思，识别系统的子部分，指明从外部看 上去的样子，勾画它的内部结构。他提供整个设计的一致性和概念完整性；他控制系统的复 杂程度。当某个技术问题出现时，他提供问题的解决方案，或者根据需要调整系统设计。
- 存在三种可能的关系
- 产品负责人和技术主管是同一个人。
- 这种方式非常容易应用在很小型的队伍中，可能 是三个或六个开发人员。在大型的项目中则不容易得到应用。原因有两个：第一，同时具有 管理技能和技术技能的人很难找到。思考者很少，实干家更少，思考者－实干家太少了。第二，大型项目中，每个角色都必须全职工作，甚至还要加班。对负责人来说，很难
在承担全部管理责任的同时，还能抽出时间进行技术工作。对技术主管来说，很难在保证设
计的概念完整性，没有任何妥协的前提下，担任管理工作。
- 产品负责人作为总指挥，技术主管充当其左右手。
- 很难在技术 主管不参与任何管理工作的同时，建立在技术决策上的权威。
- 技术主管作为总指挥，产品负责人充当其左右手。
- 这种安排同样能使工作非常有效
- 最后一种安排对小型的团队是最好的选择，对于真正大型项目中的一些开发队伍，我认为产品负责人作为管理者是更合适的 安排。
- 交流和交流的结果— —组织，是成功的关键。交流和组织的技能需要管理者仔细考虑，相关经验的积累和能力的 提高同软件技术本身一样重要。
blog comments powered by Disqus