软件项目发展历史<人月神话>这本书好

时间:2021-09-15 16:58:38
几乎是计算机软件开发的发展历史
人月神话,增加人手并不一定能提高开发速度。

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

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

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

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

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

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

具体的办法为:

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

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

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

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

作者观点是:

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

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

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

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

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

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

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

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

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

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

……………………

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

原因:

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

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

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

归纳对策

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

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

作者的观点:

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

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

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

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

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

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

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

作者建议的几种搭配:

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

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

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

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

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

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

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


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

达到无为而治的情况。

的确是屁股决定脑袋