《人月神话》阅读笔记02

今天我读了人月神话—外科手术队伍和巴比伦塔的失败。有许多体会。

在开发小组中,最好和最查人员生产率比在10:1,在运行效率和空间上5:1惊人差距。如果一个200人的项目中,有25个最能干和最有开发经验的项目经理,那么开除剩下的175名程序员,让项目经理来编程开发。

对于一个软件项目,适合的项目团队规模在20人左右,这是一个专职的IT项目经理可以管理的最大值。那由于项目进度压力需要增加团队规模到100人的时候,让项目经理来开发实际操作是很困难的方式,在这里推荐的方式是将系统按照高内聚,松耦合分解为5个子系统。这样则可以将100个分解为5个项目,由5个项目经理来管理,这是减少和有序化沟通渠道最有效的方式。

所以说小型敏捷的中小型团队可以保持最高的效率,但对于大型软件系统却不得不投入更多的人力资源来换取进度的提前。对于一个软件产品,在激励的竞争下对进度要求是非常严厉的,往往推迟半年推出都有可能失去竞争和市场,更不用说10年。对于信息化软件产品我们更强调的是迭代和多版本开发概念,每个迭代周期在1-2月左右,每个迭代周期都是真正可以向用户提供完整的可交付的功能。

据《创世纪》记载,巴比伦塔是人类继诺亚方舟之后的第二大工程壮举,但巴比伦塔同时也是第一个彻底失败的工程。为何拥有了清晰的目标,充足的人力和物力资源的项目最后仍然失败,巴比伦塔给我们的管理教训就是它们缺乏沟通和交流,以及交流的结果-组织。他们无法相互交谈,从而无法合作。当合作无法进行时,工作陷入了停顿。通过史书的字里行间,我们推测交流的缺乏导致了争辩、沮丧和群体猜忌。很快,部落开始分裂——大家选择了孤立,而不是互相争吵。

所以说沟通在一个团队中是非常重要的。团队沟通是整个项目团队的核心要素,关于项目的共同愿景,目标,进度任务,问题,风险,思想等都需要通过沟通来传达。有效的团队沟通是提升团队竞争力必不可少的要素,项目经理有90%的时间都花费在沟通上面,有了沟通就有了共同的愿景和协作氛围,就有了思想的交换和碰撞。

时间: 2024-10-10 02:57:21

《人月神话》阅读笔记02的相关文章

《构建之法》阅读笔记02

<架构之美>阅读笔记02 今天,我读了<架构之美>第三.四章,第三章主要讲伸缩性架构设计,书中说设计系统架构时,要确保系统在伸缩时的弹性,根据书中的介绍我对系统伸缩性的理解是每个网站在不同时期都会有不同的访问量,有时会很多,有时会较少,当较多的人访问你的系统时,你可能需要数量较多的设备来满足用户与系统的交互,但当访问的用户越来越少时,系统伸缩性如果不够好,很多设备就会被浪费,不能够与系统分离,这对于软件开发者是不可取的.Darkstar项目就是由Sun公司实验室承担的一个将在架构的

《用户故事与敏捷开发》阅读笔记02

 <用户故事与敏捷开发>阅读笔记02       这周读了<用户故事与敏捷开发>的第四至七章,第四章讲述的是如何搜集故事,也就是如何正确的去找到用户需求.作者明确指出"引用"和"捕捉"是不合用的.所谓"引用"和"捕捉",我想是通过用户对功能的表述,开发人员从中获取需求信息吧.如果是这种方法来获取需求,正如作者所说,用户不会知道所有的需求,所以只靠着这方法是远远不够的.对于故事编写的数量以及程度,作者认为

ijkplayer阅读笔记02

