怎么做好软件项目的管理

      首先，写下这些文字是源于一次痛苦的出差经历。由于项目原因需要到国外工作，加上我们的准备不是很充分。结果导致现场调试的过程中非常狼狈，问题怎么都找不到，员工更是几天没睡好觉，非常疲惫。而最后查出的结果：错误竟然源自于一个小小书写错误，My God。最可气得是问题出在我们认为最稳定的部分，而我们在调试过程中压根就没有觉得可能那里出问题了，My Godness。

      其次，其实这个题目定的大了一点。因为我也不知道该为这些文字取一个怎样的标题合适。但我觉得我需要将这些教训写出来，这样，至少我在以后的工作中会记住这些。所以这些字也就全当自己的一篇日记写了。

      先简要介绍一下事发经过。项目的软件部分由三人组成，分别负责：硬件底层驱动，嵌入式操作系统，应用层软件。由于某些原因，在临出国前负责硬件底层驱动的同事去不了了，于是只能有另两个同事去了。在临出国前我们模拟了许多有可能出现问题的情况，都一一想到了解决办法或者其他替代方法。在国外项目开始调试时，我们发现负责通信的模块与国外的相关服务器连接不上，但却可以和国内的服务器连上。于是我们首先怀疑是不是通讯模块在国外水土不服，但我们选择的是品牌模块，再加上咨询了其他相关人员，基本排除是模块的问题。然后我们怀疑是不是国外的相关的服务器存在某些屏蔽功能，于是我们要求合作单位单独架设一台服务器供我们调试，结果发现还是不行。接着我们怀疑是不是通信模块的设置在国内外存在差异造成的，于是请来了当地搞通信工程方面的专家咨询，将我们对通信模块的设置步骤重新整理，结果还是不行。My God，这下我们彻底抓瞎了。还好这个项目中那个没有出国的同事对该项目也有所了解，于是我们请她在国内使用相同的硬件平台与我们同步调试（国内与国外有7小时的时差，国内的上班时间相当于国外的凌晨1点，我们一起调试，那叫一个惨）。起先她可以通过硬件平台登录到国内的服务器上，但是也不能登录到国外的服务器。经过调试后（此时我们在大洋彼岸几近绝望）发现在底层串口中断的函数调用写错了，本来串口2应该调用的串口2的中断服务程序，但由于手误写成了调用串口1的中断服务程序。Oh,My God。荒唐的是这种代码尽然在国内的调试过程中通过了。Oh,My Godness。于是我们在火车开车前3小时解决了问题（之前的大部分时间都是在做无用功），在谢天、谢地、谢人的感激声中离开了此地。

      细细想想，这次的经历存在着许多的巧合：如果我们的那个同事没有因为其他原因顺利的与我们一同搭上了飞机；如果我们的程序在国内调试的时候就不通过；如果我们在出现问题的时候第一时间想到了可能是哪里的问题。当然这一切都是假设也都是巧合，但偶然之中会不会存在必然哪？

      我认为还是有的。

      首先是我们对软件代码的注释不够完善，如果在写代码的时候能够多写两句注释说不定问题早就发现了。

      其次是我们对软件的测试还不够完善，如果我们当初在测试的时候想到用国外的服务器试它一试说不定问题也就发现了。

      再次，也是我认为最重要的，是我们对同一项目研发人员的备份不够完善。一般来说，一个项目的一个任务，至少需要2个开发人员对其进行支持，这样做的好处不仅可以降低人员突发状况的风险，更能在开发的过程中起到互相督促、互相检查的作用。而我们的项目多数只有一个人在负责，那一但出现突发状况损失将很大，同时也不利于软件的排错。想想如果硬件底层驱动是由两个人交叉开发的，怎么会出现这么幼稚的错误。哎。。。。。。

      想说的也就这些。最后想聊几句，咱中国人在国内爱咋地咋地，出了国了可千万得为咱中国人争口气，别让洋人给瞧扁了。有些洋相出在国内也就行了，可千万别丢脸丢到国外去。真的，只有出国，才会爱国。