章节1：焦油坑

编程是创造性的，但是过程中也存在编程限定带来的重复性工作、

章节2：人月神话

1. 估算进度不合理发生的原因是什么？

    a. 估算技术不成熟

    b. 工作量和进度混淆，导致采取错误的估算技术

    c. 信心不足 - 可能对能交付的成果需要的时间过长，造成冗余

    d. 缺少监控

    e. 发现进度偏移，立刻增加团队成员

【感想】整体上看，项目进度管理需要存在前提条件：

PM经验 - 弥补信心问题；

估算技术 - 需要基于当前任务和人员现有能力，才能估算 - 需要把培训成本、犯错成本等加入到项目成本管理的应急储备中；

概念明确 - 需要识对任务进行拆解和细化，明确团队成员的职责和流程；

增加监控；

对于项目经理来说，遇到偏差需要进行根本原因分析。

2. 人月神话的破除 - 遇到进度滞后应该如何进行管理

核心：向进度落后的软件项目增加人手，会使进度更加落后

章节3：团队角色配置和职责划分 - 敏捷思想

章节4：概念完整性

1. 类似信息完整性，需要确保我们设计能被准确、完整、一致地在产品实施时体现

2. 易用性：

    - 设计的易用性：对于用户来说，你的设计是否很好上手；

    - 对于团队来说，需求设计是否容易理解；

∴ 设计需要简洁，直白。

3. 整个创造性活动包含了三个独立阶段：架构（architecture），实现（implementation），实施（realization）

章节5：第二系统效应

本章节说明了一种现象，当人在某件事上有了第一次经验，那么第二次他会尝试这件事时添加很多想法，而这些想法可能超过范围。

所以对于项目经理来说，需要规避的就是第二系统效应：

1. 项目经理本身的经验，需要足够；

2. 需要规划合理的基本原则 - 项目的纲领和目标；

3. 目标决定了项目的底线和上线，因此也决定了范围；

4. 迭代式完善规划组内容，保持监控 - 目标可能随着时间变化而变化。

章节6：消息传递

本章节主要说明一下2点：

  1. 人和人之间如何有效地传递消息

  2. 人和机器之间如何有效的传递消息

规定(手册)：需要明确，详细，要考虑到包含和不包含，跟合同一样，也要明确规定-哪些不被包含在范围内。

会议：不仅能用来发命令，我们在会上需要讨论，这是创新的好机会。

多重实现：当结果出现分歧，要按照规定办事。

章节7：巴别塔失败

这章说明以下2点：

  1. 交流

  2. 组织

交流：规则和信息。

  强调了规则的制定：要保留记录，记录需要按照一定的结构进行整理，便于后面查看和汇报。这决定了文件的实际用途。

组织：角色和工作内容要一致。

感想：

  六七章都是说消息的重要性，由谁说什么样的消息很重要。所以角色，消息结构，消息内容，消息频率，是项目运行的基本沟通项，需要明确这些。

章节8： 胸有成竹

核心：项目越大越复杂，越不能通过 最小工作组x人 估算成本，需要把沟通成本等涵盖进去。

感想：减少沟通成本的主要核心在于：减少involve。

章节9： 削足适履

这章虽然说的是空间和内存，但是也可以作为方法论适用各个场景

1. 项目经理需要做好范围控制，明确边界，预留buffer(预算缩减)

  1.1 预算需要从上向下树形拆解，可以分到工作包的粒度

  1.2 预算跟工作量至少需要同时预估

  1.3 系统完整性，牵一发而动全身

2. 工作量的缩减：减少重复劳动，快速掌握新技能

2.1 培训

2.2 拉式分享

章节10： 提纲挈领

强调文档的重要性：

    1. 有文档，才能识别不足；

    2. 文档=拉式读取，便于知识流通；

    3. 作为依据可以检查结果。

感想：二八定律：约20%的文档需要花80%的精力。

章节11： 未雨绸缪

需要认识到，变化是固定存在的，而适应变化的能力是必备条件。本章节前2小节说明变化，以及变化的系统可以按阶段性release（版本号）。

提出来一个topic - 复合型人才 - 必要时管理人员的角色和技术角色可以互换，保持新鲜感和创新能力。

当迭代式更新文档时，需要重新梳理前后逻辑，不要有冲突（回归测试）

项目是亚稳态的。

章节12： 干将莫邪

工欲善其事必先利其器，本章节讲述开发过程中，合理使用工具会缩减成本。

章节13： 整体部分

本章节其实是接着12章的开发过程，来讲述测试过程中需要关注的重点：

4-6 章设计时，可以通过粗略的定义和目标，先进行开发，然后再调试时把结果跟期望进行对比，识别到的差距可以通过更清晰的定义来精化后面的要求。

11章也强调，在加入新的功能和组件的时候，需要关注的是变更给整体带来的变化。

建议小步快跑 - 增量更新。