人月神话-人月

人月神话

         读前,完全不知道应该从这章中会得到点什么.

         缺乏合理的进度安排是造成项目滞后的最主要原因；

1. 对技术缺乏有效的研究,”一切都将良好运行”的美好假设；
2. 采用的估算技术隐含的假设人和月可以互换，错误的将进度和工作量相互混淆。不止人月,人和人互换的代价也是惨重的。
3. 由于对自己的估算缺乏信心，软件经理通常不会有耐心持续的估算这项工作。说到痛点了。
4. 对经度缺少跟踪和监督，理想中经度应该被跟踪程序应该被监督，通常软件开发经理同时也是核心开发，很少专注于做这意见事情。
5. 当意识到进度偏移时，下意识的反应是增加人力。我觉得很多项目坏在频繁的人员调动和研发经理未能充分的履行其职责。

乐观主义

         计算机还很年轻，程序员更加年轻，而年轻人总是些乐观主义——无论是什么样的程序，结果是毋庸置疑的：“这次它肯定会运行”，或者“我刚刚找出最后一个错误”。

系统编程进度安排背后的一个错误的假设是：“一切都将运作良好，每一项任务都应该花费它锁应该花费的时间”。

         我们的骄傲使判断带上了主观主义色彩。 技术开发过程中自己也做了不少错误的决策,能有效纠正的还是果断决策了,通常都是付出一些大多数人不知道的代价。

         单个任务中”一切都将运转正常”的驾驶在进度上具有可实现性,大型的编译工程，或多或少包含了很多任务,某些任务还有前后次序,从而一切正常的概率变得非常小。

人月

         第二个谬误的思考方式是在估计和进度安排中使用的工作量单位:人月。成本的确随着开发产品的人数和时间不同，有着很大的变化,进度却不是如此。

人月互换仅仅适用于以下情况：某个任务可以分解给参与的人员,并切他们之间不需要互相的交流，编程系统中近乎不可能。

由于次序上的限制不能分解时,人手的添加对进度没有帮助。

对于可以分解,但子任务之间需要相互沟通和交流的任务,必须在计划工作中考虑沟通的工作量,在相同人月前提下，采用增加人手来减少时间得到的最好情况，还是比未调整前差一些

沟通所增加的负担：培训和互相的交流；相互之间的交流情况可能更糟,可能会出现由于人员的增加时间反增加的情况。

错综复杂关系下的一种实践,沟通、交流的工作量非常大,会很快消耗任务分解锁省下来的个人时间,从而添加更多的人手，实际上是延长了而不是缩短了时间进度。

总结一下,通常情况下一个处于最佳状态的团队才具有最高的性价比,在需要提高成本以缩短研发时间，需要综合考虑各种因素，低效因团队扩张带来的沟通交流时间远远大于任务分解节省的时间。

系统测试

         系统测试进度的安排常常是是编程中最不合理的部分。软件任务进度安排有以下经验法则:

         1/3计划

         1/6编码

         1/4构建测试和早期系统测试

         1/4系统测试,所有构建已完成

         很少有项目允许为测试分配一半的时间,但大多数项目实际上是花费了进度中一半的时间。

         允许充分的测试时间是必要的，降低软件问题暴露到客户和项目经理面前，即将发布时时出现延误,所付出的二次商业代价是非常高昂的。

空泛的估算

         经常为了满足客户期望的日期而造成不合理的进度安排.

         开发并推行生产率图表,缺陷率图表,估算规则等。

重复产生的进度灾难

         项目的时间依赖于顺序上的限制,人员的最大数量依赖于独立子任务的数量.从这两个数值可以推算进度表,该表安排的人员较少,花费的时间较长。相反分派较多的人手,计划较短的时间,将无法得到可行的进度安排。

总结

         开发经理,更应该关注任务计划制定的是否合理,项目进度是否可把控,其中最重要的是理解”人月”关系。开发计划的制定应该考虑各种因素,安排一个较为合理的开发计划,对于不可拆分的项目来说盲目的投入人力就是“灾难”。

         在研发进度失控的情况下,应该果断协商做出决策而不是盲目持续投入更多的“人月”，以至于产生“重复的进度灾难”。

      案例1：

四人团队计划完成某系统的重构工作,因为忽略了人员状态问题,导致出了一份不可行的计划,整体上表现出以下困境:

1. 编程规范不统一,程序员产出标准不一
2. 开发经理后提供开发规范,团队成员未正确理解意图
3. 代码质量不一,开发经理扮演架构师的决策却未能履行架构师是职责,导致后续出现的二次编码,以及在已开发完成模块的妥协
4. 人员不稳定,从最初的两个到三个到四个在到三个在到两个最后到一个。

宏观上总结了出了以下困境:

1. 开发经理急于求成,指定开发计划时忽略了程序员个体差异的重大因素，在设计未明确的情况下进行进行研发本就是风险。
2. 产品层面业务场景定义不明确,重构仅体现在后端架构和技术栈上对业务没有实际价值
3. 开发人员兼顾架构设计,未对架构说明、编程规约进行系统培训。
4. 成员有远程办公场景,交流不便,协作上的问题很难第一时间进行有效沟通
5. 新加入成员不熟悉当前系统开发规范,出现二次编码问题效率低下,不熟悉当前系统业务流程。