利用三个小时通读了这本软件领域的圣作，本来想读得再细致些,但我们的项目经验与作者的大相径庭,加上是从英文翻译来的缘故，有些文字并不能顺畅地理解,读这一遍也实属囫囵吞枣,但书中许多概念还是给我留下了深刻的印象，日后有更丰富的团队作战经验或者是管理经验时重读，或许会有更多的收获。进一寸也有一寸的欢喜,接下来谈谈我读过一遍后对软件工程新增的粗显的理解。
一、软件工程领域的危机
围绕着成本核算的估算技术，混淆了工作量和项目进展。人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的。
程序员在日夜与bug顽抗的过程中也养成了乐观的心态，自然地，在软件项目的时间、成本、人力的估算上也带了乐观主义色彩，这种乐观色彩也是我们思维上的一个双刃bug。然而现实很骨感，真实的软件项目常常面临延期交付。
我们常常觉得人多力量大，众人齐心，其力断金，如果是一个一次性分配即可各自开工、互不干涉的活动，那么这句话无疑是正确的，只要花费在可控成本内，人越多任务完成得越快。
但是软件项目在若干人员中分解任务时会引发额外的工作量——培训和沟通。这都需要时间、金钱和人力的成本。向项目中增派新的人手从三个方面增加了项目必要的总体工作量：任务重新分配本身和所造成的任务中断：培训新人员、额外的相互沟通。
作者在书中提到了一个Brooks法则：
为进度落后的项目增加人手，只会使进度更加落后。
二、切实的经验及管理方法
1. 经验
同样有两年的经验且受到相同培训的情况下,优秀的专业程序员的效率是较差的程序员的10倍。
这敦促我们扎实打好基础，成为团队中不拖后腿的程序员，很难想象，工资相差仅一倍的程序员在技能上却有十倍之差，所以聘用一个优秀的程序员对公司而言赚到了中间相差九倍的效率，这无疑是巨大的回报。
2. 管理方法
小而精干的队伍是最好的,思绪尽可能少。但对于真正意义上的大型系统,小型精干的队伍太慢了。
那么对大型系统而言，有什么更好的管理方法呢？这就是书中很经典的一个例子：外科手术团队。
对绝大多数的大型编程系统，一拥而上的开发方法是高成本、速度缓慢 、低效的，开发出的产品无法进行概念上的集成。
那么一个有一位首席程序员、像外科手术队伍一样的团队架构达到了这样的一个效果——既由少数头脑建构了完整的产品概念，又得到了多位协助人员的总体生产率，还彻底地减少了沟通的工作量。
3. 概念一致性
1）为什么要有概念一致性
为了获得概念完整性,设计必须由一个人或者具有共识的小型团队来完成。
无论项目大小，将其设计与实现分离是很有必要的，这是可以获得概念完整性的强有力手段。正如在软件体系结构这门课程中学到的重要概念——解耦，我们将抽象的方法封装在单独的类中，在具体实现时调用这个抽象类，使得编程不拘泥于复杂的实现细节，且易于维护修改，这便是架构师的意义所在。
一定的规则对软件项目的推进是有益的，外部的体系结构规定实际上是增强了个体或者小团队的创造性，因为他们在编程时有了一个统一的边界，而不用花大量时间绞尽脑汁思索以及交流软件架构这些抽象的事务，从而专注于软件的实现，由此提升开发效率，更是提高了软件质量。
2）具体如何设计概念
出于精确性的考虑，我们需要形式化地设计定义,同样,我们需要用记叙性定义来加深理解。 刚阅读到这里，我不是很理解形式化定义，后来想到离散数学中所学的逻辑学知识，大概理解了所谓形式化应该是用一种特定的语言规则将定义表达出来，以确保其在逻辑学意义上的精确，同时给，为了增加可读性，再辅以记叙性文字，来降低沟通成本。
4. 团队组织性
1）交流
“因为左手不知道右手在做什么，从而进度灾难、功能的不合理和系统缺陷纷纷出现。”由于存在对他人的各种假设，团队成员之间的理解开始出现偏差。
我刚开始加入老师的项目团队时，负责前端页面的设计，但由于项目不是很紧急，所以在学习新技术方面有所怠惰，而团队之间交流也不甚多，所以在第一个项目节点时，我积攒的疑惑都因缺少团队交流而没有得到解决，还好当时项目分工较明确，我的部分和其他同学的部分也暂时没有需要对接之处，不过在交流各自成果时属实有些尴尬。
2）项目工作手册
项目工作手册不是一篇独立的文档，它是对项目必须产生的一系列文档进行组织的一种结构。
我们需要尽早和仔细地设计工作手册的结构，而每个成员也应该了解所有的材料。 之前有过几次团队合作的经历，从刚开始的校内实训，项目文档各自成家——每个人手里拿着自己的一部分，到最后的必要时刻才汇集在一起，到后来使用语雀平台管理项目的所有文档，从需求分析到数据库设计到接口设计，实时更新在线上，使得团队减少了一些不必要的交流，提高了开发效率，也减少了由于文档更新而又没有及时通知到项目组成员造成的麻烦。
3）组织架构
团队组织的目标是为了减少必要的交流和协作量。为了减少交流，组织结构包括了人力划分和限定职责范围。
传统的树状组织反映的是权力的原理结构，也就是不允许双重领导。但组织中的交流是网状，所以在组织结构图中的虚线部分都是为了调整交流路径，以克服树状组织结构中交流缺乏的困难。
每个子项目具有两个领导角色——产品负责人，技术主管或者架构师，他们互相充当左右手，职能有很大区别。
5. 控制进度
根据一个严格的进度表来控制大型项目的第一个步骤是指定进度表，进度表由里程碑和日期组成。
里程碑必须是具体的，可度量的事件，能进行清晰的定义，这样一来，程序员也无法自欺欺人，就里程碑的进展弄虚作假。
必须有评审机制，使所有成员可以通过它了解真正的状态。
评审使我们及时关注个人进展与团队进展的出入，若是有一个对里程碑报告进行维护的计划和控制小组，那将对项目及时交付有莫大的帮助。
