人月神话-职业的乐趣和IT项目管理（210131）

个人从06年开始写新浪博客的时候取名人月神话，即来自于布鲁克斯这名《人月神话》书籍，一本偏软件工程和IT项目管理的实践总结。当你真正做过大量IT项目建设和实践后，你越会体悟到这本书里很多内容的经典。

今天准备对该书的内容做下重新整理。

首先看下网上对该书的一个最基本的内容简介如下：《人月神话》探索了达成一致性的困难和解决的方法，并探讨了软件工程管理的其他方面。该书既有很多发人深省的观点，又有大量软件工程的实践，为每个复杂项目的管理者给出了自己的真知灼见大型编程项目深受由于人力划分产生的管理问题的困扰，保持产品本身的概念完整性是一个至关重要的需求。

人月的启示

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

进度问题是IT项目管理最为关注的问题之一，到了第二章人月神话开始讲进度问题。进度的可保证性和可控制性来源于项目计划的科学性，项目计划对进度预测的准确性又来源于估算的准确性，估算是否准确又涉及到项目规模， 根据规模可以得到工作量，根据工作量和人力资源的投入和任务依赖约束可以得到最终的进度 。

当软件产品的规模增加的时候，复杂度成倍增长，从而导致这些要素之间不是单纯的线性关系，这是人月神话的启示之一；同时由于软件项目本身的生命周期模型和工序任务限制，导致对于一定规模的软件产品研发，无论投入多少的资源，都有一个最短工期的限制，在这个最短工期下投入再多的资源也没有用。

开篇仍然在谈估算的问题，对于估算假设人月可以互换的问题是可以引入CocomoII估算模型来估算工作量和进度的，对于中小型产品和项目的估算更多仍然需要依靠专家的经验， 对于大型项目则需要遵循一定的方法和估算模型。 因此大型项目仍然强调的是首先要估算出软件产品的规模，规模结合生产率得到工作量，工作量结合进度安排和相关模型得到项目周期。当按照这种思路的时候我们就会有意识地去积累生产率，评审效率，缺陷密度等原始数据。

估算的基础是用户需求，但往往我们就是在用户需求不明确的情况下盲目估算。

对于企业信息化相关软件系统，对于全新启动和开发的产品估算往往是最不准确的，因为缺乏相关的历史数据，经验积累，估算参与人员也缺乏对业务和需求的深入理解。对于PSP个体软件过程的推广有利于提升估算能力，因为可以让开发人员更加准确的认识到自我的开发生产率。 对于技术架构的完善和技术的积累有利于提高估算水平，因为技术越完善后期的技术研究任务越少，而技术研究往往是具有高度不确定性的任务 。开发人员对所属业务领域的深入理解有利于提高估算水平，任何一个需求功能点中对规模和工作量影响最大的是业务规则的复杂性，而不是该需求所涉及到的UI界面和基本流程。

乐观主义

乐观主义假设一切都会运转良好，而不会遇到任何的风险和问题。而恰恰实际情况是在实际开发中遇到一个疑难问题耽误几天或一周的时间，虽然我们做了风险识别和分析，但仍然无法避免各种突发疑难问题的产生。

通过PERT计划评审技术和三点法估算可以看到，如果我们完全按照对乐观方式来估算，能够按进度正常完成概率往往是0%，如果我们按照最悲观的方式估算也很难真正保证100%能够按期完成。如果我们按照最可能估算，我们期望达到80%的概率能够按期完成，这说明将进度偏差控制在20%的范围内，20%有可能是我们能够容忍的进度控制范围。

创造性活动包括了 构思，实现和交流 三个阶段。

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

人月神话

用人月来衡量一项工作的规模是一个危险和带有欺骗性的神话，因为它暗示了人员数量和时间是可以相互替换的。

这里进一步来描述人月不能互换的原因，首先是任务能否拆解，及时能够分解任务间是否存在相互的依赖和约束，分解后是否增加会增加相应的沟通，以及由于分解任务而引入的分解和后期集成等额外的工作量。

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

如果一个系统按功能点估算有200个功能点，按一个功能点200-300行代码计算，整个系统规模在5万行代码左右。这是一个中小型的项目或系统。如果按照总生产率80行/天计算，则总工作量在20人月左右。

根据非线性关系我们可以估计理想情况或者说性价比最好的情况是投入5人4个月完成，当人数增加一倍时候进度只能压缩到3个月。当人数再增加到15个人的时候，进度压缩到2个月，这个时候增加再多的人就已经没有用了，对于这种规模的的系统，2个月可能就是进度极限了。

系统测试

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

当我们假设是线性的时候，我们主观地去缩减了这两头的工作量。

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

对于大型项目，书中给出了推荐的工作量比例分布(计划1/3,编码1/6,单元测试和集成测试1/4,1/4系统测试)。很少有项目为测试分配一半的周期和时间，也很少有项目真正只给编码分配1/6时间。根据个人实际软件项目开发的经验，大概的经验数据是(需求1/4，设计实现1/2,测试1/4)。中小型项目能够分配到1/4的测试工作量已经是比较大的一个值，这意味着一个10人左右的团队需要配置2个专门的测试人员)。

进度灾难

简单、武断地重复一下Brooks法则： 向进度落后的项目中增加人手，只会使进度更加落后。（Adding manpower to a late software project makes it later） 。

这就是除去了神话色彩的人月。项目的时间依赖于顺序上的限制，人员的数量依赖于单个子任务的数量。从这两个数值可以推算出进度时间表，该表安排的人员较少，花费的时间较长（唯一的风险是产品可能会过时）。相反，分派较多的人手和计划较短的时间将无法得到可行的进度表。总之，在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还要大。

当进度出现严重问题时候最有效的方法仍然是消减任务，与其交付10个不可用的功能点，还不如交付5个优先级高的功能点。

其二进度落后的时候，盲目的加班往往是无济于事的。按照时间管理的方法论，你越忙的时候你越该停止下来，好好地反省究竟慢在哪里，瓶颈和根源究竟在哪里，只有当问题的根源真正被挖掘出来和解决后，才可能真正提高效率和加速度。

对于进度落后的问题根源，我们可以做如下考虑。

需求本身频繁变动而且不受控，开发频繁的修改和返工，全是无效工作量。
开发人员技能本身问题，或者是开发效率低，或者是对业务需求理解不深。
开发人员自身的态度和责任感，是否有一种能够刺激他们潜在创造激情的氛围。
没有一个安静专注的环境，经常被各种无意见的会议，电话和琐事打断。

我仅仅是列出了几个常见的问题场景，不管是哪种问题，最终都会归结到改善过程和更多的关注团队和人两方面。