人月神话读后.doc

《人月神话》读后感通过阅读《人月神话》, 我从中学到了一些东西: 首先, 开发一个项目, 我们错误的认为用人月这个工作量单位来估计和进行进度安排。成本的确随开发产品的人数和时间的不同, 有着很大的变化, 进度却不是如此。因此我认为用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互替换的。人数和时间的互换仅仅适用于以下情况: 某个任务可以分解给参与人员, 并且他们之间不需要相互的交流, 而在系统编程中近乎不可能。当任务由于次序上的限制不能分解时, 人手的添加对进度没有帮助。调试、测试的次序特性, 许多软件都具有这种特征。因为软件开发本质上是一项系统工作——错综复杂关系下的一种实践——沟通、交流的工作量非常大, 它很快会消耗任务分解所节省下来的个人时间。从而, 添加更多的人手, 实际上是延长了, 而不是缩短了时间进度。对于编程, 有其乐趣和苦恼。创建事物的快乐, 开发对其他人有用的东西的乐趣, 将可以活动、相互啮合的零部件组装成类似迷宫的东西,这个过程所体现出令人神魂颠倒的魅力, 面对不重复的任务,不间断学习的乐趣,工作在如此易于驾驭的介质上的乐趣——纯粹的思维活动,其存在、移动和运转方式完全不同于实际物体。将做事方式调整到追求完美,是学习编程的最困难部分; 由其他人来设定目标, 并且必须依靠自己无法控制的事物( 特别是程序) ;权威不等同于责任实际情况看起来要比这一点好一些;真正的权威来自于每次任务的完成任何创造性活动都伴随着枯燥艰苦的劳动,编程也不例外人们通常期望项目在接近结束时,( bug 、工作时间) 能收敛得快一些, 然而软件项目的情况却是越接近完成, 收敛得越慢产品在即将完成时总面临着陈旧过时的威胁。开发一个软件, 我们要有合理的时间进度, 开发人员要少而精, 概念完整性必须考虑在内, 要尽量做到尽早交流和持续沟通。同时, 文档形成了关键的枢纽, 每个项目管理的工作都围绕着它们运转, 它们是经理们的主要个人工具。对于计算机硬件开发项目,关键文档是目标、手册、进度、预算、组织机构图、空间分配、以及机器本身的报价、预测和价格; 对于大学科系, 关键文档类似: 目标、课程描述、学位要求、研究报告、课程表和课程的安排、预算、教室分配、教师和研究生助手的分配; 对于软件项目, 要求是相同的: 目标、用户手册、内部文档、进度、预算、组织机构图和工作空间分配。即使是一个小型项目, 我们都会要求书写相关文档, 对每个关键文档的维护提供了状态监督和预警机制并且本身就可以作为检查列表或者数据库。良好的工作手册和组织架构可以开发出更加符合用户的需求。手册、或者书面规格说明, 是一个非常必要的工具, 尽管光有文档是不够的。手册是产品的外部规格说明, 它描述和规定了用户所见的每一个细节; 同样的, 它也是结构师主要的工作产物。形式化定义是精确的, 它们倾向于更加完整; 差异得更加明显, 可以更快地完成。但是形式化定义的缺点是不易理解。记叙性文字则可以显示结构性的原则, 描述阶段上或层次上的结构, 以及提供例子。它可以很容易地表达异常和强调对比的关系,最重要的是,它可以解释原因。在表达的精确和简明性上, 目前所提出的形式化定义, 具有了令人惊异的效果, 增强了我们进行准确表达的信心。通常,开发一个软件我们还会设立规模目标,控制规模