人月神话职业的乐趣和IT项目管理

　　个人从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个优先级高的功能点。
　　其二进度落后的时候，盲目的加班往往是无济于事的。按照时间管理的方法论，你越忙的时候你越该停止下来，好好地反省究竟慢在哪里，瓶颈和根源究竟在哪里，只有当问题的根源真正被挖掘出来和解决后，才可能真正提高效率和加速度。
　　对于进度落后的问题根源，我们可以做如下考虑。需求本身频繁变动而且不受控，开发频繁的修改和返工，全是无效工作量。 开发人员技能本身问题，或者是开发效率低，或者是对业务需求理解不深。 开发人员自身的态度和责任感，是否有一种能够刺激他们潜在创造激情的氛围。 没有一个安静专注的环境，经常被各种无意见的会议，电话和琐事打断。
　　我仅仅是列出了几个常见的问题场景，不管是哪种问题，最终都会归结到改善过程和更多的关注团队和人两方面。焦油坑
　　岸上的船儿，如同海上的灯塔，无法移动。 - 荷兰谚语
　　焦油坑的意思说明了即使你足够强大，也无法摆脱束缚而沉到坑底。
　　IT项目也是这样，不论是开发大型软件系统还是小型项目，都会遇到诸多复杂的问题和影响因素，项目本身就是一个足够复杂的动态系统，没有最优，只有满意。项目四要素，人员，组织环境，干系人，外部依赖和约束，风险和假设，团队，人等诸多问题都是你必须要考虑的问题，任何一个要素出现大的差错都可能导致项目失败，只有所有要素能够平衡好，团队能够协调一致才能够保证项目成功。
　　通过编程系统的演进可以看到简单的程序已经不能称作为系统，编程系统+编程产品才构成了编程系统产品，编程系统产品的复杂度将是一般程序的9倍。复杂度的增加就更好地说明了规模和工作量，工作量和项目周期之间都不是简单的线性增长关系，和第二章人月神话打下伏笔。
　　回头再看大型系统复杂度和工作量成倍增长的原因：
　　1.对于复杂事物我们需要去描述清楚，需要自顶向下逐层细化，这个系统分析和建模的过程需要耗费我们大量时间。当系统被分解为子系统->模块->组件后，后续我们为了完成产品还需要将它们集成在一起，这个集成过程仍然需要花费大量的时间。系统越复杂前期分析建模和后期集成的时间越多。
　　2.系统越复杂越涉及到更多的人参与来共同完成，导致人员间协同和沟通成本的增加。人员的分工越是细化，越引入更多的沟通和集成的工作量。一工序的增加使我们更加强调过程管理，我们会花费更多的时间来保证概念完整性。
　　职业的乐趣
　　兴趣是最好的老师，软件开发是一项相互协作的游戏，大家必须有兴趣为共同的目标而奋斗。对于软件开发职业乐趣首先体现在程序员是在创造产品，而且自我创造的产品会被用户使用，为客户带来价值。因此要尽量避免项目中途夭折，或者最终开发出的产品被抛弃的厄运，这会打击到程序员的积极性和对创造的渴望。
　　一个软件产品如果是一个人被封闭在一个孤立的环境里面做，他可能是体会不到更多的快乐的，职业的乐趣也来源于团队成员间的沟通和交流，相互协作。不管是自己的问题被解答，或者解答了他人的问题，程序员都会感到快乐。
　　学习的过程可能是枯燥的，但是学习后的成果能够帮助你解决实际的问题，你能够通过学习来创造软件产品，从这个意义上讲学习的是快乐的。学习的过程就是自我提高的过程，也是自我价值得以展示的过程。
　　从职业的乐趣这个意义上讲，IT项目管理者需要去激发团队成员意识到这点，这里涉及到沟通，团队建设活动，学习和培训诸多内容。让每个人都感受到他们被重视，而且共同在做一件有意义的事情，通过做这个事自己得到乐趣，得到了提升。
　　职业的苦恼
　　程序员往往不喜欢受到太多的依赖和约束，也不喜欢繁琐的规程和文档，特别是这些文档没有体现出真正的价值的时候。还有他们可能并不喜欢修改自己的Bug，更不细化修改他人遗留下来的Bug,因此这种重复性的工作让他们体会不到创造性的乐趣。还有最大的苦恼往往更在于辛苦开发出来的系统不能真正使用而被抛弃。
　　还是有太多的程序员和管理者认为编码是一种没有创造性的活动，他们理想化地认为需求和设计可以做得足够详细，编码仅仅是一种体力劳动，这是对每一位程序员的不尊重。处于最后一道工序的编码人员，他们产出的代码最终形成的形成了软件系统和产品，当他们的价值往往并不能得到相应的承认。
　　类似帕金森定律中的金字塔上升想象，每个人都很忙但组织效率却越来越低，每个人都在往上走，导致在每个岗位角色上都难得到技能过关高效率的人员。
　　IT项目管理者需要致力于改善这些苦恼，这里面一方面是绩效机制的改善，一方面是适当的过程保证。项目管理者带领项目取得成功不仅仅是体现了自我价值，也让团队每个团队成员意识到他们存在的价值和贡献的力量。外科手术队伍
　　在开发小组中，最好和最差人员生产率比在10:1，在运行效率和空间上5:1惊人差距。如果一个200人的项目中，有25个最能干和最有开发经验的项目经理，那么开除剩下的175名程序员，让项目经理来编程开发。
　　对于一个软件项目，适合的项目团队规模在20人左右，这是一个专职的IT项目经理可以管理的最大值。那由于项目进度压力需要增加团队规模到100人的时候，让项目经理来开发实际操作是很困难的方式。
　　在这里推荐的方式是将系统按照高内聚，松耦合分解为5个子系统。这样则可以将100个分解为5个项目，由5个项目经理来管理，这是减少和有序化沟通渠道最有效的方式。
　　小型敏捷的中小型团队可以保持最高的效率，但对于大型软件系统却不得不投入更多的人力资源来换取进度的提前。对于一个软件产品，在激励的竞争下对进度要求是非常严厉的，往往推迟半年推出都有可能失去竞争和市场，更不用说10年。对于信息化软件产品我们更强调的是迭代和多版本开发概念，每个迭代周期在1-2月左右，每个迭代周期都是真正可以向用户提供完整的可交付的功能。
　　外科手术队伍的目的仍然是为了提高整体效率，要达到这个目的就需要分清主次，由外科医生和副手主体人员复制解决问题和保持概念完整性。将有经验的首席程序员真正能够解放出来，让他们能够真正的专注于产品和程序实现。外科医生和副手构成了整个团队的核心，副手不是简单的打杂人员，而是外科医生的后备和左右手，他们在经验丰富后就可以升任为外科医生。
　　对于企业管理信息系统软件开发和大型操作系统的开发有一些差异，跟业务相关密切的信息系统会更加强调需求的重要性，需求分析也是系统分析的重要内容。
　　因此一般会划分出专门的需求分析人员这种角色，或者说将需求和总体设计合并为系统分析员角色，当我们理清楚了业务架构和技术架构后，后续实现就变得简单。
　　对于队伍如何运作的问题，外科医生和副手是核心保证高度的概念完整性，跟传统按生命周期阶段来分角色的团队相比，我们可以看到一个显著的差别就是流水线式的沟通方式朝扁平的总线式沟通方式转化。这种方式沟通更加高效，同时概念完整性更加容易保证，当出现冲突的时候外科医生具有绝对的权威。
　　一位首席程序员、类似于外科手术队伍的团队架构提供了一种方法—既能获得由少数头脑产生的产品完整性，又能得到多位协助人员的总体生产率，还彻底地减少了沟通的工作量。
　　团队的扩建
　　扩建过程的成功依赖于这样一个事实，即每个部分的概念完整性得到了彻底的提高—决定设计的人员是原来的七分之一或更少。所以，可以让200人去解决问题，而仅仅需要协调20个人，即那些＂外科医生＂的思路。
　　对于协调的问题，还是需要使用分解的技术。在这里，可以认为整个系统必须具备概念上的完整性，要有一个系统结构师从上至下地进行所有的设计。要使工作易于管理，必须清晰地划分体系结构设计和实现之间的界线，系统结构师必须一丝不苟地专注于体系结构。总的说来，上述的角色分工和技术是可行的，在实际工作中，具有非常高的效率。
　　这里所讲到的重点就是体系结构设计师要抽取出来组成核心设计团队，其他人员是实现人员，这样沟通的范围将限制到到这20个人的核心团队中，以保证高度的概念完整性，大大的提高沟通效率。贵族专制和民主政治
　　专制-高度的概念完整性
　　在这个章里面一个最重要的关键词就是概念完整性，不论你软件项目规模的大小都，不论你采取的软件生命周期方法论，我们都不要忽视了总体架构设计这个过程，而总体设计的一个重点就是概念完整性。
　　概念完整性是系统设计首要考虑的内容，为了反映一系列连贯的设计思路，宁可省略一些不规则的特性和改进，也不提倡独立和无法整合的系统，哪怕它们其实包含着许多很好的设计。
　　如何保证概念完整性，首先提到的就是系统设计要掌握到一个人少数已经互有默契的人员来实现。
　　举个简单的例子如做网页设计，某一个人的设计可能配色和风格并不是最好，但是由于是一个人他可以保持整个系统和页面风格的统一，这比多个人设计搞的五花八门要好的多。
　　在现在软件系统的易用性越来越成为我们关注的内容，对于给定级别的功能，能用最简洁和直接的方式来指明事情的系统是最好的。而简单和直白正来自于概念完整性，这让我们对概念完整性进行了拓展，一个是涉及到功能和非功能性需求的系统架构设计，一个是涉及到用户交互和界面的交互设计，这两方面都是概念完整性的内容，随着专业化的分工，这两方面概念完整性的保证往往要分配到两个独立的角色来完成即：架构设计工程师和交互设计工程师，因此这两个人之间的沟通和协作就显得更加重要了。
　　总体架构设计的重点就是理清楚整个系统的骨架和体系结构，架构设计是从实际的需求到抽象的实现之间重要的衔接。体系结构描述的是发生了什么，而实现描述的是如何实现。
　　民主政治-从开放包容到统一
　　贵族专制和民主政治并不是否定民主和大家共同的智慧的力量，而是最终的合并和统一决策权力要高度统一，团队成员有的创意和意见仍然可以积极的反馈。但是系统架构师必须要注意到，他是为整个系统负责，而不是对系统的某个独立的功能模块负责，我们需要的不是头脑发达却四肢不健全的人，这是让大家无法满意的。因此不能和系统的基本概念进行整合的想法和创意，都必须暂时放在一边。
　　为了解决在需求和架构阶段，大量编码人员的等待问题，我们现在已经很少采用真正意义上的瀑布模型，而是采用增量和迭代开发的生命周期模型。
　　对于传统的大型软件项目和外包项目，它们完全可以在完成了所有的需求和架构设计后在开始编码的外包或者雇佣相应的编码人员，但是对于周期较短的中小型项目，人力资源始终是在项目内的。
　　为了解决这个问题在前期需求和架构阶段，可以提前开始一些相关技术预研和公用组件的开发，提前进行业务的熟悉；但是为了真正的解决项目人力资源的有效使用的问题，我们往往引入了多个项目进行多项目管理，各个项目的各个生命周期阶段往往错开，A项目的在需求阶段的时候往往B项目正处于开发阶段，这样往往才能够真正的达到项目人力资源的充分使用和提高绩效。
　　最后对本章做一个总结如下：1.概念完整性是系统设计中最重要的考虑因素
　　2.为了获得概念完整性，设计必须由一个人或者具有共识的小型团队来完成
　　3.无论项目实际规模的大小都必须要考虑概念完整性的高度统一
　　4.纪律、规则对行业是有益的
　　5.概念上统一的系统能更快地开发和测试。
　　6.体系结构、设计实现、物理实现的许多工作可以并发进行画蛇添足
　　画蛇添足就过分设计，而书中很明确地指出了过分设计往往出现在设计和开发第二个系统的时候，对于第一个系统他们小心谨慎，倾向于精炼和简洁，但是到了第二个系统他们太想去追求完美，又加上盲目的自信，再加上没有太多的成本和进度等意识，导致了画蛇添足和过分设计。
　　项目经理如何避免画蛇添足（second-system effect）？他必须坚持至少拥有两个系统以上开发经验结构师的决定，同时保持对特殊诱惑的警觉，他可以不断提出正确的问题，确保原则上的概念和目标在详细设计中得到完整的体现。
　　在我们常见的软件开发中，类似画蛇添足和过分设计的例子有:1.完全根据自己主观思维，花哨的界面和不适用的功能。
　　2.过分和过度的考虑系统的可扩展性而成倍加大系统复杂度。
　　3.没有项目目标意识，追求完美的系统，但是无法达到项目预期的进度和成本目标。
　　4.没有迭代和渐进的思路，老想一次就尽善尽美，结果往往确实难产
　　5.自我欣赏和盲目自信，完全沉醉到技术的乐趣而忘记了产品创造价值本身沟通-巴比伦塔的失败
　　据《创世纪》记载，巴比伦塔是人类继诺亚方舟之后的第二大工程壮举，但巴比伦塔同时也是第一个彻底失败的工程。为何拥有了清晰的目标，充足的人力和物力资源的项目最后仍然失败，巴比伦塔给我们的管理教训就是它们缺乏沟通和交流，以及交流的结果-组织。他们无法相互交谈，从而无法合作。当合作无法进行时，工作陷入了停顿。通过史书的字里行间，我们推测交流的缺乏导致了争辩、沮丧和群体猜忌。很快，部落开始分裂——大家选择了孤立，而不是互相争吵。
　　沟通是整个项目团队的核心要素，关于项目的共同愿景，目标，进度任务，问题，风险，思想等都需要通过沟通来传达。有效的团队沟通是提升团队竞争力必不可少的要素，项目经理有90%的时间都花费在沟通上面，有了沟通就有了共同的愿景和协作氛围，就有了思想的交换和碰撞。
　　敏捷软件开发是很强调沟通和协作的，在敏捷宣言中专门提到了一个重要原则即:
　　个体和交互胜过过程和工具。足见沟通和交互协作在敏捷开发中的重要性。
　　沟通的形式很多，虽然面对面的沟通是最为高效和有价值的沟通方式，但是在互联网虚拟社区和分布式异地开发的逐渐兴起，见面沟通的代价也越来越大。因此在线协作模式下的沟通更加提倡各种截止互联网平台和系统的沟通方式，IM即时通讯和项目团队群，在线协同平台，远程会议等都成为流行的沟通方式。在项目团队已经具有了共同的团队愿景和通用词汇表的情况下，这些沟通将会发挥越来越大的作用。
　　基于异地开发和虚拟环境，我们始终要牢记的就是团队愿景和通用词汇表是沟通的基础。
　　我们都知道，对于一个N个人的团队其存在的沟通渠道是N(N-1)/2条，如何减少沟通渠道则涉及到团队组织结构和岗位角色的设置。
　　我们最担心的就是组织机构层次太复杂而影响到沟通的效率。
　　事实上，树状组织架构是作为权力和责任的结构出现。其基本原理——管理角色的非重复性——导致了管理结构是树状的。但是交流的结构并未限制得如此严格，树状结构几乎不能用来描述交流沟通，因为交流是通过网状结构进行的。在很多工程活动领域，树状模拟结构不能很精确地用于描述一般团队、特别工作组、委员会，甚至是矩阵结构组织。
　　在较大型的开发团队中一般都设置了产品负责人(项目经理)和技术负责人(开发经理)，他们一个负责项目的进度和目标，一个负责技术方案和构思。这两种角色所需要的技能是非常不同的。这些技能可以按不同的方式进行组合。产品负责人和技术主管所拥有的特殊技能可以用不同方式组合，组合结果控制和支配了他们之间的关系。团队的搭建必须根据参与的人员来组织，而不是将人员纯粹地按照理论进行安排。
　　在小型团队中一般是同一个人同时担当产品负责人和技术负责人，在这种情况下沟通当然不存在大的问题，但是我们很少能够找到同时具备合格的管理技能和技术技能的人员。对于大型团队分解为两个人的时候，我们一般仍然是提倡产品负责人作为整个团队的总指挥，但是书中专门提到了一个重要的论点，即产品负责人必须预先声明技术主管的技术权威。要达到这一点，产品责任人和技术主管必须在基本的技术理论上具有相似观点。很多时候导致沟通障碍的都是由于产品负责人和技术负责人之间的观点差异大和冲突的产生。胸有成竹
　　实践是最好的老师，但是，如果不能从中学习，再多的实践也没有用。
　　这个章节标题是胸有成竹，而要做到胸有成竹就必须在项目计划阶段我们对项目的预测和估算都需要很准确。因此整个章节的内容就是在讲估算，而估算就涉及到预测和估算模型，估算要做到准确必须通过前期多个历史项目和版本的积累，同时通过历史版本和数据的积累来发现预测指标Y和相应的估算因子X之间的关系。这样建立出来的估算模型就可以提供我们的估算准确性。
　　最早用的估算方法是建立需求->设计->编码->测试各个阶段工作量之间的比例关系，然后根据需求的工作量来推导其它各个阶段的工作量或者是根据编码工作量来反推上游各个阶段的工作量。这种方式在项目规模比较稳定的小型项目中是比较适用的，但是它不能简单的类别应用到大型软件项目，因为随着项目规模的扩大，规模和工作量之间已经不是简单的线性关系了。
　　根据Nanus和Morin和研究重要结论是工作量和规模之间是指数关系，虽然软件产品规模的扩大工作量成倍增加。
　　工作量 ＝ (常数)×(指令的数量)~1.5
　　Portman的数据表明，对于研发人员每天8小时工作制的情况下我们能够有效利用的全精力投入时间在5-6小时甚至更底。因此我们在做估算的时候必须要考虑到开发人员每天的有效工作量的问题。
　　Aron的数据表明开发人员直接的交互渠道和交互量直接影响到到开发人员的平均生产率，我们强调沟通但是过多无效的沟通会直接影响到我们的效率。当在沟通和问题确认上浪费了我们太多时间的时候，开发生产率下降明显。
　　Harr的数据表明确实存在不同程序类型复杂度完全不同的情况，比如对于控制逻辑程序，编译器程序复杂度远远关于应用软件程序。因此程序类型和复杂度的不同将直接影响到开发生产率。不同简单的不同的程序类型之间类别生产率。IBM OS/360的经验，尽管没有Harr那么详细的数据，但还是证实了那些结论。削足适履和提纲挈领
　　削足适履-关注程序的空间规模和空间控制技能
　　削足适履这个章节在讲什么？
　　我们很多时候在开发程序的时候都是考虑程序的运行时间和效率，而很少考虑到程序的运行空间问题。现在的存储空间是越来越廉价，我们很少去考虑这些问题。经典的DOS版本的仙剑奇侠传还不到20M，而现在的一个大游戏却是2,3G甚至更大。由于计算机的不断更新换代和性能的提升，我们不是特别去强调空间问题，而对于一些操作系统的底层程序我们仍然会强调空间的问题。
　　在开始讲的时候首先讲了软件产品的规模控制，这个规模则是指的空间存储，软件产品的规模应该从顶向下进行预算，分解到各个子系统和模块。这是一种从系统整体出发的统筹思路，这样分解到每个开发人员后他们都必须要考虑如何达到期望的规模目标，尽量同程序设计，算法等各个方面去优化程序规模。
　　在规模控制的技能上讲得很清楚，常用的两种方法。
　　一种是通过提供功能点的多少来换取空间，一种是通过牺牲性能和时间来换取空间。而如何做好空间和时间上的折衷？这一方面是要加强培训提高开发人员的编程技能水平(核心的可能是数据结构和算法)，一方面是要进行长期的技术积累，提倡复用和开发更多的公共构件。
　　数据的表现形式是战略的根本，很多时候技艺的改进和战略上的图片都来自于表和数据的重新表达。由于缺乏空间而绞尽脑汁的编程人员，常常能通过从自己的代码中挣脱出来，回顾、分析实际情况，仔细思考程序的数据，最终获得非常好的结果。实际上，数据的表现形式是编程的根本。
　　提纲挈领-文档的作用和文档管理
　　在一片文件的汪洋中，少数文档形成了关键的枢纽，每件项目管理的工作都围绕着它们运转。它们是经理们的主要个人工具。(文档是沟通的一种重要辅助手段，文档不在于多少，而在于真正的有效)。
　　在这里我们看描述了三类文档，我们只分析里面的产品级文档和项目文档。
　　对于产品级的文档是我们进行后续的项目版本计划的基础，是项目计划上一个层面的产品级规划和计划。里面需要包括:•产品的定位和目标
　　•产品详细的功能特征和技术规格说明(最初来源可能是SOW,后可细化为产品需求)
　　•产品的周期和预算
　　•产品的可行性分析(预测，价格和报价三要素的制约和平衡)
　　•组织结构图
　　对于软件项目级的文档，最重要的是开始的项目计划，原来的博文我有过详细内容描述，在此在书中指出的核心内容包括:•项目的目标和范围(需求详细描述）
　　•进度表（里程碑和详细的进度计划）
　　•预算(资金的预算，人力资源的需求和预算)
　　•工作空间分配
　　•组织机构图
　　为什么要有少量必备的文档，一方面书面的文档记录可以减少分歧，一方面是异步沟通的很好方式。项目经理的任务是制订计划，并根据计划实现。但是只有书面计划是精确和可以沟通的。计划中包括了时间、地点、人物、做什么、资金。这些少量的关键文档封装了一些项目经理的工作。
　　如果一开始就认识到它们的普遍性和重要性，那么就可以将文档作为工具友好地利用起来，而不会让它成为令人厌烦的繁重任务。通过遵循文档开展工作，项目经理能更清晰和快速地设定自己的方向。未雨绸缪
　　为之于未有，始之于未然。 －《道德经》
　　未雨绸缪这章我开始还原来一直记成了是讲风险，但是仔细阅读后发现主要讲如何快速适应变化。在敏捷软件开发中我们强调通过迭代和快速交互等各种方法来适应变化。在大型软件工程中我们看到仍然需要考虑如何适应变化，很多时候对于大型的软件和系统，我们一开始往往很难设计的很清楚，所以只有先假设一种方案，然后对其开发原型进行验证，只有通过验证后才能开始后续的计划，否则就必须提出新的假设。
　　一切事物皆无常，都处于动态的发展变化中，唯一不变的就是变化本身。不但目标上的变化不可避免，而且设计策略和技术上的变化也不可避免。抛弃原型概念本身就是对事实的接受——随着学习的过程更改设计。所以以此为展开分别开始谈软件开发生命周期的各个阶段都必须要适应变化。为变更而计划并不是要求我们范围不明确，而是计划过程应该是迭代式的渐进细化过程。 为变更而设计组织结构，如外科手术团队，要求最小化团队成员接口并最方便系统修改和扩展。 为变更而发布讲如何提高软件产品可维护性，如何解决Bug的修复会引入新的Bug的问题。没有银弹
　　没有任何技术或管理上的进展，能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步。-没有银弹
　　一个相互牵制关联的概念结构，是软件实体必不可少的部分，它包括：数据集合、数据条目之间的关系、算法、功能调用等等。这些要素本身是抽象的，体现在相同的概念构架中，可以存在不同的表现形式。尽管如此，它仍然是内容丰富和高度精确的。
　　我认为软件开发中困难的部分是规格化、设计和测试这些概念上的结构，而不是对概念进行表达和对实现逼真程度进行验证。当然，我们还是会犯一些语法错误，但是和绝大多数系统中的概念错误相比，它们是微不足道的。
　　如果这是事实，那么软件开发总是非常困难的，天生就没有银弹。然后具体从软件开发的复杂性，一致性，可变性和不可见性进行了详细分析。
　　1.复杂性
　　软件系统与计算机、建筑或者汽车大不相同，后者往往存在着大量重复的部分。由于软件产品特有的复杂度导致了成员之间的沟通非常困难，带来了软件产品的进度，质量和成本多方面的问题。特别是在软件规模增加的时候复杂度往往成倍上升。同时复杂度不仅仅导致技术上的困难，还引发了很多管理上的问题。它使全面理解问题变得困难，从而妨碍了概念上的完整性。(在软件产品开发工厂化的过程中，我们要注意到仍然解决的是次要因素，比如加大公用组件开发，加大平台和框架的建设，而业务功能本身导致的复杂性是无法避免的。)
　　2.一致性
　　某些情况下，因为是开发最新的软件，所以它必须遵循各种接口。另一些情况下，软件的开发目标就是兼容性。在上述的所有情况中，很多复杂性来自保持与其他接口的一致，对软件的任何再设计，都无法简化这些复杂特性。
　　3.可变性
　　系统中的软件包含了很多功能，而功能是最容易感受变更压力的部分。所有成功的软件都会发生变更。现实工作中，经常发生两种情况。当人们发现软件很有用时，会在原有应用范围的边界，或者在超越边界的情况下使用软件。功能扩展的压力主要来自那些喜欢基本功能，又对软件提出了很多新用法的用户们。简言之，软件产品扎根于文化的母体中，如各种应用、用户、自然及社会规律、计算机硬件等等。后者持续不断地变化着，这些变化无情地强迫着软件随之变化。(软件开发的过程必须要考虑如何适应变化，在需求，设计和编码过程中都需要考虑如何快速响应变化，如何提高软件产品的可扩展性。我们在软件开发生命周期模型上强调增量迭代的思路，强调测试驱动的思路其根本目的就是为了快速响应变化，降低变化带来的风险。)
　　4.不可见性
　　除去软件结构上的限制和简化方面的进展，软件仍然保持着无法可视化的固有特性，从而剥夺了一些具有强大功能的概念工具的构造思路。这种缺憾不仅限制了个人的设计过程，也严重地阻碍了相互之间的交流。(我们推荐快速原型法仍然是为了进来去解决软件不可见性的问题。
　　5.对没有银弹的感触
　　现在有很多快速开发平台，但是真正能够不写代码就完成业务功能的开发平台基本上没有成功的，特别是在业务场景比较复杂情况下，编程自动化基本是不可能的事情。唯一看到有所突破的是关于统一框架和技术平台等方面的建设，在原有的框架基础上我们来构建一个产品开发平台，将跟业务关系不大的权限模型，工作流引擎等集成进去，将常用的可复用组件集成进去，加快开发速度。
　　不要在追求自动编程平台上下功夫，可以在加强组件复用和技术平台建设上下功夫。要多从开发模式的改进上来解决没有银弹所提出的各种实际问题，虽然不能够彻底解决，但是可以通过努力来改进。比如增量迭代的开发模型，快速原型法，测试驱动，高级语言和图形化编程等。