《人月神话》的读书笔记.doc

人月神话的读书笔记 人月神话阅读笔记01 发表日期时间:xx-04-3019:07 这段时间我开始阅读本学期我选择的第二本书人月神话。人月神话内容源于作者Brooks在IBM公司任System计算机系列以及其庞大的软件系统OS项目经理时的实践经验。人月神话探索了达成一致性的困难和解决的方法，并探讨了软件工程管理的其他方面。 “焦油坑”这章，作者把大型系统开发比作一个焦油坑.作者从开发系统产品引入先分析职业的乐趣与苦恼，得出“编程，一个许多人痛苦挣扎的焦油坑以及一种乐趣和苦恼共存的创造性活动。”这一结论。 “人月神话”这章，指出缺乏合理的时间进度是造成项目滞后的最主要原因以及导致这种普遍性灾难的原因。大部分编程人员对于项目的看法太乐观，一个项目增加人手，会增加沟通的复杂度，增加交流的工作量，会适得其反。充分的系统测试时间十分重要。软件估算要科学合理。 外科手术队伍这章，讲了这一模型的团队如何运作及扩建。 贵族专制、民主政治和系统设计：易用性实际上需要设计的一致性和概念上的完整性。 画蛇添足：结构师的交互准则和机制。项目经理如何避免画蛇添足 （second-systemeffect）？他必须坚持至少拥有两个系统以上开发经验结构师的决定。同时，保持对特殊诱惑的警觉，他可以不断提出正确的问题，确保原则上的概念和目标在详细设计中得到完整的体现。 贯彻执行：手册、或者书面规格说明，是一个非常必要的工具，尽管光有文档是不够的。手册是产品的外部规格说明，它描述和规定了用户所见的每一个细节；同样的，它也是结构师主要的工作产物。会议是必要的。产品测试是十分重要的一环。 前6章，作者以自己的开发经验为例，为读者介绍了软件开发的一些知识。比较生动的说明了，软件开发中存在的困难。 虽然身为在校生对大型的软件开发不太了解，但依然能从中汲取许多知识。 读人与神话有感 翻开人月神话这本书的第一感受，感觉看这本书不像是在看一本和我们学的相关的书，书中用了很多的形象的比喻，来阐述项目管理中的一些问题，让人以很轻松愉悦心态去阅读。书开始就形象有有趣的把软件危机比作：焦油坑。史前史中,没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震撼。上帝见证着恐龙、猛犸象、剑齿虎在焦油中挣扎。它们挣扎.让我感觉到，软件开发过的过程中，会有很多困难，很多的挑战。 看完此书后，我发现人月神话无处不在，其实在我们做软件工程来说，此书已经渗透进去了。本书作者为人们管理复杂项目提供了颇具洞察力的见解，既有很多发人深省的观点，也有大量的软件工程实践。大型编程项目深受由于人力划分产生的管理问题的困扰，保持产品本身的概念完整性是一个至关重要的需求。人月神话探索了达成一致性的困难和解决的方法，并探讨了软件工程管理的其他方面。 的在刚刚进入软件工程学习时，老师就和我们说了一些关于“软件项目开发的完成与增加人员的问题”，这句话听起来通俗易懂，道理很简单明了，但实现起来却遇到了相当大的困难，这也是我在阅读完成人月神话时最大的感受。全书的第二章说的就是人月神话的关系。“一切都将运转良好”在软件工程中是不适用的；完成工作的人数与时间是不能进行简单的互换的，因为沟通需要额外的成本。我想这种问题的出现主要是就订单项目而言，因为人员的增加主要是因为客户所要求实现的东西并没有在计划的时间内收到满意的答复和应得的功能与效益。所以项目开发人员不断的增加，本书作者布鲁克斯得出的结论是显而易见的：“向进度落后的项目中增加人手，只会使进度更加落后”。如果不想加班，不想削减功能，不想推迟发布日期，那么唯一的方法还是只有加人。加足够的人。而且不要逐步加入，一定要一次性加入。要小心的是，新加入的人可能对原来的组织造成冲击，或者对原来的设计有不同意见，特别是我想如果如果有比较强大的设计者时就要当做新组建了一个团队。重新交流，培训新人，就设计达成一致，继续向者目标前进。这也是造成项目延迟的原因之一。软件开发的多少人参与和完成时间不成正比，过多的人参与并不一定能缩短开发时间。如战争，部队多，人多并不是关键，更多需要武器的先进，战术，兵多后方便的补给就得多。如是参与软件开发的人增加，软件的花费将提高，刚参加这需要时间了解项目，给软件管理带来了不协调。在我们实际进行软件开发的时候，各个成员之间要做好沟通协调，一个人开发软件虽然完整性会很好，但是效率太低；相反，团队开发虽然效率很高速度很快，但是如果各个成员之前没有很好地团结协作，各自为战，那么最后的结果也一定不会尽如人意。 书中主要提到在项目管理方面可以看到项目估算，组织结构和人员角色安排，团队建设和沟通，历史数据积累和建模，软件开发方法论，风险和问题管理等相关的内容；在软件工程方面可以看到架构设计保证概念完整性，整体和部分，空间技能和程序结构的关系，产品集成的方法和消除缺陷的设计思路；在支持过程上我们可以看到文档和流程的建设，软件开发工具对软件开发过程的支持和效率的提升以及工具的选择等相关内容，回过来再看，发现书里面仍然大部分内容 涉及到了团队，人和沟通。对于大型的软件工程项目仍然强调了人的重要性，在开篇就在讲开发人员的职业乐趣，后面又通过巴比伦塔讲沟通的重要性，在外科手术队伍中讲团队的组建和分工。这些都涉及到了团队中的人和交互，只有一个有了积极心态和热情的沟通团队，才可能成就一个伟大的团队。从最后的没有银弹，再次肯定了开发工作是一种高智力的脑力工作。 开发一个软件，我们要有合理的时间进度，开发人员要少而精，概念完整性必须考虑在内，要尽量做到尽早交流和持续沟通。同时，文档形成了关键的枢纽，每个项目管理的工作都围绕着它们运转，它们是经理们的主要个人工具。对于计算机硬件开发项目，关键文档是目标、手册、进度、预算、组织机构图、空间分配、以及机器本身的报价、预测和价格；对于大学科系，关键文档类似：目标、课程描述、学位要求、研究报告、课程表和课程的安排、预算、教室分配、教师和研究生助手的分配；对于软件项目，要求是相同的：目标、用户手册、内部文档、进度、预算、组织机构图和工作空间分配。即使是一个小型项目，我们都会要求书写相关文档，对每个关键文档的维护提供了状态监督和预警机制并且本身就可以作为检查列表或者数据库。良好的工作手册和组织架构可以开发出更加符合用户的需求。手册、或者书面规格说明，是一个非常必要的工具，尽管光有文档是不够的。手册是产品的外部规格说明，它描述和规定了用户所见的每一个细节；同样的，它也是结构师主要的工作产物。 一个软件的好坏不是说是由一个程序员决定的，往往一个很小的功能，其实也需要开发人员的架构设计方面的完善，对其它模块的影响及扩展,以及代码编写工作。一个小小的bug，也许就需要好几个部门的分工协作。原著中说，软件系统也是人类创造的错综复杂的事物。所以只有在一个团队的沟通了解，通力协作和努力之下，才能做出更加完善的软件作品！ 人月神话读后感 在刚刚进入软件工程学习时，老师总会时不时向我们提起一些关于“软件项目开发的完成与增加人员的问题”这句话听起来通俗易懂，但实现起来却遇到了相当大的困难，这是我在阅读完成人月神话时最大的感受，我想这种问题的出现主要是就订单项目而言，因为人员的增加主要是因为客户所要求实现的东西并没有在计划的时间内收到满意的答复和应得的功能与效益。所以项目开发人员不断的增加，本书作者布鲁克斯得出的结论是显而易见的：“向进度落后的项目中增加人手，只会使进度更加落后”。如果不想加班，不想削减功能，不想推迟发布日期，那么唯一的方法还是只有加人。加足够的人。而且不要逐步加入，一定要一次性加入。要小心的是，新加入的人可能对原来的组织造成冲击，或者对原来的设计有不同意见，特别是我想如果如果有比较强大的设计者时就要当做新组建了一个团队。重新交流，培训新人，就设计达成一致，继续向者目标前进。这也是造成项目延迟的原因之一。 书中主要提到在项目管理方面可以看到项目估算，组织结构和人员角色安排，团队建设和沟通，历史数据积累和建模，软件开发方法论，风险和问题管理等相关的内容；在软件工程方面可以看到架构设计保证概念完整性，整体和部分，空间技能和程序结构的关系，产品集成的方法和消除缺陷的设计思路；在支持过程上我们可以看到文档和流程的建设，软件开发工具对软件开发过程的支持和效率的提升以及工具的选择等相关内容，回过来再看，发现书里面仍然大部分内容涉及到了团队，人和沟通。对于大型的软件工程项目仍然强调了人的重要性，在开篇就在讲开发人员的职业乐趣，后面又通过巴比伦塔讲沟通的重要性，在外科手术队伍中讲团队的组建和分工。这些都涉及到了团队中的人和交互，只有一个有了积极心态和热情的沟通团队，才可能成就一个伟大的团队。从最后的没有银弹，再次肯定了开发工作是一种高智力的脑力工作。 总结一下这本书，讲的主要是软件工程方面的，如何配置人力进行开发。虽然对于软件编程我们对其了解并不多，但是对于在软件功能的实现，程序设计人员面临的客观性的困难至少我可以站在略懂的角度上去理解他们，对于一个或多个项目来说，公司大多都会搞人海战术，进度没有提前，还整天加班，最后用户不满意，开发人员整天郁闷，结果是用户对公司失去了信任，成了一槌子买卖，开发人员旧人一一辞职，新人天天引进，做法没有改变，情况没有改观，公司没有发展，这就是问题。人月之所以不能成为神话，正是因为增加人手的同时也增加了人与人之间的交流。我们所有的进度都是以“人月”代码产量来衡量的.而增加人并不能缩短月的量。这同样是作者的观点，布鲁克斯这个名字在中国知之者不多，但在美国却是大名鼎鼎。因为他在60年代初只有29岁时就主持与领导了被称为人类从原子能时代进入信息时代标志的IBM/360系列计算机的开发工作，取得辉煌成功，在计算机技术的诸多领域中都做出了巨大的贡献。作者在书中提到了他使用了很多年的经验法则：1/3计划1/6编码1/4构件测试和早期系统测试1/4系统测试，虽然布鲁克斯的这本书发表数十年，但他预计的这些问题并没有得到最终的大变革，软工领域仍在面临着多种作则提出的问题，不过令人欣慰的是，大家确实在向这方面改变。在第6章中作者又提到，系统架构师们应该在文档中描述所有外部特性，但是他应该避免干涉具体实现细节，实际上我们动脑想一想解决