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