内容简介
在软件领域，很少能有像《人月神话》一样具有深远影响力和畅销不衰的著作。Brooks博士为人们管理复杂项目提供了*洞察力的见解，既有很多发人深省的观点，又有大量软件工程的实践。本书内容来自Brooks博士在IBM公司SYSTEM／360家族和OS／360中的项目管理经验，该项目堪称软件开发项目管理的典范。该书英文原版一经面世，即引起业内人士的强烈反响，后又译为德、法、日、俄、中、韩等多种文字，全球销售数百万册。确立了其在行业内的经典地位。
在《人月神话》出版40年后的今天，我们重新整理了Brooks博士的经典内容，并将国内软件开发领域先行者们对《人月神话》中的实践及系统理论的使用经验和心得集结成册免费赠与大家共享，更使本书成为国内从业者的经典之一。
本书读者包括：软件开发人员、软件项目经理、系统分析师等IT从业者。
作者简介
小弗雷德里克布鲁克斯曾获得美国计算机领域*声望的图灵奖(A. M. Turing Award)。美国计算机协会(ACM)称赞他“对计算机体系结构、操作系统和软件工程做出了里程碑式的贡献”。
布鲁克斯博士1956年开始任职于IBM公司，早期担任Stretch 和Harvest计算机的体系建构师。他被认为是“IBM 360系统之父”，曾担任360系统的项目经理。凭借在此项目中的杰出贡献，他与Bob Evans和Erich Bloch在1985年获得了美国国家技术奖(National Medal of Technology)。
布鲁克斯博士创立了北卡罗来纳大学的计算机科学系，并于1965-1985年担任系主任。他还曾任职于美国国家科技局和国防科学技术委员会。目前其仍活跃于从事虚拟环境和科学可视化等方面的研究工作，2010年获得虚拟现实事业奖(IEEE Virtual Reality Career Award)。
书籍+思维导图获取方式
长按下方二维码
回复： 读书
书籍+思维导图获取方式
长按下方二维码
回复： 读书
书籍地址：
https://pan.quark.cn/s/31400e93b596
全书摘抄
1 “人月”的欺骗
人们通常期望项目在接近结束时，软件项目能收敛的更快一些。然而，情况却是越接近完成，收敛得越慢。
产品在完成前总面临着陈旧过时的威胁，只有实际需要时，才能用到最新的构想。
缺乏合理的时间进度是造成项目滞后的最主要原因。
进度安排，我的经验是1/3用于设计, 1/6用于编码, 1/4用于构件测试, 1/4用于系统测试。
在若干人员中分解任务会引发额外的沟通工作量——培训和相互沟通。
向进度落后的项目增加人手，只会使进度更加落后。
向软件项目增加人手增加了总体工作量：任务重新分配所造成的工作中断，培训新人员，额外的相互沟通。
2 “团队的构建”
小型、精干队伍是最好的！
在大型系统设计中，需要外科手术似的的队伍：由一个人进行进行任务的分解，其他人给予支持。
外科医生=首席程序员
系统设计者，亲自定义功能和性能技术说明书，设计程序，编制源代码，测试以及书写 技术文档
副手=二级程序员
设计的思考者、讨论者和评估者，作为外科医生的后备
管理员
控制财务、人员、工作地点和办公设备的专业管理人员
编辑
外科医生负责文档的生成，编辑则根据外科医生的草稿或口述，进行分析和重新组织， 对多个版本 进行维护
两个文秘
管理员和编辑每人需要一个文秘
程序职员
负责维护编程产品库中所有团队的技术记录
工具维护人员
保证所有基本服务的可靠性，以及承担团队所需要的特殊工具的构建、维护、升级责任
测试人员
编写测试用例，负责计划测试步骤，为单元测试搭建测试平台
语言专家
寻找一种简洁、有效的使用语言的方法来解决复杂问题
3 “保证概念完整性”
概念完整性是系统设计中最重要的考虑因素。
功能与理解上的复杂程度的比值才是系统设计的测试指标。
为了获得概念完整性，设计必须由一个人或者具有共识的小型团队来完成。必须有人控制这些概念，虽然这是一种专制统治。
4 “职责分工”
第二个系统是最危险的系统，通常是过分的进行设计。
结构师的职责：
牢记是开发人员承担创造性的实现责任，结构师只能提出建议
时刻准备着为所指定的说明建议一种实现的方法，准备接受任何一种其他可行的方法
听取开发人员在体系结构上改进的建议
软件编程管理人员的职能：从系统整体出发、面向用户的态度
项目经理的基本职责：使每个人都朝着相同的方向前进
主要日常工作是沟通，而不是做出决定。
为通用工具的开发分配资源，必须意识到专业工具的需求
5 “团队合作”
尽早交流、持续沟通，可使团队效率更高。
团队应该以尽可能多的形式进行相互交流，非正式地进行简要技术陈述的常规项目会议，
共享的正式项目工作手册，或者通过电子邮件。
项目工作手册是对项目必须产生的一系列文档进行组织的一种结构，而不是一片独立的文档。需要尽早和仔细地设计项目手册。
每个团队成员都要能看到到工作手册的所有材料，网页即可满足需求。
应该将注意力集中在上次阅读后的变更以及关于这些变更重要性的评述上。
6 “未雨绸缪”
第一个开发的系统往往不合人意，系统的丢弃和重新设计是必经阶段。
目标上的一些正常变化无法避免，事先为它们做好准备比假设他们不会出现要好得多。
为变更组件团队比为变更进行新设计更加困难。
维护成本受用户数目的严重影响，用户越多，所发现的错误也越多。
产品生命周期中每月BUG的数量变化曲线是“先下降后上升“。
缺陷修复总会以20%-50%的几率引入新的bug。
每次修复之后，必须重新运行先前所有的测试用例。
实现设计的人员越少，接口越少，产生的错误就越少。
所有修改都倾向于破坏系统的架构，增加系统的混乱程度。
即使是最熟练的软件维护工作，也只是延缓了系统退化到不可修复的混乱状态的进程。
7 ”项目延迟“
一天一天的进度落后比重大灾难更难以识别，更不容易防范和弥补。
根据一个严格的进度表来控制大型项目，进度表由里程碑和日期组成。里程碑必须是具体的可度量的事件，里程碑需要定义得非常明确，以至于无法弄虚作假。
——推荐阅读——
![]()
书籍资料获取方式
长按下方二维码
回复： 逻辑
![]()
书籍资料获取方式
长按下方二维码
回复： 逻辑
![]()
干货▶
麦肯锡认知升级三部曲：《麦肯锡方法》《麦肯锡意识》《麦肯锡工具》
PPT▶
![]()
干货▶
麦肯锡认知升级三部曲：《麦肯锡方法》《麦肯锡意识》《麦肯锡工具》
PPT▶
扫码进入知识分享社群
分享优质内容，让阅读有价值
愿行者智，并智者行
公众号后台回复 “社群”, 加入社群
