读书笔记《人月神话》

《人月神话》探索了达成一致性的困难和解决的方法，并探讨了软件工程管理的其他方面。

在刚刚进入软件工程学习时，老师就和我们说了一些关于“软件项目开发的完成与增加人员的问题”，这句话听起来通俗易懂，道理很简单明了，但实现起来却遇到了相当大的困难，这也是我在阅读完成《人月神话》时最大的感受。全书的第二章说的就是人月神话的关系。“一切都将运转良好”在软件工程中是不适用的；完成工作的人数与时间是不能进行简单的互换的，因为沟通需要额外的成本。我想这种问题的出现主要是就订单项目而言，因为人员的增加主要是因为客户所要求实现的东西并没有在计划的时间内收到满意的答复和应得的功能与效益。所以项目开发人员不断的增加，本书作者布鲁克斯得出的结论是显而易见的：“向进度落后的项目中增加人手，只会使进度更加落后”。如果不想加班，不想削减功能，不想推迟发布日期，那么唯一的方法还是只有加人。加足够的人。而且不要逐步加入，一定要一次性加入。要小心的是，新加入的人可能对原来的组织造成冲击，或者对原来的设计有不同意见，特别是我想如果如果有比较强大的设计者时就要当做新组建了一个团队。重新交流，培训新人，就设计达成一致，继续向者目标前进。这也是造成项目延迟的原因之一。软件开发的多少人参与和完成时间不成正比，过多的人参与并不一定能缩短开发时间。如战争，部队多，人多并不是关键，更多需要武器的先进，战术，兵多后方便的补给就得多。如是参与软件开发的人增加，软件的花费将提高，刚参加这需要时间了解项目，给软件管理带来了不协调。在我们实际进行软件开发的时候，各个成员之间要做好沟通协调，一个人开发软件虽然完整性会很好，但是效率太低；相反，团队开发虽然效率很高速度很快，但是如果各个成员之前没有很好地团结协作，各自为战，那么最后的结果也一定不会尽如人意。

进度问题是IT项目管理最为关注的问题之一。进度的可保证性和可控制性来源于项目计划的科学性，项目计划对进度预测的准确性又来源于估算的准确性，估算是否准确又涉及到项目规模，根据规模可以得到工作量，根据工作量和人力资源的投入和任务依赖约束可以得到最终的进度。当软件产品的规模增加的时候，复杂度成倍增长，从而导致这些要素之间不是单纯的线性关系，这是人月神话的启示之一；同时由于软件项目本身的生命周期模型和工序任务限制，导致对于一定规模的软件产品研发，无论投入多少的资源，都有一个最短工期的限制，在这个最短工期下投入再多的资源也没有用。

对于估算假设人月可以互换的问题是可以引入CocomoII估算模型来估算工作量和进度的，对于中小型产品和项目的估算更多仍然需要依靠专家的经验，对于大型项目则需要遵循一定的方法和估算模型。因此大型项目仍然强调的是首先要估算出软件产品的规模，规模结合生产率得到工作量，工作量结合进度安排和相关模型得到项目周期。当按照这种思路的时候我们就会有意识的去积累生产率，评审效率，缺陷密度等原始数据。估算的基础是用户需求，但往往我们就是在用户需求不明确的情况下盲目估算。对于企业信息化相关软件系统，对于全新启动和开发的产品估算往往是最不准确的，因为缺乏相关的历史数据，经验积累，估算参与人员也缺乏对业务和需求的深入理解。对于PSP个体软件过程的推广有利于提升估算能力，因为可以让开发人员更加准确的认识到自我的开发生产率。对于技术架构的完善和技术的积累有利于提高估算水平，因为技术越完善后期的技术研究任务越少，而技术研究往往是具有高度不确定性的任务。开发人员对所属业务领域的深入理解有利于提高估算水平，任何一个需求功能点中对规模和工作量影响最大的是业务规则的复杂性，而不是该需求所涉及到的UI界面和基本流程。

