当前项目开发管理中的问题

第一个问题就是项目开发时间安排问题。

时间安排规划给详细设计文档和编码的时间太短，明显的认为软件都是借用之前版本的设计和代码，仅仅进行一些移植工作，所以给这么一点点时间。这样的话，留给重构的时间实在太少，代码太烂了，想重构，可是进度又这么紧张，逼迫着开发人员没有办法只好沿用一个被修补了千百遍的老框架，而不能彻底的进行重构重写。

第二个问题就是敏捷的皮毛

只学了频繁发布的皮毛，驱赶着开发人员频繁发版本，不给一个相对较长的时间让开发人员进行重构。

第三个问题就是原始的源代码管理方式

使用的源代码管理工具倒是流行的SVN，但是却没有领略源代码管理工具最基本的精神：协同工作、源代码变更管理和分支管理等。简直就是最原始最简单的那种管理方式，把源代码不断的拷贝一份给个版本号放在那里。问题1 系统各部分的代码存放在不同的服务器，从单一服务器上checkout出来的代码是不完整不能编译的，这是个小问题，我分别把各部分checkout出来不就OK了；要命的是 问题2 开发人员只有他所负责部分所在服务器的存取权限，要命吧，你checkout不出其他部分的代码；问题3，每个月只给1到2次commit代码的机会，每次一两天，除去这几天，开发人员只能自行管理代码，这TMD的哪里是SVN啊，还不如弃用SVN使用最原始的拷贝代码的方式得了。当然开发人员自有应对之策，自己建立个为自己或小组服务的代码管理服务呗，这个问题倒是大大促进了部分开发人员的源代码管理能力，svn、git、bazaar等五花八门的的工具使用的溜熟。（说个小窍门，若项目使用SVN，你使用非svn工具可以针对同一套代码同时使用两种工具）

第四个问题是变更管理

变更管理工具本是和源代码管理工具联合使用效果最佳的，但是公司的变更管理工具（简单抄袭CQ自己实现的）是不能和svn关联的。若要管理只能依靠开发人员在不同的系统上手工填写用于联系的信息，比如提交代码时手工在comments中填写相应的变更实施活动的细节，在变更实施活动结束时再在此手工填写提交代码时的svn revision号等细节。这个不是项目的问题的，是公司的问题，抄袭了皮毛，没有抄袭配置管理工具的灵魂。人家CQ是和CC关联的，你抄袭CQ但是却又不能和你的svn关联，这不是折腾人么，为啥抄袭CQ，而不是抄袭bugzilla（可以和svn集成），bugzilla都不叫抄袭，人家是开源的，叫二次开发，你只要不卖不发布只是自用，不用太理会版权协议，就是需要尊重协议了你害怕开源么？这有什么可怕的呢，你对bugzilla的开发只能叫非语言的本地化工作，人家都不一定待见你二次开发出来的功能。

不过么，手工能实现就手工呗，反正我的时间你付钱的（可惜的是我的时间本来可以更有用的）。项目由于存在上面说诉第三个问题，每月只能提交一两次代码，典型的变更管理流程是走不了了，变更实施活动的的验证等都是在开发者个人或小组的服务器上进行的。等TMD的变更活动实施完了，才等到每月一次的代码提交。不过这个嘛，有问题就有问题呗，本来部分不谙变更管理之道的人就抱怨变更管理流程，你没有能完整实施倒正和他的心意。第三个问题都忍了，这第四个问题还有啥不能忍的。

第五个问题软件项目盲目平台化

以为平台化是神器什么的，至少是现在怨声载道啊，产品开发备受拖延（好在我们软件开发人员都是神仙，如此恶劣的环境还在继续工作）。你提供了软件平台，那我们产品部门愿不愿意是我们的事情。其实这里有个很好的生态系统可供借鉴，Linux，发行版那是种类繁多啊，你开发的软件平台代码也只是一个产品（类比linux发行版，比如debian）的一部分，我产品愿意使用你的东西那我就使用，不愿意使用就不使用了呗。这就好比debian可以采用linus大神发布的的linux内核，也可以采用bsd内核,甚至hurd内核。也比如桌面，KDE和GNOME是linux发行版最常用的桌面系统，而除此之外还有xfce等等桌面存在，而ubuntu即将发布的11.04版本将采用unity shell，应该是gnome基础上发展出来的。

有这些参照物，其实软件平台和最终产品的关系其实很好确定，软件平台项目交付代码后，产品项目可以决定使用特定版本的平台代码，然后再在该平台代码基础上自由修改。除非产品不愿意跟随平台升级了，产品项目一般是不会大幅修改平台代码的。但是一定要给予产品维护小组这样的权利：决定使用某个版本的平台代码，决定使用平台代码的哪些模块，对已交付的平台代码任意修改。

可以这么理解吧，把平台代码暂定位主分支，而各产品的代码也是这个主分支上分支出来并不断自我演进的其他分支。类似于linux发行版的发行方式。