《人月神话》读书笔记
2015-10-08 23:36
288 查看
[align=center]《人月神话》读书笔记
缺乏合理的进度造成项目滞后:[/align]
[align=left] 我们所面临的挑战和任务是在现有的时间和有效的资源范围内,寻找解决实际问题的切实可行的方案。在众多软件项目中,缺乏合理的时间进度[/align]
[align=left]是造成项目滞后的最主要的原因,它比其他所有因素加起来的影响还大。导致这种普遍性灾难的原因是什么呢? [/align]
[align=left]
[/align]
[align=left] 首先:我们对估算技术缺乏有效的研究,更加严肃地说,它反映了一种悄无声息,但并不真实的假设----一切都将运作良好。[/align]
[align=left] 第二:我们采用的估算技术隐含地假设人和月可以互换,错误地将进度与工作量相互混淆。[/align]
[align=left] 第三:由于对自己的估算缺乏信心,软件经理通常不会有耐心持续地进行估算这项工作。[/align]
[align=left] 第四:对进度缺少跟踪和监督。在其他工程领域中,经过验证的跟踪技术和常规监督程序在软件工程中常常被认为是无谓的举动。[/align]
[align=left] 第五:当意识到进度的偏移时,下意识以及传统的反应是增加人力。这就像使用汽油灭火一样,只会使事情更糟。越来越大的火势需要更多的[/align]
[align=left] 汽油,从而进入了一场注定会导致灾难的循环。[/align]
[align=left]
[/align]
[align=left]
[/align]
[align=left] 第二个谬误的思考方式是在估计和进度安排中使用的工作量单位:人月。[/align]
[align=left]成本的确随开发产品的人数和时间的不同,有着很大的变化,进度却不是如此。因此我认为用人月作为衡量一项工作的规模是一个危险的和带有欺骗性[/align]
[align=left]的神话。它暗示着人员数量和时间是可以相互替换的。[/align]
*人数和时间的互换仅仅适用于以下情况:某个任务可以分解给参与人员,并且他们之间不需要相互的交流。(如图2.1)
(这在割小麦或收获棉花的工作中是可行的,而在系统编程中近乎不可能。)
图2.1 人员和时间之间的关系--完全可以分解的任务
[align=left]
[/align]
当任务由于次序上的限制不能分解时,人手的添加对进度没有帮助。
[align=left]无论多少母亲,孕育一个生命都需要十个月。由于调试、测试的次序特性,许多软件都具有这种特征。对于可以分解,但子任务之间需要相互沟通[/align]
[align=left]和交流的任务,必须在计划中考虑沟通的工作量。因此,相同人月的前提下,采用增加人手来减少时间得到的最好情况,也比未调整前要差一些。[/align]
[align=left](如图2.2)[/align]
图2.2 人员和时间之间的关系--无法分解的任务
沟通所增加的负担由两个部分组成,培训和相互的交流。每个成员需要进行技术、项目目标以及总体策略上的培训。这种培训不能分解,
因此这部分增加的工作量随人员的数量呈线性变化。(如图2.3)
图2.3 人员和时间之间的关系--需要沟通的可分解任务
人员相互之间交流的情况更糟一些:若任务的每个部分必须分别和其他部分单独协作,则工作量按照n(n-1)/2递增。一对一交流的情况下,
[align=left]三个人的工作量是两个人的三倍,四个人的工作量则是两个人的六倍。而对于需要在三四个人之间召开会议,进行协商,一同解决的问题,[/align]
[align=left]情况会更加恶劣。所增加的用于沟通的工作量可能会完全抵消对原有任务分解所产生的作用。此时,我们会被带到图2.4的境地。[/align]
图2.4 人员和时间之间的关系--关系错综复杂的任务
因此软件开发本质上是一项系统工作--错综复杂关系下的一种实践--沟通、交流的工作量非常大,它很快会消耗任务分解所节省下来的
[align=left]个人时间。从而添加更多的人手,实际上是延长了,而不是缩短了时间进度。[/align]
[align=left]
总结:[/align]
[align=left] 人员和时间的关系: 1.完全可以分解的任务: 人 = 月[/align]
[align=left] 2.无法分解的任务: 人 != 月 (任务由次序上的限制不能分解)[/align]
[align=left] 3.需要沟通的可以分解的任务: 人 ≈ 月 (需在计划中考虑沟通的工作量)[/align]
[align=left]4.关系错综复杂的任务: 人!= 月 (增加人手产生的工作量抵消了分解任务产生的作用)[/align]
[align=left]
[/align]
[align=left]
[/align]
[align=left]向进度落后的项目中增加人手,只会使进度更加落后。[/align]
[align=left]这就是除去了神话色彩的人月。项目的时间依赖于顺序上的限制,人员的数量依赖于单个子任务的数量。总之,在众多软件项目中,缺乏合理的[/align]
[align=left]时间表(进度)是造成项目滞后的最主要原因,它比其他所有因素加起来的影响还要大。[/align]
[align=left]
[/align]
[align=left]不变的只是愿望,变化才是永恒。[/align]
[align=left]普遍的做法是,选择一种方法,试试看;如果失败了,没关系,再试试别的。不管怎么样,重要的是先去尝试。[/align]
[align=left]
[/align]
[align=left]没有银弹--软件工程中的根本和次要问题。[/align]
[align=left]没有任何技术或管理上的进展,能够独立地许诺十年内使生产率,可靠性或简洁性获得数量级上的进步。[/align]
[align=left]
[/align]
[align=left]实践是最好的老师,但是,如果不能从中学习,再多的实践也没有用。[/align]
不变只是愿望,变化才是永恒。
注:
人月神话 The Mythical Man-Month FrederickP Brooks JR著 清华大学出版社 1999
缺乏合理的进度造成项目滞后:[/align]
[align=left] 我们所面临的挑战和任务是在现有的时间和有效的资源范围内,寻找解决实际问题的切实可行的方案。在众多软件项目中,缺乏合理的时间进度[/align]
[align=left]是造成项目滞后的最主要的原因,它比其他所有因素加起来的影响还大。导致这种普遍性灾难的原因是什么呢? [/align]
[align=left]
[/align]
[align=left] 首先:我们对估算技术缺乏有效的研究,更加严肃地说,它反映了一种悄无声息,但并不真实的假设----一切都将运作良好。[/align]
[align=left] 第二:我们采用的估算技术隐含地假设人和月可以互换,错误地将进度与工作量相互混淆。[/align]
[align=left] 第三:由于对自己的估算缺乏信心,软件经理通常不会有耐心持续地进行估算这项工作。[/align]
[align=left] 第四:对进度缺少跟踪和监督。在其他工程领域中,经过验证的跟踪技术和常规监督程序在软件工程中常常被认为是无谓的举动。[/align]
[align=left] 第五:当意识到进度的偏移时,下意识以及传统的反应是增加人力。这就像使用汽油灭火一样,只会使事情更糟。越来越大的火势需要更多的[/align]
[align=left] 汽油,从而进入了一场注定会导致灾难的循环。[/align]
[align=left]
[/align]
[align=left]
[/align]
[align=left] 第二个谬误的思考方式是在估计和进度安排中使用的工作量单位:人月。[/align]
[align=left]成本的确随开发产品的人数和时间的不同,有着很大的变化,进度却不是如此。因此我认为用人月作为衡量一项工作的规模是一个危险的和带有欺骗性[/align]
[align=left]的神话。它暗示着人员数量和时间是可以相互替换的。[/align]
*人数和时间的互换仅仅适用于以下情况:某个任务可以分解给参与人员,并且他们之间不需要相互的交流。(如图2.1)
(这在割小麦或收获棉花的工作中是可行的,而在系统编程中近乎不可能。)
图2.1 人员和时间之间的关系--完全可以分解的任务
[align=left]
[/align]
当任务由于次序上的限制不能分解时,人手的添加对进度没有帮助。
[align=left]无论多少母亲,孕育一个生命都需要十个月。由于调试、测试的次序特性,许多软件都具有这种特征。对于可以分解,但子任务之间需要相互沟通[/align]
[align=left]和交流的任务,必须在计划中考虑沟通的工作量。因此,相同人月的前提下,采用增加人手来减少时间得到的最好情况,也比未调整前要差一些。[/align]
[align=left](如图2.2)[/align]
图2.2 人员和时间之间的关系--无法分解的任务
沟通所增加的负担由两个部分组成,培训和相互的交流。每个成员需要进行技术、项目目标以及总体策略上的培训。这种培训不能分解,
因此这部分增加的工作量随人员的数量呈线性变化。(如图2.3)
图2.3 人员和时间之间的关系--需要沟通的可分解任务
人员相互之间交流的情况更糟一些:若任务的每个部分必须分别和其他部分单独协作,则工作量按照n(n-1)/2递增。一对一交流的情况下,
[align=left]三个人的工作量是两个人的三倍,四个人的工作量则是两个人的六倍。而对于需要在三四个人之间召开会议,进行协商,一同解决的问题,[/align]
[align=left]情况会更加恶劣。所增加的用于沟通的工作量可能会完全抵消对原有任务分解所产生的作用。此时,我们会被带到图2.4的境地。[/align]
图2.4 人员和时间之间的关系--关系错综复杂的任务
因此软件开发本质上是一项系统工作--错综复杂关系下的一种实践--沟通、交流的工作量非常大,它很快会消耗任务分解所节省下来的
[align=left]个人时间。从而添加更多的人手,实际上是延长了,而不是缩短了时间进度。[/align]
[align=left]
总结:[/align]
[align=left] 人员和时间的关系: 1.完全可以分解的任务: 人 = 月[/align]
[align=left] 2.无法分解的任务: 人 != 月 (任务由次序上的限制不能分解)[/align]
[align=left] 3.需要沟通的可以分解的任务: 人 ≈ 月 (需在计划中考虑沟通的工作量)[/align]
[align=left]4.关系错综复杂的任务: 人!= 月 (增加人手产生的工作量抵消了分解任务产生的作用)[/align]
[align=left]
[/align]
[align=left]
[/align]
[align=left]向进度落后的项目中增加人手,只会使进度更加落后。[/align]
[align=left]这就是除去了神话色彩的人月。项目的时间依赖于顺序上的限制,人员的数量依赖于单个子任务的数量。总之,在众多软件项目中,缺乏合理的[/align]
[align=left]时间表(进度)是造成项目滞后的最主要原因,它比其他所有因素加起来的影响还要大。[/align]
[align=left]
[/align]
[align=left]不变的只是愿望,变化才是永恒。[/align]
[align=left]普遍的做法是,选择一种方法,试试看;如果失败了,没关系,再试试别的。不管怎么样,重要的是先去尝试。[/align]
[align=left]
[/align]
[align=left]没有银弹--软件工程中的根本和次要问题。[/align]
[align=left]没有任何技术或管理上的进展,能够独立地许诺十年内使生产率,可靠性或简洁性获得数量级上的进步。[/align]
[align=left]
[/align]
[align=left]实践是最好的老师,但是,如果不能从中学习,再多的实践也没有用。[/align]
不变只是愿望,变化才是永恒。
注:
人月神话 The Mythical Man-Month FrederickP Brooks JR著 清华大学出版社 1999
相关文章推荐
- 黑马程序员——IO概述之转换流和键盘录入
- 年化收益“破3”创新低,余额宝生存空间遭挤压
- a useful macro when writing webpage with common lisp
- XF 文档 - Element Framework Doc
- 最短路径算法Dijkstra && SPFA && Floyd 代码实现模板
- NODE接口的属性和方法
- ZOJ 3826 大模拟
- dns总结一
- iOS开发笔记--swift语法基础
- Unity Shader 表面着色器边缘光(Rim Lighting)二
- java线程 同步与异步
- BestCoder Round #57 (div.2) HDU 5479 Scaena Felix
- Mybatis框架基础学习(二)
- 浏览器兼容性问题汇总
- mysql-procedure多参数(测试)
- Theano入门——MNIST数据库
- Dev tdxDBTreeView
- [DP]Codeforces Round #323 (Div. 2)DOnce Again...
- james 安装
- HDU 5128 暴力