这节内容中，作者主要着力于项目进度预估的工具。
利用精确的预估推动项目进度
实际工作中，我们经常被要求给出一项具体工作的工作量排期。某些情况下，我们可能不得不在排期明显不够的情况下工作（比如业务方的施压，领导给出倒排期项目等等），为了保证项目进展可控，有以下几个方法可供使用：
- 把项目拆分成细粒度的任务 先拆分任务，再对各个相对小而可控的子任务进行排期
- 根据任务的实际工作量给出排期，而不是所期望的排期
- 不要总考虑最好的情况，应该考虑在大概率情况下合理的排期 合理考虑不确定的因素影响，比如依赖方的进展，外部工作的进展等等
- 让实际工作人给出排期 很容易理解，每个工程师的生产力都大不相同
- 警惕锚定偏见 警惕外部给出的所谓“锚定值”，避免受到影响
- 采用多种方法来预估同一个任务
- 警惕“人月神话”
- 根据历史数据验证估算
- 使用时间箱来约束调研类的问题
- 允许其他人合理的质疑给出的预估
预留缓冲时间
项目开发不可能一帆风顺，对于越大的项目，这点就越明显，所谓的未知因素包含但不仅限于下面几点：
- 编写测试相关的基础代码，这有利于项目质量的保证，但没有包含在实际的排期时间内
- 被一些期望之外的外部高优先级任务打断，比如：线上事故的修复等等
- 修复可能出现的第三方库的问题
- 处理可能出现的扩展性问题
- 可能出现的人员流失问题
- 依赖方可能出现的延迟问题
- 业务方可能调整业务需求
......
所以，务必为不可知因素预留一些缓冲时间。
定义具体可衡量的进度时间点
目标越明确，就越能够帮助我们决定工作方向。设定目标也构建了关键涉众之间的清晰性和一致性，制定清晰可衡量的里程碑，有助于把控项目的整体进度。
尽早排除风险
最先去做最有可能出问题的部分，以便于尽快定位问题带来的影响。最初阶段应该充分调研，以减少不确定因素带来的风险。尽早编写完善的测试也有助于定位问题所在。
重写系统时务必谨慎
重写系统通常会面临以下问题：
- 它们与其他软件项目一样，都有相同的项目规划和评估困难
- 因为我们倾向于熟悉最初的版本，所以我们通常会比在新领域中更严重地低估重写项目
- 将额外的改进打包到重写中很容易也很诱人。为什么不重构代码以减少一些技术债务，使用一个性能更好的算法，或者在重写代码时重新设计这个子系统呢?这些想法有可能将项目越拖越久
- 正在进行的重写时,任何新功能或改进必须被添加到改写版本(在这种情况下,他们不会发布直到重写完成)或者他们必须重复在现有版本和新版本(为了得到功能或改进更快)。任何一种选择的成本都随着项目的时间表而增长，也就是说，既要兼容历史问题，又要不断满足新的业务需求
