此篇为人月神话第三篇阅读笔记，包含个人感受部分
作品简介
《人月神话》探索了达成一致性的困难和解决的方法，并探讨了软件工程管理的其他方面。在《人月神话（英文版）》中，
既有很多发人深省的观点，又有大量软件工程的实践，为每个复杂项目的管理者给出了自己的真知灼见大型编程项目深受
由于人力划分产生的管理问题的困扰，保持产品本身的概念完整性是一个至关重要的需求。它适合任何软件开发行业的从
业人员阅读，对软件开发人员、软件项目经理、系统分析师更是必读之作。
作者简介
Brooks博士在1975年，把历年来所写的有关软件工程和项目管理方面的文章汇集成书，书名为《人月神话》
(The Mythical Man-Month: Essay on Software Engineering，Addison Wesley)。由于《人月神话》是Brooks博士领导
IBM/360软件开发经验的结晶，内容丰富而生动，例子详实，因此成为软件工程方面的经典之作。
在拜读《人月神话》之前，已经读了《梦断代码》，软件大师们沉痛的教训以及这个学期的课业让我对这个行业有了深刻的了解。
在看完本书大概后，我发现这不是一部讨论软件技巧的书籍，而是一个人和团队和项目的故事。
软工人总是很会讲故事，看来这是先辈留给我们的宝贵的财富，开发一个工程是枯燥的，但人不是机器人，所以乐观是必备因素。
书中用实例给了我们很多启示。
1.人月神话，
首先当然是人月啦，和别的工程不同，一个软件工程的进度并不是人越多就越快，而当年许多管理员就是犯了这个问题而导致了奇点的产生，
2.开发人员
一个开发小组因由较少人员组成，单体应有较强的战斗力，
优秀的程序员效率的巨大差异弥补了人数的差异并且解决了由于人员过多导致的隐形问题（例如沟通）。
3.确定系统概念的完整性
由此推出架构师的概念，通过架构师的专制设定，使得系统在设计概念和代码编写风格方面上能有很强的一致性。
4.沟通，沟通
人员的精少会保持沟通的高效性，而沟通会使得设计最小偏离预定轨道。
5.设立明确目标
尽管软件在开发过程中会遇到各种各样意向不到的难题，但是小目标还是要设立的，它将进度可视化给关心它的人。
6.文档
好吧，虽然乏味，不乐意，但文档还是要写的，文档使信息可视化，软件是虚的，而文档是实的，虚实结合，信息才能被快速传播。
软件是迄今为止最复杂的系统之一，读完本书，对于作为一个软件人究竟需要有什么样的素质我有了初步的了解。
那便是追求卓越，追求完美，心态乐观。
个人感受：
以前是怎么做的：我过去没有注意到沟通的重要性
为什么不好：缺乏沟通，使得每个人的开发进度不可见，无法很好的制定下一步的计划
解决办法：进行每日会议，每个人都要汇报自己的进度