人月神话---观点摘录

<人月神话> 为什么想看这本书呢? 因为以前的公司虽然名气不大, 但是管理流程都挺规范的 , 没有觉察到管理混乱带来的灾难 , 临时到了一家比较有名气的公司 , 但是在开发过程中, 深深感到了管理的混乱 , 流程上的不规范 , 需求上的来回反复 , 所以萌生了想看下正确的流程是什么样的. 于是找到了<人月神话>学习下. 下面是看的时候的观点摘录 , 有的地方,由于资历不够,身处的位置也不是项目经理的位置,所以不太懂, 权且记下了.

1.史前史中,没有别的场景比巨兽们在焦油坑中垂死挣扎的场面更令人震撼。上帝见证着恐龙、猛犸象、剑齿虎在焦油中挣扎。它们挣扎得越猛烈,焦油纠缠得就越紧,没有任何猛兽足够强壮或具有足够的技巧,能够挣脱束缚,它们最后都沉到了坑底。

 

2.向进度落后的项目中增加人手 , 只会使进度更加落后。

 

3.1这些研究表面,效率高和效率低的实施者之间的个体差异非常大,经常能够达到数量级的水平。

3.2常常听软件经理说,他们喜欢由一流人才组成的小型,精干的队伍,而不是那些几百人的大型团队

3.3.概念完整性，外科手术式的团队利于维持设计的一致性，维持较低的软件的熵。

 

10.任何管理任务的关注焦点都是时间,地点,人员,项目内容和资金.

 

11.1普遍的做法是,选择一种方法,试试看;如果失败了,没关系,在试试别的.不管怎么样,重要的是先去尝试.

11.2我从不建议顾客所有的目标和需求的变更必须,能够,或者应该整合到设计中.项目开始时建立的基准,肯定会随着开发的进行越来越高,甚至开发不出任何产品.

11.3变更的阶段化是一种必要的技术.每个产品都应该有数字版本号,每个版本都应该有自己的日程表和冻结日期,在此之后的变更属于下一个版本的范畴.

11.4对于一个广泛使用的程序,其维护总成本通常是开发成本的40%或更多.令人吃惊的是,改成本受用户数目的影响很大.用户越多,所发现的错误呀也越多.

11.5起初,上一个版本中被发现和修复的bug,在新的版本中仍会发现.新版本中的新功能会产生新的bug.解决这些问题后,程序会正常运行几个月.接着,错误率会重新攀升. 

11.6程序维护中的一个基本问题是——缺陷修复总会以固定(20-50%的几率引入新的bug).所以整个过程是前进两步,后退一步.

11.7显然,使用能消除或至少能指明副作用的程序设计方法,会在维护成本上有很大的回报.同样,设计实现的人员越少,接口越少,产生的错误也就越少.

11.8系统软件开发是减少混乱度(减少熵)的过程,所以它本身是出于亚稳态的.软件维护是提高混乱度(增加熵)的过程,即使是最熟练的软件维护工作,也只是放缓了系统退化到非稳态的进程.

 

13.变更必须被阶段化,并且定期发布.这样,每个用户拥有稳定的生成周期.

 

14.里程碑的选择只有一个原则,那就是里程碑必须是具体的,特定的,可度量的事件,能够进行清晰定义.要求边界明显,没有歧义.

 

16.1软件系统的快速原型对重要的系统界面进行模拟，并演示待开发系统的主要功能。同时，原型不必受到相同硬件速度、规模或者成本约束的限制。原型通常展示了应用程序的功能主线，但不处理任何如无效输入、退出清除等异常情况。原型的目的是明确实际的概念结构，使客户可以测试一致性和可用性.

16.2首先系统应该能够运行，即使未完成任何有用功能，只能正确调用一系列伪子系统。接着,系统一点一点被充实，子系统轮流被开发，或者是在更低的层次调用程序、模块、子系统的占位符(伪程序)等。

 

