摘要: 昨天难得几家公司的一些开发人员聚集在一起讨论了些项目实施中的问题,摘录两个比较有趣的问题:
关于工作日志问题:大家都认识到做工作总结的重要性。但是以什么方式做总结,以及在实施情况都不大一致。其中有的是以硬性规定程序员必须每天下班前填写工作日志,每周周五填写周报形式进行总结;有的则是以小型随便的圆桌会议进行项目组内部面对面沟通,周五则在会议室召开例会进行周总结;有的则每周只有周五进行一次例会;有的公司甚至好几次反复执行填写工作日志制度。但是,大家这样做的目标都是为了了解当前项目进度,同时进行计划调整与安排,增进成员间各种交流,方面上级领导视察工作情况,作为绩效考评之一。[个人观点]:填写工作日志是好的,一份好的工作日志确实能反映出很多问题。但是工作日志毕竟只是一种工具,那就要看怎么去用,才能用好它了。ZDNet里就有一篇《工作日志的好处》的文章。但是看似非常好的东西往往在执行过程中就变味了。比如有的工作日志是只填写给项目经理或上级领导看的,那就缺少了成员间技术等多方面交流的环节;有的工作日志简单到只写了“今天我做了XXX事,完成了XXX模块”之类,而没有把碰到的问题,解决的思路,最后的解决方案等写出来,形成了无用的信息垃圾;有的为了写给项目经理或领导看,夸大了自己的工作成绩,如果项目经理片面相信工作日志,就会埋下一定隐患。等等诸如此类问题。所以我觉得能做到象《工作日志的好处》里写的,那么你可以考虑执行。如果在你执行一段时间后,发现碰到上面所说的一些问题,你就该考虑出了什么问题,要不要纠正然后继续执行然后采取其他更适合自己团对的工具与手段?
测试与版本管理等软件工程实施问题:这个问题可能比较受忽视,但却是真的十分严重的问题。几家公司中,讨论后发现这块比较好知名度也比较高的一家公司,它略去单元测试,他们采用MSF,在版本管理和变更管理上也算达到百分六七十成功了(套用那晚一个PPT上一句话,100%成功的配置管理耗费资源太多,能做到百分六七十就算实际了)。另一家采用类似XP编程方式,单元测试、代码重构、持续集成等都相对靠拢,当然结对编程也没实施(我怀疑结对编程在中国是否存在)。而另外一家也没单元测试,就进行功能测试性能测试,版本管理差不多也在去年初才使用SourceSafe管理。这之间讨论出现的问题就是,版本混乱、BUG跟踪、BUG报告等问题。我印象最深的是上述第一家公司用Excel做BUG跟踪、第二家之前也用Excel后来因为购买了Rational系列软件而采用Rational ClearQuest,但用不起来;第三家不清楚。[个人观点]:我想这个问题更多的是要求要有思想上的转变以及管理上的配合。现在的软件工程中的开发方法开发方式等呈现百花齐放景象,问题在于这些软件工程的方法生搬硬套并不能解决问题。我一直理解软件工程方法为一套实施参考指南,而非一套标准,这是我个人的理解。所以在实施一系列过程中,就应该在实践中去总结出自己最行之有效又合乎实际的方法。你能说出用Excel跟踪BUG的多点坏处,但是在目前情况目前财力物力下,如果管理通顺配合Excel管理BUG跟踪却是十分实际的做法。你能说没采用结对编程,参考实施XP其他有点就无法发挥其优势了吗?...[
阅读全文]