ijkplayer阅读笔记02 1.在这一章主要介绍音视频解码和显示线程的创建和启动,直接贴代码如下: IjkMediaPlayer_prepareAsync{ ijkmp_prepare_async_l{ ijkmp_change_state_l(mp, MP_STATE_ASYNC_PREPARING); msg_queue_start(&mp->ffplayer->msg_queue); SDL_CreateThreadEx(&mp->_msg_thread, mp

《需求分析与系统设计》阅读笔记02

在对于<需求分析与系统设计>第一章的阅读中我知道一个项目的成型的大致流程,一个软件的生命周期以及在不同的阶段我们应该采用什么样的方法.在不同的生命周期阶段当中我们应该做些什么,应该注意什么.对于一个软件的开发的方法. 对于第二.三章的精读之后了解到学习对象技术的主要困难在于缺乏明确的出发点和清晰的研究途径.没有像我们曾经了解的自顶向下或自底向上的一种学习方法.学习面向对象技术是一种“从中间出发”的方法.对于一个对象,我们首先要先确认实例对象,并且区分实例对象和类对象.那么关于对象呢,我们需要掌

《构建之法阅读笔记02》

这次主要对<构建之法>的第四章“两人合作”作一次阅读笔记. 首先是代码规范问题. 我过去对于代码规范问题并没有做到注意.在编程中,许多变量和函数的命名都非常的简单而没有实际的意义.而且编程时不注意对齐缩进.很多时候也不加注释,导致对这些简单的变量名称不熟悉. 这样做会使得很多人读代码费劲,甚至是自己都要花时间再次阅读懂自己的代码.而且很多没必要的注释也会使得注释失去意义.当自己再次在原基础上编程时,可能要重新编程等问题. 因此,通过阅读“代码规范”,我找到一些解决方法.代码的风格要简明.易读.

&lt;&lt;需求分析与系统设计&gt;&gt;读书笔记之一

<<需求分析与系统设计>>这本书论述了软件分析和设计的迭代增量式过程,讨论软件分析与设计的原理,方法和技术,并特别关注了设计阶段,对软件体系结构的内容进行了很大的扩充.本书强调对象技术与统一建模语言UML在企业信息系统开发中的应用,并讨论了使用web技术和数据库技术进行开发的方法.这本书集中在面向对象软件开发上,统一建模语言用于捕捉建模的人工制品,主要论述用逐步细化的方式进行开发,并且在整个开发生命周期中都是用UML这种建模语言.系统分析师,设计师和程序员使用同一种语言和工具,但有

&lt;&lt;需求分析与系统设计&gt;&gt;读书笔记之三

终于把<需求分析与系统设计>读完了,感受很多,虽然理解还不是透彻,但还是学到了不少知识.在软件需求规格说明中,需要用图形和其他形式化模型来说明需求,为了完整地说明一个系统,有必要采取多种模型.UML提供了许多集成化的建模技术来辅助系统分析师来完成这项工作.规格说明的过程是迭代增量式的.对成功的建模来说,使用case工具是必须的.需求规格说明产生三种模型:状态模型,行为模型,状态变化模型.需求规格说明涉及需求确定期定义的客户需求进行严格的建模,重点放在那些系统将要提供的所期望的服务上.在规格说明

《UML大战需求分析》阅读笔记02

软件应能真正的对客户的工作提供帮助,只有客户使用并真正对其有用才能说我们做的软件成功了.客户从开始提出需求时到后期的工作过程中,需求总是不停变化的,所以这就需要需求人员对需求领先于客户.所以活用UML进行结构和行为建模,帮助我们更好的认识客户业务和做好业务流程再造工作.UML进行需求分析的过程: 搞清楚系统的目标和范围 找出该系统的所有关键涉众列出他们要解决的问题 分析业务,确认问题,发掘真正问题 针对问题,提出系统的特性 针对特性,提出系统的用例细化功能需求非功能需求 类图是用的最多的UML图

代码大全阅读笔记02

继续阅读代码大全这本书,感觉是好厚好难啃啊.刚刚开始读不久到了作者说把主要精力集中于构建活动,可以大大提高程序员的生产率.我想就一个项目来说,思路和设计是站着主导的地位的,你如果不能把思路理清,可能随时都有可能卡在那里,而一旦灵感来了,你就会想泉涌一样的来思路,我们也算是做了一个小的项目的了,虽然很low吧,但是好歹也算有点体会.我们总是在设计的时候会走投无路,不知所措,以至于每一次开始时都是没有思路起手都只能积压在那里,实在是不知道该怎么做.我觉得 P28 的那个食物链的例子更有说服力,健康的

人月神话阅读笔记02

贵族专制.民主政治和系统设计 本章主要是围绕着: 1.如何得到概念的完整性. 2.这样的观点是否要有一位杰出的精英,或者说是结构设计师的贵族专制,和一群创造性天分和构思被压制的平民编实现人员? 3.如何避免结构设计师产出无法实现.或者是代价高昂的技术规格说明,使大家陷入困境? 4.如何才能实现与实现人员就技术说明的琐碎细节充分沟通,以确保设计整备正确的理解并精确的整合到产品中? 就第一个问题文章是介绍的编程系统的目的是使计算机更加容易使用.对于功能,能够用最简洁的方式来指明事情的系统是最好的,对