这周认真阅读了《人月神话》一书的前五章，早在上学期曾经简单读过一部。本书在第一章“焦油坑”中先和读者讨论了一个问题，编程的乐趣在哪里。对我个人而言，编程的快乐是让冰冷没有思想的代码为我所用。而作者则把程序员和诗人做比，任务本质上这些没有任何区别，老实说，如果没有看过《程序员修炼之道》一书，我是断然不敢接受这种说法的，但是看完那本程序员的哲学，我愈发相信这一点了。第二章，作者便解释了书名，同时也是本章名——《人月神话》。在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还大。作者列举了五条因素。其中第二条为：我们采用的估算技术隐含地假设人和月可以互换，错误地将进度与工作量相互混淆。对于第二点，作者在后面的解释中，给出图像，相同人月的条件下，人越多，月的减少速率越慢，也就是说，增加过多的人，不会对工作效率有显著提升了。作者任务这个问题的主要原因在于——交流。
现在，其实也是这样的情况。因为左手不知道右手在做什么，所以进度灾难、功能的
不合理和系统缺陷纷纷出现。随着工作的进行，许多小组慢慢地修改自己程序的功能、规模
和速度，他们明确或者隐含地更改了一些有效输入和输出结果用法上的约定。
个人感受：在我们第一阶段的任务完成中，交流确实成了最大的问题，隔着网络，我们多了很多不必要的礼貌和仁慈，这直接导致了整个团队的态度不端正，效率极差。按照书中所说在团队交流中，要重点做到以下三点：
1、非正式途径
清晰定义小组内部的相互关系和充分利用电话，能鼓励大量的电话沟通，从而达到对
所书写文档的共同理解。
2、会议
常规项目会议。会议中，团队一个接一个地进行简要的技术陈述。这种方式非常有用，
能澄清成百上千的细小误解。
3、工作手册
在项目的开始阶段，应该准备正式的项目工作手册。理所应当，我们专门用一节来讨
论它。
在之后的团队合作中，我要注意团队交流，尤其是团队交流的方法，认真执行每一次会议，并且当再有团队合作项目时，思考如何写一份团队工作手册
