实践是最好的老师，但是，如果不能从中学习，再多的实践也没有用。

这个章节标题是胸有成竹，而要做到胸有成竹就必须在项目计划阶段我们对项目的预测和估算都需要很准确。因此整个章节的内容就是在讲估算，而估算就涉及到预测和估算模型，估算要做到准确必须通过前期多个历史项目和版本的积累，同时通过历史版本和数据的积累来发现预测指标Y和相应的估算因子X之间的关系。这样建立出来的估算模型就可以提供我们的估算准确性。

最早用的估算方法是建立需求->设计->编码->测试各个阶段工作量之间的比例关系，然后根据需求的工作量来推导其它各个阶段的工作量或者是根据编码工作量来反推上游各个阶段的工作量。这种方式在项目规模比较稳定的小型项目中是比较适用的，但是它不能简单的类别应用到大型软件项目，因为随着项目规模的扩大，规模和工作量之间已经不是简单的线性关系了。

根据Nanus和Morin和研究重要结论是工作量和规模之间是指数关系，虽然软件产品规模的扩大工作量成倍增加。工作量 ＝ (常数)×(指令的数量)~1.5

Portman的数据表明，对于研发人员每天8小时工作制的情况下我们能够有效利用的全经理投入时间在5-6小时甚至更底。因此我们在做估算的时候必须要考虑到开发人员每天的有效工作量的问题。

Aron的数据表明开发人员直接的交互渠道和交互量直接影响到到开发人员的平均生产率，我们强调沟通但是过多无效的沟通会直接影响到我们的效率。当在沟通和问题确认上浪费了我们太多时间的时候，开发生产率下降明显。

Harr的数据表明确实存在不同程序类型复杂度完全不同的情况，比如对于控制逻辑程序，编译器程序复杂度远远关于应用软件程序。因此程序类型和复杂度的不同讲直接影响到开发生产率。不同简单的不同的程序类型之间类别生产率。IBM OS/360的经验，尽管没有Harr那么详细的数据，但还是证实了那些结论。就控制程序组的经验而言，生产率的范围大约是600～800（经过调试的指令）/人年。语言翻译小组所达到的生产率是2000～3000（经过调试的指令）/人年。

Corbato的数据得出更进一步的延伸结论，对常用编程语句而言。生产率似乎是固定的。这个固定的生产率包括了编程中需要注释，并可能存在错误的情况.使用适当的高级语言，编程的生产率可以提高5倍。