今天对人月神话的正文部分进行了阅读，从人月神话这一部分中了解到缺乏合理的时间进度控制是造成滞后的主要原因，比其他任何事情影响的和还大，书中也对造成这种这种普遍灾难的原因进行了并进行了详细列举。
首先，我们对估算技术缺乏有效的研究。也就是文章中所介绍的对于与每一个编程人员来说都是乐观主义者，在编程人员的心中，认为一切都将运作良好，每一项任务仅花费它所“应该”花费的时间。然而事实并不是这么简单的，在创作工程中总会遇到不同的苦难的，你的程序并不一定就按照这你的思路进行，总会遇到一定的bug等着你去处理。第二，我们采用的估算技术隐含地假设人和月可以互换，错误地将进度与工作量相互混淆。按照常规思维，人多力量大，然而实际在编程过程中却不一定是这样的当任务由于次序上的限制不能分解时，人手的添加对进度没有帮助，因为程序的次序性不同每一步都必须经过一点时间的孕育的。第三，由于对自己的估算缺乏信心，软件经理通常不会有耐心持续地进行估算这项工作。由于没有认真的估算好时间就会导致对于系统测试的安排时间较短，如果没有经过这些基本的测试就直接交付就会导致重新的维护，这样相应的成本也会上涨，最终造成的费事费力，所以一个良好的时间规划是程序编写的关键。正确的时间规划应该是：1/3 计划1/6 编码1/4 构件测试和早期系统测试1/4 系统测试，所有的构件已完成。第四，对进度缺少跟踪和监督。其他工程领域中，经过验证的跟踪技术和常规监督程序，在软件工程中常常被认为是无谓的举动。就如同书中所介绍的那样，编程人员，同厨师一样，某项任务的计划进度，可能受限于顾客要求的紧迫程度，但紧迫程度无法控制实际的完成情况。
第五，当意识到进度的偏移时，下意识（以及传统）的反应是增加人力。然而这并必须要考虑到不同的情况，有时盲目的增加人手只会是画蛇添足，导致越帮越忙。
另外，根据对于外科手术队伍的也颇有感想。在这一章的内容中阐述的就是在工程管理过程的经验。同样本章中也对人员问题进行了另一番阐述，书中所说，一个优秀的队伍并并不在于人数的多少，相反在于人员的精炼，就如同一个优秀的外科队伍一样，有时10个人就可以构成一个优秀的团队。.一个首席程序员（后来叫做架构师），可以采用一个外科手术式的队伍完成10人配比的队伍。大概是主程序、管理（BOSS）及他的文秘、编辑及他的文秘（这个可以省略），副手（和主程序相比，什么都会，但是没有主程序那么精通），其他程序，语言专家（外援），测试员这样的配比来执行，相应的还可以有工具维护人员（也是程序员的一种，负责辅助程序的开发）因为小型、精干队伍最好（思绪少，相互交流容易）-----相对于普通情况下，如果是大型的可以将领导人拆出来做成一个决策组，来提升协调；当然团队中的每个成员最好都是优秀的编程人员，因为相同程度的培训，优秀的人员的生产率是较差成员的10倍，只有在这种精悍的团队下，才更加有益于优秀作品的推出。当然对于开发真正的大型系统的话，人员的增加才是必须的。
这也给我们我们很大的启示，要想做一个真正的程序开发人员，我们还是远远不够的我们必须通过不断地学习，不断提升自己的能力，能够融入到优秀得队伍中去。
javascript匿名函数)
