几乎是计算机软件开发的发展历史
 
 
人月神话,增加人手并不一定能提高开发速度。

原因在于,有些任务是无法分解的,存在先后顺序。无法同步进行。

增加人手,增加的是沟通成本,相互牵制。可以分解的任务就可以通过增加人手来加快速度。但是不能分解的任务,增加人手只会增加开发时长。打个通俗比方,怀孕需要12个月,增加人手,也不能加快时间。

作者赞赏的是,小型精干的技术团队是最好的。沟通成本低,开发效率高。

厨师煎一个蛋,需要5分钟,而顾客期望2分钟。怎么都达不到,2分钟的办法是,把火开大可以快速点(类似于软件加班,多投入人),蛋会烧掉。

 
我们往往忽略了成员的沟通成本,培训成员的成本,拆解任务后,就变了,结果项目还是继续延长
已经延期的项目增加人手,会更加延期。分配任务,培训新成员的成本。
这方面的坑,前人遇到过了。
 
 
 
 
评估技术开发任务的复杂度和时长,容易凭着直觉
困难的预估不足。这是我们的问题。
做项目,任务的评估时间忽视了软件开发的特点,我们往往凭着直觉来评估周期。增加人手不能解决问题。
 
技术人员往往比较讨厌那种说"这个很简单"的人。他自己去做,被一个小bug栽跟头可能卡住很久
 
以后我们做时间预估的时候,就不要凭着自己想当然
我们自己做的时候,不会这样。等到位置变了,就想当然了。
 
 
这本书里面提到一个经验,调试和测试的时间花费是最多的。比开发写代码要多得多。
现在看来是这样,有时候为一个bug,调试,定位问题,耗费长时间。
 
 
 
 

建立一个组织架构,不要强调头衔。

具体的办法为:

1,叫负责人,而不是叫总监。叫法会造成心理的隔阂。负责人强调的是身上的责任和担子。将会促使人去干实事。

2,提供技术和管理两条发展路线。级别要一样,不应该有待遇差别。办公室的位置要一样,不要刻意显示地位差别。否则,技术人员都挤着想做管理(不安心钻研技术,因为级别和待遇低),而管理人员则显得自己地位的差别,技术人员的话语权就低了。

管理能获得更好的待遇(薪资、受尊重程度,各种权利和荣誉)。那么管理将会务虚不务实了。

3,技术人员向管理的转换,要以调动的名义,而不要以晋升的名义。这种调动时,待遇不要跟着变化,而应该不要变。

作者观点是:

对于一个广泛使用的程序,维护成本是开发成本的40%甚至更多。而且据发现,系统的用户数越多,发现的错误越多(我们想想windows常年打补丁进行更新)。

为什么会这样?用户数多,他们熟练使用旧功能后,就会使用新功能。于是就会发现新功能那些不容易察觉的问题。
修复bug,往往会引入新的bug。经常出现这样现象:前进两步(修复和完善两个地方),后退一步(引入一个新的缺陷)。

读到这个观点,程序员是不是深有共鸣?

我想,更关心的是如何解决这个问题?

……………………书中笼统而过解释了一下

为什么缺陷不能更彻底地被修复?首先,看上去很轻微的错误,似乎仅仅是局部操作上的失败,实际上却是系统级别的问题,通常这不是很明显。修复局部问题的工作量很清晰,并且往往不大。但是,更大范围的修复工作常常会被忽视,除非软件结构很简单,或者文档书写得非常详细。

其次,维护人员常常不是编写代码的开发人员,而是一些初级程序员或者新手。

作为引入新 bug 的一个后果,程序每条语句的维护需要的系统测试比其他编程要多。

理论上,在每次修复之后,必须重新运行先前所有的测试用例,从而确保系统不会以更隐蔽的方式被破坏。实际情况中,回归测试必须接近上述理想状况,所以它的成本非常高。

显然,使用能消除、至少是能指明副作用的程序设计方法,会在维护成本上有很大的回报。同样,设计实现的人员越少、接口越少,产生的错误也就越少。

……………………

作者已经帮我们归纳原因了,那么我们可以根据原因,依据自己项目中实际情况做改进。

原因:

1,修改系统的人不熟悉原来的系统。比如他是系统的新手。比如系统的维护人员,由于他并不是之前开发这个系统(功能)的人员,于是不熟悉系统,修改就会造成麻烦。
不熟悉,改了具备后会影响到哪个环节。

