本周因为个人作业的原因，课外阅读时间有所压缩，所以我只是囫囵吞枣般地接着阅读了布鲁克斯所著的人月神话，但仍有一些感悟想与大家分享。
对于每一个软件项目来说，都需要一个文档化的规格说明——手册。因为在设计中，编程实现人员是根据手册所列出的功能进行设计，而当该项目发布后，用户则是依靠手册的指点进行操作。因此，如果没有一个完整的说明手册，将会给编程实现人员和用户带来较大的麻烦。
因此手册的内容要尽量精确，而且还要保证在处理原则上的一致性，所以手册必须有一个或两个人来完成。然而在我每次编完程序后，如果没有硬性规定，我常常不会编写使用手册（当然是为了偷懒）。但我拜读完这本书之后，觉得手册还是很有必要的，所以以后我会尽量注意这个问题。
在项目开展过程中，定期的会议也是非常必要的。书中将会议分为两个级别：周例会和年度大会。周例会是每周半天的会议，在会议中，任何人都可以提出问题和修改意见，而周例会的决策会给出迅捷的结论，使工作继续开展下去，卓有成效。这种会议卓有成效的原因在于以下几个方面：
1.与会人员都对项目的相关内容比较了解，不需要安排额外时间对人员进行培训。
2.每个人对面临的问题都承担义务，无法脱卸责任。
3.当问题出现时，在界线的内部和外部同时寻求解决方案。
4.正式的书面建议，集中了注意力，使决策的制定具有一致性。
接着作者又以巴比伦塔为例，谈到了大型编程项目中的交流和组织问题。众所周知，巴比伦塔是人类继诺亚方舟之后的第二大工程壮举，但巴比伦塔同时也是第一个彻底失败的工程。
那么类似于巴比伦塔的大型编程项目团队如何进行合理有效的交流与架构组织呢？首先大型编程项目团队要通过所有可能的途径进行交流沟通：
1.非正式途径
2.会议
3.工作手册
这对将来我们的团队项目也有借鉴意义，一个团队可能有6至8个人，如果不进行及时有效的交流，很可能会延误团队项目的进展，因此，交流是必不可少的。我觉得团队项目的开展应注意以下几点：
1.每天要保证一或多次线上的交流，团队的每位成员都要告诉大家自己今天干了什么，有什么进展或者好的建议；
2.每周肯定要开一或两次组会，时间可以不必太长，会上要讨论问题，提前在群里发出来，这样就可以节省大家会上思考的时间；
3.及时更新团队博客，每位组员都应关注团队博客的更新，及时了解团队项目的总体进展和必要知识。
至于团队的分工合作问题，应该综合考虑任务量和个人能力。在分工时要从实际出发，不能异想天开。保证每位成员都有任务可干，并且能有所成果。同时，每位组员都应尽职尽责，积极完成自己的任务，否则组员之间就会因分工不均或有人不干事而产生矛盾。