人月神话》(二)"/>
杀不死的人狼——我读《人月神话》(二)
<<== 上一节
===== 二、哪些是现象,哪些是答案,而哪些才是本质? ===== Brooks 在 1961 年至 1964 年间,主持与领导了被称为人类从原子能时代进入信息时代标志的 IBM/360 。十余年后,在 1975 年,他将历年来所写的有关软件工程和项目管理方面的文章汇集成书,这就是《人月神话》。无疑的,《人月神话》是 Brooks 十年中对 IBM/360与操作系统OS360等 项目的不断反思的结果。 而在我看到 Brooks 这些言论的时候,我并没有为它们所震惊。我所叹服的是 Brooks 在 30 年前便具有这样深远的思想。可以想见,对于 30 年前的黑暗时代,这些思想无疑是明灯和烛火。 (你有否打算用十年来思考一个问题呢?) 但这些在我看来,还只是“现象”。 Brooks 的持续思考也是现象,所述的言论也是现象。我们既不能因为其过程,也不能因为其结果而坚信这些观点:在决定全盘接受之前,至少要看清楚盘子里的东西。 我大概地统计了一下第 18 章列出的列表,其中:章 | 现象 | 答案 | 本质 | 章 | 现象 | 答案 | 本质 |
1 | 3 | 9 | 7 | 7 | 2 | ||
2 | 10 | 1 | 1 | 10 | 7 | 4 | 1 |
3 | 3 | 3 | 11 | 21 | 6 | 2 | |
4 | 3 | 4 | 1 | 12 | 15 | 3 | 1 |
5 | 3 | 2 | 13 | 13 | 4 | ||
6 | 3 | 5 | 1 | 14 | 13 | 4 | 1 |
7 | 5 | 14 | 2 | 15 | 9 | 5 | 1 |
8 | 10 | 1 | 统计 | 62% | 31% | 7% |
本质含义 | 原文 | 注 |
项目在定义阶段就发生了错误 | 2.6 我们围绕成本核算的估计技术,混淆了工作量和项目进展。 人月是危险和带有欺骗性的神话,因为它暗示人员数量和时间是可以相互替换的。 | |
概念不完整=定义不明确=无法实施 | 4.1 “ 概念完整性是系统设计中最重要的考虑因素 ” | 注 1 |
形式化会带来精确的定义 | 6.3 出于精确性的考虑,我们需要形式化的设计定义 ,同样,我们需要记叙性定义来加深理解。 | |
组织是交流(沟通)的结果 | 7.1 巴比伦塔项目的失败是因为缺乏交流,以及交流的结果——组织。 | |
组织的目标:减少必要的交流和协作量 | 7.16 团队组织的目标是为了减少必要的交流和协作量。 | |
小型程序与大型程序不同 | 8.2 构建独立小型程序的数据不适用于编程系统项目。 | |
私利性是本质问题 | 9.6 在大型的团队中,各个小组倾向于不断地局部优化,以满足自己的目标,而较少考虑队用户的整体影响。这种方向性的问题是大型项目的主要危险。 | 注 2 |
数据表现形式是编程的根本 | 9.16 更普遍的是,战略上突破常来自于数据或表的重新表达。数据的表现形式是编程的根本。 | |
项目经理的基本职责 | 10.9 项目经理的基本职责是使每个人都向着相同的方向前进。 | |
产品交付的关键是质量的保障程度 | 11.7 “ 开发人员交付的是用户满意程度,而不仅仅是实际的产品。 ” ( Cosgrove ) | 注 3 |
用户需求变化的根源 | 11.9 软件产品易于掌握的特性和不可见性,导致了它的构建人员(特别容易)面临着永恒的需求变更。 | |
某些计算机资源不能总是方便的得到 | 12.4 目标机器的使用需求量是一种特殊曲线:刚开始使用率非常低,突然出现爆发性的增长,接着趋于平缓。 | 注 4 |
里程碑的性质/定义 | 14.4 里程碑必须是具体的、特定的、可度量的事件,能进行清晰能定义。 | |
程序=用户认识+机器认识 | 15.1 对于软件编程产品来说,程序向用户所呈现的面貌与提供给机器识别的内容同样重要。 |
下一节==>>
更多推荐
杀不死的人狼——我读《人月神话》(二)
发布评论