2,缺少评估修改系统后,产生的影响。大系统,修改功能,评估时间做足够点,重点不要放在评估开发时间上,放在修改局部造成哪些方面会影响。不要走形式。

3,系统缺乏必要的文档说明。造成接手的技术不知道来龙去脉,那么为了应付上级任务催促,就只能先改好再说,但是改了后出现问题了。

归纳对策

1、减少开发系统人员的波动。现实中这的确比较难,实际上根源并不是人员波动(因为人员不波动是理想状态而已),而是人员波动后造成的衔接故障问题。只要解决这个根本性问题即可。一个国家主席会有任期,没有不散的筵席。怎么保证国家政权的平稳过渡,有选举制度,按流程走。

2 、详细的文档,避免混乱。古代的经验,今天的人怎么继承的。靠的是古人的文字记载。

作者的观点:

杰出的设计人员应该与杰出的管理人员一样重要,受到的回报要一样,不仅仅是薪资待遇,要在认可方面一样:办公室规模、安排、人员支持等方面。这样才会有更多回报。

良好的设计人员和卓越的管理人员都是稀缺的。卓越的管理人员,绝不会比良好的设计人员更加迫切。

之所以那么重管理,那是传统的工厂活,因为是机械式的干活,不需要很强的创造力。而当面对高级人才的时候,这些高级人才往往是自我驱动型,对他们的管太多会造成情绪不爽的。

如何解释小型团队带来的好处。

维护系统比开发系统的成本更高。如何才能做到这样。

有些开发任务是没法拆分的,拆分后,反而效率不高。需要投入沟通时间,培训成员的时间。

这本书提出一个观点,成员多交流,定期交流,这样才能知道需求有没有偏差。

作者建议的几种搭配:

产品经理和技术总监是同一人。
产品总监总指挥,技术总监当其左右手。
技术总监总负责,产品经理做左右手。

为什么要这样子设计呢?好处是什么呢?

知道正确的办法。很多事情要回报。

老板的目标,如何培养人才,使得技术和管理人员可以互换。
提供两条晋升路线的办法,为什么存在一些社会性障碍。

为技术和管理人员建立相同薪资容易,建立相同的威信则需要很多措施。

项目经理的职责之一就是协调大家按照一致的方向前进。他的重要不是做在决策,而是沟通,沟通使得大家保持一致方向。

文档是作为沟通的渠道,让大家想法达成一致。文档减轻了沟通障碍。


有以文档记录下来,大家的分歧才会明朗,矛盾才会突出。因为文档往往是精确的,可以沟通的(相比口头语而言)。这里文档有个细化到什么程度的问题:什么事
情需要文档,什么事情不需要文档。我以为,重大或者关键性的决定口头说是不准确的,沟通看起来快(相互马上知道),但是要接地气实施目标困难。会出现沟通
偏差,误解,白做。

达到无为而治的情况。

 
 
 

的确是屁股决定脑袋

