改善交流效率的常用方法是采用正式的文档。不是让50个人以各种可能方式相互交流，而让她们阅读和撰写文档。有些文档是文本，有些是图形。有些文档需要打印出来，有些则是电子格式。
27.5.1 Activities Proportions and Size 活动比例和项目规模
27.5.2 Programs, Products, Systems, and System Products 程序、产品、系统和系统产品
代码行数和团队规模并不是影响项目大小的仅有因素。另一个敏感的影响因素是最终软件的质量和复杂度。
最简单的一类软件是一个单一的“程序”，只有它的开发者使用它，或者其他少数几个人非正式地使用它
稍复杂些的一类程序时软件“产品”，它打算供给最初开发者以外的人员使用。软件产品的使用环境也与开发环境不同。在发布之前要做充分的测试，要有文档，并且可以由其他人来维护。开发软件产品的成本大约是开发“软件程序”的三倍。
更复杂一些的是开发一组能够结合起来工作的程序。这样一组程序通常称为软件“系统”。开发一个系统要比开发一个简单的程序复杂得多，因为开发各个组成部分之间的接口并把它们集合起来会很复杂。大体上，系统的开发成本也是简单程序的开发成本的3倍。
如果开发的是“系统产品”,它既要具有单一产品的精致特征，又要拥有一套系统所具备的多个成分。系统产品的开发成本大约是简单程序的9倍。
没能认识到程序、产品、系统以及系统产品在精度和复杂度上的区别，是导致估算出偏差的一个常见原因。程序员用他们开发“程序”的经验来估计开发一套系统产品的进度，可能会低估10倍。请参考如图27-3.如果你依据自己写2000行代码的经验来估计开发一个2000行的程序需要多长时间，那么你估计的时间只是“为开发改程序而实际需要进行的全部活动额总耗时”的65%。写2000行代码的时间不等于开发一个具有2000行代码的程序的时间。如果你不把“非构建”活动的用时考虑进去，开发时间将会比你的估计要多出50%。
这里所说的估算误差，其产生原因全在于你不理解“项目规模对开发大型程序所造成的影响”。如果除此之外你还没有考虑到开发一个“产品”比仅仅开发一个“程序”需要做更多的“抛光”工作， 那么误差将会再增长至3倍，甚至更多。
27.5.3 Methodology and Size 方法论和规模
在软件开发领域，项目越正规，你不得不写的文件的数量也会越多，用于确认你已经完成了自己的工作。撰写文档额目的不在于文档本身。比如，写配置管理计划的目的不是要锻炼你的写作肌。先写计划的关键在于，它能迫使你仔细考虑配置管理，并且把你的计划向每个人解释。文档只是你在计划并构建软件系统过程中所做的那些真实工作的一种有形的副产品罢了。如果你感觉自己只是在履行写作手续，写出来的内容页泛泛无奇，那肯定是什么地方出了问题。在实践中关键的是要考虑你的项目实际的规模和类型，然后找出“适量级”的方法论。
随着项目规模的扩大，交流需要加以支持。大多数方法论的关键点都在于减少交流中的问题，而一项方法论的存亡关键也应取决于它能否促进交流。
在其他条件都相等的时候，大项目的生产率会低于小项目
在其他条件都相等的时候，大项目的每千行代码的错误率会高于小项目。
在小项目里的一些看起来“理当如此”的活动在大项目中必须仔细地计划。随着项目规模扩大，构建活动的主导地位逐渐降低。
放大轻量级的方法论要好于缩小重量级的方法论。最有效的方法是使用“适量级”方法论
代码大全
2014-09-12
2014-09-12