zoukankan      html  css  js  c++  java
  • 04《人月神话》阅读笔记

    翻开《人月神话》这本书的第一感受,感觉看这本书不像是在看一本和我们学的相关的书,书中用了很多的形象的比喻,来阐述项目管理中的一些问题,让人以很轻松愉悦心态去阅读。书开始就形象有有趣的把软件危机比作:焦油坑。史前史中,没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震撼。上帝见证着恐龙、猛犸象、剑齿虎在焦油中挣扎。它们挣扎...让我感觉到,软件开发过的过程中,会有很多困难,很多的挑战。

    看完此书后,我发现人月神话无处不在,其实在我们做软件工程来说,此书

    已经渗透进去了。本书作者为人们管理复杂项目提供了颇具洞察力的见解,既有

    很多发人深省的观点,也有大量的软件工程实践。大型编程项目深受由于人力划

    分产生的管理问题的困扰,保持产品本身的概念完整性是一个至关重要的需求。

    《人月神话》探索了达成一致性的困难和解决的方法,并探讨了软件工程管理的其他方面。

    的在刚刚进入软件工程学习时,老师就和我们说了一些关于“软件项目开发的完成与增加人员的问题”,这句话听起来通俗易懂,道理很简单明了,但实现起来却遇到了相当大的困难,这也是我在阅读完成《人月神话》时最大的感受。全书的第二章说的就是人月神话的关系。“一切都将运转良好”在软件工程中是不适用的;完成工作的人数与时间是不能进行简单的互换的,因为沟通需要额外的成本。我想这种问题的出现主要是就订单项目而言,因为人员的增加主要是因为客户所要求实现的东西并没有在计划的时间内收到满意的答复和应得的功能与效益。所以项目开发人员不断的增加,本书作者布鲁克斯得出的结论是显而易见的:“向进度落后的项目中增加人手,只会使进度更加落后”。如果不想加班,不想削减功能,不想推迟发布日期,那么唯一的方法还是只有加人。加足够的人。而且不要逐步加入,一定要一次性加入。要小心的是,新加入的人可能对原来的组织造成冲击,或者对原来的设计有不同意见,特别是我想如果如果有比较强大的设计者时就要当做新组建了一个团队。重新交流,培训新人,就设计达成一致,继续向者目标前进。这也是造成项目延迟的原因之一。软件开发的多少人参与和完成时间不成正比,过多的人参与并不一定能缩短开发时间。如战争,部队多,人多并不是关键,更多需要武器的先进,战术,兵多后方便的补给就得多。如是参与软件开发的人增加,软件的花费将提高,刚参加这需要时间了解项目,给软件管理带来了不协调。在我们实际进行软件开发的时候,各个成员之间要做好沟通协调,一个人开发软件虽然完整性会很好,但是效率太低;相反,团队开发虽然效率很高速度很快,但是如果各个成员之前没有很好地团结协作,各自为战,那么最后的结果也一定不会尽如人意。

    书中主要提到在项目管理方面可以看到项目估算,组织结构和人员角色安排,团队建设和沟通,历史数据积累和建模,软件开发方法论,风险和问题管理等相关的内容;在软件工程方面可以看到架构设计保证概念完整性,整体和部分,空间技能和程序结构的关系,产品集成的方法和消除缺陷的设计思路;在支持过程上我们可以看到文档和流程的建设,软件开发工具对软件开发过程的支持和效率的提升以及工具的选择等相关内容,回过来再看,发现书里面仍然大部分内容涉及到了团队,人和沟通。对于大型的软件工程项目仍然强调了人的重要性,在开篇就在讲开发人员的职业乐趣,后面又通过巴比伦塔讲沟通的重要性,在外科手术队伍中讲团队的组建和分工。这些都涉及到了团队中的人和交互,只有一个有了积极心态和热情的沟通团队,才可能成就一个伟大的团队。从最后的没有银弹,再次肯定了开发工作是一种高智力的脑力工作。

     

  • 相关阅读:
    模式识别 之 BP算法
    仪器开发 之 DICOM 三维重建 HPP
    模式识别 之 BP算法 (二)
    病理分析 之 细胞分析
    脉搏血氧仪 之 算法原理
    模式识别 之 初学
    机器学习 之 模糊神经(失败总结)
    冲刺第二天
    冲刺第三天
    团队项目计划
  • 原文地址:https://www.cnblogs.com/yibao/p/8317627.html
Copyright © 2011-2022 走看看