杀不死的人狼——我读《人月神话》(二) 编程360项目管理IBM
程序员文章站
2022-07-16 13:19:43
...
=====
二、哪些是现象,哪些是答案,而哪些才是本质?=====
*s在1961年至1964年间,主持与领导了被称为人类从原子能时代进入信息时代标志的IBM/360。十余年后,在1975年,他将历年来所写的有关软件工程和项目管理方面的文章汇集成书,这就是《人月神话》。无疑的,《人月神话》是*s十年中对IBM/360与操作系统OS360等项目的不断反思的结果。
而在我看到*s这些言论的时候,我并没有为它们所震惊。我所叹服的是*s在30年前便具有这样深远的思想。可以想见,对于30年前的黑暗时代,这些思想无疑是明灯和烛火。
(你有否打算用十年来思考一个问题呢?)
但这些在我看来,还只是“现象”。*s的持续思考也是现象,所述的言论也是现象。我们既不能因为其过程,也不能因为其结果而坚信这些观点:在决定全盘接受之前,至少要看清楚盘子里的东西。
我大概地统计了一下第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%
|
列表中分出了三类:现象、答案和本质。通常我们总是能给出“答案”,但未见得触及“本质”。例如街口的乞丐向我伸出手来,我给了他十元钞票,我给出了解决了他伸手(这个问题)的答案,但没并有触及他伸手的本质:饥饿;更未能触及整个事件的本质:贫穷(或者懒惰)。另外,在标注成“现象”的项中,有一部分是包括某种现象的成因的。我最开始分析时,有“原因”这个分类,但后来发现原因其实也是一种现象,所以我合并了它们。
对“现象-答案-本质”的分析存在主观的成分,因此你可以重做这个实验。但我建议你谨慎使用“本质”这个标签。至于其它两种,即使你混淆了,(在接下来的讨论中)也不是至关重要的——尤其是现在,很多*s先生曾经给出的答案已经变成了思考同类问题的现实现象。
你可以在工程中应用这些既有的答案。但是无论这些“解/答案”看起来如何合理,如果脱离它本质上讨论的对象,那么就可能不是正确的解。而另一方面,如果作者的逻辑足够清晰,那么他提出的“解/答案”必然是围绕着某些本质的东西。在上面的列表的分析过程中,我只看到这样的几点本质:
本质含义
|
原文
|
注
|
项目在定义阶段就发生了错误
|
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 对于软件编程产品来说,程序向用户所呈现的面貌与提供给机器识别的内容同样重要。
|
注1:这里“精确定义”是本质,形式化只是答案。
注2:对组织中的个体或组织的局部来说。
注3:产品问题不是本身的“完成度”的问题,而是用户可感受到的质量问题。
注4:书用例举的是“调试环境和目标系统”,但可以引申到例如“目标用户”或者“客户现场”。
我们应该清楚:现象之存在与是否被发现无关。例如苹果从树上掉到地上是现象,你看见这个现象也并不体现你的伟大,你四处大叫“苹果掉地上了”会被人当成疯子。而牛顿没有被人(因此)看成疯子的原因:现象只是引起了他的注意,而探究到“本质”才是关键。
所以上表列出的“62%的现象”只是*s从四十年前就好心的提醒我们:看啦,快看看这些奇怪的现象,你难道不觉得它们奇怪么?于是,我们开始关注这些,并把它们当成关注的焦点。我只能因此承认*s是一个醒客,但这并不表明“陈述现象”,就等于告诉了我们什么真理。
接下来我们讨论“31%的答案”。
上一篇: 下一代(大众)语言霸主应该具备的条件
下一篇: C基本数据类型所占字节数