关于项目发布包前后遇到的问题及看法

关于项目发布包前后遇到的问题

近期团队就发包的问题，展开了一次讨论性的会议。与其说是一次会议，更确切的说是一次沟通。项目是java人力外包，下面就让我介绍一下团队和本次沟通的内容吧。

团队构成

分工	人数	程序数量	平均工龄
前端（含后台取数）	4	1	2
后台	4	9	2

问题

1. 发布包升级手册中脚本及问题验证编写粗心，发布包的验证马虎。
2. 需求/bug与现场沟通不够
3. 问题修复不完整或改出新问题的现象
4. 各程序之间的联合测试问题
5. svn使用不当,代码冲突或覆盖
6. 程序的版本控制问题

在沟通的过程中，大家都可以说出几个如何改进的点。在大家看来，这些都是项目运行过程中都会遇到的小问题。部分成员又是中途插队，很难再短时间内做好这样的工作。但这不是借口。对于如上问题，我也有自己的一些小建议，或者说小看法。

看法

发布包升级手册中脚本及问题验证编写粗心，发布包的验证马虎

这个也不能完完全全说是成员个人的问题。在很多团队中，也并不要求成员对文档的编写有很大的要求。往往“麻雀虽小，但五脏俱全”的小团队反而压抑住成员的主人翁精神。这里我并没有说细分工种是件不好的事情。也由于目前的市场情况及团队任务的繁琐工作，在工作日内完成上级分配的任务已经算是很大的结果了（我们项目还不算太忙），非工作情况下的学习算是种“奢侈的消费”。

需求/bug与现场沟通不够

在我待过的团队中，很少有“内向”的人存在。众所周知，程序猿找对象都用new的形式去完成，大部分人都是“宅”。但是这些“宅”们在一起可是无话不谈的。在与业务人员沟通的情况下，是否出现“自以为是”，“已经可以”，“无需确认”的情况。往往这些都是致命的。

问题修复不完整或改出新问题的现象

如果把这个归纳到短期内无法完全理解项目业务和融入团队这里的话，有点牵强。有一份原因也可以归纳到与业务员的沟通问题上面。成员的项目经验问题还有待提高。

各程序之间的联合测试问题

有人说，我很难想到我修改的程序是否影响到其他程序功能的运行。对，想想看，这的确有点道理，各何况团队程序那么多，谁来把控？项目经理？要知道，团队可是个0测试的构成啊。难道就不能规避这个问题了吗？这么多程序，是否存在“麻烦”，“就这样了”，“不用测”的话语。业务了解的够不够？一个人就要面对2-3个程序，是否就应该无视或者不关心其他应用程序？肯定有人会说，哪有时间啊，搞完自己的就已经不错啦。我觉得这很值得深思啊。

svn使用不当,代码冲突或覆盖

我觉得百度比我懂的更多。

程序的版本控制问题

不要做一个只会敲代码的好程序猿，也要为自己留条“后路”吧。

转载于:https://my.oschina.net/xiaozhutefannao/blog/878845