如何高效交付项目--《人月神话》读感2

之前一直要总结高效的研发团队，正好最近再读《人月神话》，今天结合书中内容一并来说说。

以前的观点：

高效的团队由高效的个人组成，高效的团队才能完成高效的项目交付。

新的认知：

高效的项目交付才是结果，而能够进行高效交付的团队未必是高效团队，这个团队中的个人也不一定得是高效人士。其核心在于降低延期的各项风险值，而不是非得每个人都优秀。

1. 研发项目为什么会经常延期？

在软件研发项目中，缺乏合理的进度安排是造成延期最主要的原因，这比其他所有因素加起来影响还要大。这个灾难是怎么发生的呢？

1.1. 所有编程人员都是乐观主义者

所有系统的进度安排背后第一个错误的假设是：一切都将运作良好，每项任务仅需要花费它“应该”花费的时间。对于创造者，只有在实现的过程中，才能发现我们构思的不完整和不一致性。

编程人员通过非常纯粹的思维活动构思程序，所以很容易自信的认为实现过程中不会遇到困难。然而我们的思维是有缺陷的，项目越大，能够按照计划顺利进行的概率就越小。

1.2. 人月是一个隐性的谎言

在估计和进度安排的过程中使用“人月”作为工作量单位是十分荒谬的，是一个带有危险和欺诈性的神话，他暗示着人员数量和时间可以相互替换。然而人数和时间的互换仅仅适用于，某个任务可以分解给参与人员，并且他们之间不需要相互交流的情况。

当任务不能分解时，人手的添加对进度没有任何帮助，大多数编程工作都具有这种特征。就像你无论找几个妈妈，孕育一个生命总是需要10个月的时间。

Brooks法则：为进度落后的项目增加人手，只会使进度更加落后。

对于可以分解的情况，增加人手可以加快进度，但是会提高成本，2个人的效率可能仅等于1.5个人。原因在于沟通、培训、交流等事物增加了工作量，而且所增加的工作量可能会完全抵消任务分解所产生的作用。

软件开发作为一项系统工作，沟通、交流的工作量非常大，它会快速消耗任务分解所节约下来的时间。

1.3. 系统测试都过于短了

系统测试进度的安排往往是编程中最不合理的部分，都过于短了。很少项目允许为为测试分配一半的时间，然而大多数项目的测试实际上是花费了进度中一半的时间。不安排足够的测试时间将会是一场灾难，由此造成的项目延期成本高昂，在早期规划时，保留充分的测试时间非常重要。

作者建议的进度安排：

1/3 计划
1/6 编码
1/4 构建测试和早期系统测试
1/4 系统测试，所有的构建已完成

1.4. 管理人员往往比开发人员更加乐观

管理人员很容易会认为项目功能完成就意味着开发完成了，没有为测试阶段安排较长时间的意识，往往测试的时间只能占到项目周期的1/8甚至更少。这明显是犯了乐观主义的错误，项目管理人员甚至比开发人员更加乐观。

如果不是站在专业的角度上，似乎很难理解测试阶段所花的时间，更难理解的是为什么增加人手不能让项目进度加快。

2. 如何更准确的进行时间评估？

2.1. 不能简单的使用系数进行计算

仅仅通过对编码部分时间的估计，然后乘以其他部分的相对系数，是无法得出对整项工作的精确估计的。

比如编码预计要用1个月的时间是推不出总体用时6个月的。

2.2. 构建独立小程序的经验不适用与大系统项目。

独立小型程序的案例数据可能不适用于系统的产品，这就像不能通过统计百米短跑纪录得出人类可以在3分钟内跑完一英里的结论一样。

2.3. 程序开发随着程序规模的大量增长而增长。

刚才说的编码预计要用1个月，总周期是可能大于6个月的，因为书中作者提出了编程总体工作量和程序规模之间显示出的关系是指数关系，指数值在1.05到1.2之间。也就是随着程序规模的增加，编程工作量的增长量也会增长。

3. 改善项目交付的效率

结合这部经典和敏捷的方法论，总结了一下几个点来进行项目交付效率的提升。

3.1. 重要文档先行

《人月神话》的作者非常看重文旦，认为优质的文档就是项目成功的保证。虽然这一观点与敏捷方法的观点有所出入，但不可否认我们现在的工程师对于文档编写缺乏激情，而文档的缺失也给后期加入和新人和功能修改带来复杂度。

敏捷不等于不要文档，文档也未必需要事无巨细的记录。对于我们而言，重要的文档必须输出，如带有描述的产品原型文档，拥有实体、接口和数据库定义的系统设计文档， 还得有相应的测试用例，发布程序时的发布记录。

对于一些重复性强的工作、经验性强的工作，需要整理成执行清单，这样下次的执行按照清单进行即可。对于清单不要担心写的不够完善，因为清单往往需要经过实践的检验，而在检验的过程中自然就会完善起来，不过前提还是需要重视文档，这样清单才能得到及时的更新。

3.2. 显性的进度表

我们现在采用了显性化的里程碑进行项目进度沟通，但这些里程碑以结点为主，缺少过程的显性化，最好再增加一个进度表，由大里程、小里程及完成时间组成，并且记录真是的进度情况？不可模棱两可。

3.3. 使用高效的语言和框架

• 对于常用的编程语言，生产率似乎是固定的
• 使用适当的高级语言，编程的生产率可以提高5倍

这点我们在改善，但是还不够，特别是在语言的突破上局限性太大。

3.4. 主动沟通但要减少无效沟通

随着敏捷思想的贯彻，大家的沟通也频繁了起来，但是目前的沟通询问偏多，主动偏少，后面要让主动沟通更多一些。

减少无效沟通，沟通之后要有结论和输出。比如目前一些沟通是在抛问题，抛完问题沟通也就结束了，可这种沟通对于实际工作并无益处，反而浪费了时间。

3.5. 有效的人员分配与赋能

完成一个项目往往不是一个人的事情，需要多工种、多成员的密切配合，有效的配合将带来高效的回报。

但是人员的分工、分配不等于责任的划分，因为项目是一个整体，项目的整体交付结果才是团队的输出结果、每个人的结果。一定不能存在项目整体很糟，但某个人确非常优秀，项目的荣辱就是每个项目成员的荣辱。

对于团队来讲，赋能也是非常、非常重要的点，通过赋能不仅能够减少管理者的工作量，更能够让普通成员肩负起项目交付的单子更好的成长。但是赋能不可以是甩锅，特别对于成长中的队友，要在关注，要在关键时刻推一把。

软件系统与计算机、建筑或者汽车大不相同，后者往往存在着大量重复的部分，而前者需要我们投入大量的思考和实践来寻求正确的路线。本次读《人月生化》又有不少的收获，感谢布鲁克斯留给我们的宝贵财富。