18.1因为左手不知道右手在做什么，从而进度灾难、功能的不合理和系统缺陷纷纷出现。由于对其他人的各种假设，团队成员之间的理解开始出现偏差。团队应该以尽可能多的方式进行相互之间的交流.

18.2传统的树状组织结构反映了权力的结构原理——不允许双重领导.组织中的交流是网状，而不是树状结构，因此所有的特殊组织机制(往往体现成组织结构图中的虚线部分)都是为了进行调整，以克服树状组织结构中交流缺乏的困难。

18.3除了运行时间以外，程序所占据的内存空间也是主要开销。规模本身不是坏事，但不必要的规模是不可取的。软件开发人员必须设立规模目标，控制规模,发明一些减少规模的方法,减少不必要的规模。

18.4规模预算必须与分配的功能相关联;在指明模块大小的同时，确切定义模块的功能。

在大型团队中，各个小组倾向于不断地局部优化，以满足自己的目标，而较少考虑对用户的整体影响。这种方向性的问题是大型项目的主要危险。

在整个实现的过程期间，系统结构师必须保持持续的警觉，确保连贯的系统完整性。

培养开发人员从系统整体出发、面向用户的态度是软件编程管理人员最重要的职能。

18.5对于软件项目，这些文档是重要的 : 产品目标、用户手册、内部文档、进度、预算、组织机构图和工作空间分配。

18.6项目经理的基本职责是使每个人都向着相同的方向前进。项目管理:包括客户管理、进度管理、成本管理、风险管理和培训管理等;

18.7项目经理的主要日常工作是沟通，而不是做出决定;文档使各项计划和决策在整个团队范围内得到交流。

18.8系统的丢弃和重新设计可以一步完成，也可以一块块地实现。但这是个必须完成的步骤。

18.9开发人员交付的是用户满意程度,而不仅仅是实际的产品。

18.10软件产品易于掌握的特性和不可见性，导致它的构建人员(特别容易)面临着永恒的需求变更。

18.11对于一个广泛使用的程序，其维护总成本通常是开发成本的40%或更多。维护成本受用户数目的严重影响。用户越多，所发现的错误也越多。

18.12Campbell指出了一个显示产品生命期中每月bug数的有趣曲线，它先是下降，然后上升。

18.13缺陷修复总会以20%~50%的几率引入新的bug。同样，实现设计的人员越少、接口越少，产生的错误也就越少。

18.14开发大量的辅助调试平台和测试代码是很值得的，代码量甚至可能会有测试对象的一半。

18.15项目是怎样被延迟了整整—年时间的? 一次一天。一次一天的进度落后比起重大灾难更难以识别，更不容易防范和更加难以弥补。

18.16根据一个严格的进度表来控制大型项目的第一个步骤是制定进度表，进度表由里程碑和日期组成。里程碑必须是具体的、特定的和可度量的事件，能进行清晰地定义。如果里程碑定义得非常明确，以至于无法自欺欺人时，程序员很少会就里程碑的进展弄虚作假(哈哈,现实不是这样的)。

18.17状态的获取是困难的，因为下属经理有充分的理由不提供信息共享。并且,老板的不良反应肯定会对信息的完全公开造成压制;相反，仔细区分状态报告、毫无惊慌地接收报告、决不越俎代庖，将能鼓励诚实的汇报。

 

19.1定义用户群。用户群越大和越不确定，就越有必要明确地定义用户群，以获得概念完整性。设计队伍中的每个成员对用户都有—幅假想的图像，并且每个设计者的图像都是不同的。结构师的用户图像会有意或者无意地影响每个结构决策，因此有必要使设计队伍共享一幅相同的用户图像。这需要把用户群的属性记录下来，包括:

他们是谁;

他们需要 (need)什么;

他们认为 自己需要(need)什么;

他们想要(want) 的是什么。

19.2当计划进度比最优进度长时，成本曲线会缓慢攀升。时间越充裕，所花的时间也越长;当计划进度比最优进度短时，成本曲线急剧升高;无论安排多少人手，几乎没有任何项目能够在少于3/4的计算出的最优时间内获得成功!