软件项目发展历史<人月神话>这本书好的更多相关文章

  1. 读书笔记第三周 人月神话 刘鼎乾 PB16070837

    读书笔记第三周:人月神话   这本书主要讲述了如何管理一个软件开发团队的问题,其中如何提高团队的效率可以说是本书的重点之一了.感觉这本书地中文版翻译得比较晦涩,很多表达比较模糊,看起来有些吃力,因此下 ...

  2. IT项目管理——《人月神话》读后感

    这也许是和候红老师的最后的几节课了吧,侯老师是一个很有思想深度,很关心同学的好老师. 一开学就布置了阅读<人月神话>的作业,说实话,我没有看,以我的速度可能2.3个小时就看完了,但是我觉得 ...

  3. 《The Mythical Man-Month(人月神话)》读后感(2)

    第10章 未雨绸缪 在化学领域中,在实验室可以进行的反应过程,并不能在工厂中一步实现.一个被称为“ 实验性工厂(pilot planet)”的中间步骤是非常必要的,它会为提高产量和在缺乏保护的环境下运 ...

  4. 《The Mythical Man-Month(人月神话)》读后感(1)

    临近考试周,这里我通过平时阅读的<人月神话>十九个章节和知乎.简书等网页中网友们对<人月神话>的读后感,对书中各个章节进行简单的总结,以下均为个人手打观点的思考与整合,仅供大家 ...

  5. <<人月神话>>阅读体会(一)

    第一次听说人月神话还是在大一上学期的导论课那会儿,那会儿好像就已经确定了自己要学软件,于是就去问王建民老师能不能给我推荐几本软件工程方面的书,我想要提前自己学学,以为老师会给我推荐一些某种语言类的学习 ...

  6. 《人月神话》读书笔记 PB16110698 第七周(~4.19)

    每逢读书笔记上交作业时刻,班级blog页面上总能看到<人月神话>相关的读书笔记,本次软工课邓老师推荐的第一篇读书笔记也是写的<人月神话>,算是对它“耳濡目染”了.本周,我终于抽 ...

  7. Java课程寒假之《人月神话》有感之一

    一.焦油坑 以前上课的时候,老师讲过早期的程序由于工作量不大,大多只需要几个人完成,随着软件规模的不断扩大,代码量直线上升,仅仅一两个人可能没有办法完成这样的任务,多以开始形成了团队的规模,焦油坑说的 ...

  8. 第八周读书笔记(人月神话X月亮与六便士)——到底什么才是一个程序员的自我修养?

    写了这么久的读书笔记,涉及到问题大多是一些如何把软件工程做好,如何把自己的职业生涯做好.但总感觉逻辑链上缺了一环,亦即:我们为什么要把软件工程做好,我们成为一名优秀的职业生涯的意义到底在于什么?我觉得 ...

  9. 《人月神话》读书笔记(2)-week3

    为了确保团队中的每个人都能保持系统概念上的完整性,关于项目的书面规格说明是必不可少的.手册要描绘用户可见的一切,但不应支配实现的过程.光有规格说明也是不够的,会议也是必要的.书中提到的周例会会迅捷地给 ...

随机推荐

  1. css基础总结一

    最近在弄一个简单管理系统的前端,所以打算将做项目的一些个人感想以及总结简单罗列下,当然,主要针对前端的基础部分以及一些常用的前端个人简单技巧总结.主要分为js部分和css部分,下面是css的基础部分总 ...

  2. 实现步骤: 推送&传感器&UIDynamic

    一.本地通知基本使用: #01.请求授权(8.0以前默人授权) #02.创建本地通知 #03.设置通知内容 #04.设置通知时间(多久后发通知) #05.发送通知 二.本地通知而外设置: #01.设置 ...

  3. Android开发之登录验证

    最近在做一个小项目,项目开发中需要实现一个登录验证功能,具体的要求就是,在Android端输入用户名和密码,在服务器端验证MySQL数据库中是否有此用户,实现之前当然首要的是,如何使Android端的 ...

  4. 关于Entity Framework中的Attached报错相关解决方案的总结

    关于Entity Framework中的Attached报错的问题,我这里分为以下几种类型,每种类型我都给出相应的解决方案,希望能给大家带来一些的帮助,当然作为读者的您如果觉得有不同的意见或更好的方法 ...

  5. 利用grunt-contrib-connect和grunt-connect-proxy搭建前后端分离的开发环境

    前后端分离这个词一点都不新鲜,完全的前后端分离在岗位协作方面,前端不写任何后台,后台不写任何页面,双方通过接口传递数据完成软件的各个功能实现.此种情况下,前后端的项目都独立开发和独立部署,在开发期间有 ...

  6. img[src*="same"]{}

    假如你有一组图片,你想选择其中一些名字中带有same的图片,那么你就可以用这种写法,这里的意思就是选择所有正确路径下名字中带有same的图片文件. 譬如说:me_same.png,you_same.p ...

  7. Spring MVC 对于@ModelAttribute 、@SessionAttributes 的详细处理流程

    初学 Spring MVC , 感觉对于 @ModelAttribute 和 @SessionAttributes 是如何被Spring MVC处理的,这一流程不是很清楚, 经过Google资料,有了 ...

  8. PHP访问MySql数据库介绍

    在网站后台,经常要与数据库打交道.本文介绍如何使用XAMPP来管理MySql数据库及如何用PHP来访问MySql数据库. 一.使用XAMPP来管理MySql数据库 首先使用XAMPP打开MySql的管 ...

  9. ASP.NET Core 开发-Entity Framework (EF) Core 1.0 Database First

    ASP.NET Core 开发-Entity Framework Core 1.0 Database First,ASP.NET Core 1.0 EF Core操作数据库. Entity Frame ...

  10. linq 实现动态 orderby

    class Pet { public string Name{get;set;} public int Age{get;set;} } void Main() { Pet[] pets = { }, ...