乐观主义假设一切都会运转良好，而不会遇到任何的风险和问题。而恰恰实际情况是在实际开发中遇到一个疑难问题耽误几天或一周的时间，虽然我们做了风险识别和分析，但仍然无法避免各种突发疑难问题的产生。通过PERT计划评审技术和三点法估算可以看到，如果我们完全按照对乐观方式来估算，能够按进度正常完成概率往往是0%，如果我们按照最悲观的方式估算也很难真正保证100%能够按期完成。如果我们按照最可能估算，我们期望达到80%的概率能够按期完成，这说明将进度偏差控制在20%的范围内，20%有可能是我们能够容忍的进度控制范围。

创造性活动包括了构思，实现和交流三个阶段。第一个构思本来就需要花时间，在开发活动中开发人员实际想的时间(想本身就是一种分析和设计活动)往往比实际敲代码行的时间多的多；第二构思本身是不完整的，在实现中要不断的验证和修改构思，这种不断的往复是需要花时间的，例如开始假设的某种代码实现方法行不通，不得不全部推倒构思新的算法来实现。还有大型系统会进行多层WBS分解，任务之间存在复杂的关联依赖关系，在路径汇聚点上任何一个任务的延期都将导致后续任务的延期。

用人月来衡量一项工作的规模是一个危险和带有欺骗性的神话，因为它暗示了人员数量和时间是可以相互替换的。(注:人月是用来衡量工作量的，规模是通过功能点或代码行等方式来衡量的，规模除以个体生产率后可以得到人月数据)。这里进一步来描述人月不能互换的原因，首先是任务能否拆解，及时能够分解任务间是否存在相互的依赖和约束，分解后是否增加会增加相应的沟通，以及由于分解任务而引入的分解和后期集成等额外的工作量。

假设人月可以互换，则为了缩减周期需要投入更多的人，为了让更多的人都有事可做就需要细分任务，细分任务自然增加了系统分解和后期集成的工作量，细分任务间无法避免的依赖和关联自然增加了沟通的成本和工作量。而且由于任务的细分需要引入文档等重量级的沟通工具，原始的需求信息在需求，设计，开发，测试等多个环节传递很难真正保证我们需要的概念完整性。

如果一个系统按功能点估算有200个功能点，按一个功能点200-300行代码计算，整个系统规模在5万行代码左右。这是一个中小型的项目或系统。如果按照总生产率80行/天计算，则总工作量在20人月左右。根据非线性关系我们可以估计理想情况或者说性价比最好的情况是投入5人4个月完成，当人数增加一倍时候进度只能压缩到3个月。当人数再增加到15个人的时候，进度压缩到2个月，这个时候增加再多的人就已经没有用了，对于这种规模的的系统，2个月可能就是进度极限了。

我们讲当规模增长的时候，工作量并不是非线性增长，周期也不是非线性缩短。其中工作量的增加前面已经讲了第一个重点增加在了系统分析设计，需要将复杂的系统进行分解；其二在后期集成和测试，需要将分解的各个功能模块集成和组装。对于产品规模增加的时候，对于详细设计和编码阶段工作量可以任务是一种线性的增加，非线性部分指数增加的工作量都体现到了前期的分析设计和后期的集成和测试上面。

当我们假设是线性的时候，我们主观的去缩减了这两头的工作量。如何缩减了系统分析和总体设计的工作量，则可能带来整个产品结构的不稳定，后果往往是整个产品推倒重来；如果缩减了后期集成和测试的工作量，则不可避免的是导致项目延期。乐观主义者喜欢假设我们开发的是零缺陷的系统，但对复杂的软件系统而言这仅仅是个神话。

用人月这一观念来衡量项目进度带有欺骗性。因为他使得项目看上去好像人力和时间是可交换的。如果时间不够，那么增加人手就可以加快进度。但是这个衡量方式忽略了新增加人手的培训时间、队员之间的沟通时间等等因素，结果就是，盲目的增加人手只会导致项目落后。所以问题是，如何使得项目进度不落后；要想使得项目进度不落后，就要制定出合理的项目进度。所以，问题是，如何制定出合理的项目进度。