项目管理现状之我见

[zenwong]

原作者：zenwong
原地址：http://blog.zenw.org/pro_manage_status_quo


前言

中国的软件行业也经历了不少年，很多公司也是什么什么几千认证的。大规模的不在少数。而很多公司都只是把规范、流程浮于表面，和应试教育一样死背、死记但一点都不会去应用，也不知道如何应用，更重要的是在利欲熏心挣块钱的思想下不懂得如何思考，考试的时候才拿起来研究，平时扔在一边。
知道开发存在问题，但不知道如何解决，知道很多标准和规范，但不会用，也不愿意聘请懂的人来帮他管理教他用。导致管理者管中窥豹后就闭门造车的自以为是的开始项目开发。问题出现后，项目上游部门把黑锅向下扔，接到黑锅的又继续扔，这使得大多时候在生态链最低端的开发部门很被动。
当然，如果遇到明理的管理者可能会知道项目出现问题的原因不可能只是某个部门的某个人。
更多的时候是管理者没按照流程办事，或是根本没有一个好的正常的流程。
一个不靠流程而是靠人管理的公司是要命的公司。

从SVN说起

在项目开发中SVN是大家最常用的工具，如果一个项目不使用SVN进行版本控制的话，我认为也是很可怕的。
但如何使用SVN却让很多人伤透脑筋，他们不是因为那些SVN的命令或如何使用一个按钮而犯难，而是具体的什么时候提交，什么时候更新，什么情况下创建分支，版本库太大怎么办。
我曾经就职的一家公司，他们就遇见了这种问题，个人总结一下，他们的问题根源是因为他们把SVN当成了上传工具。其实这种情况在很多开发团队中都存在，而且相当普遍。
在这种团队中，开发人员直接操作SVN，而不是某台测试服务器。有的团队发现了这个问题，就让他们的开发人员用自己的电脑来充当测试服务器，但这样做的后果是毁灭性的，这样无法确保每个开发人员都在一个相同的运行环境中测试自己的代码，通常最普通的路径权限就能让一个功能耽搁半天，然后接下来的半天用来解决由于电脑IP没有被授权而无法访问数据库的错误。
管理者要求开发人员将代码在本地（自己的电脑）测试完成后上传到SVN中。而且令人无法理解的是，很多管理者把测试服务器当作了一个很机密的东西，一般人无法操作，只有具备特定权限的人才可以通过SVN来更新测试服务器中的代码。这使得他们的版本库每天的提交和更新次数的总和可能都要逼近一百。
这使得管理者无法确定什么时候应该创建里程碑，现在的代码应该属于主干还是分支，因为一切都已经混淆到了一起，到了你中有我我中有你的地步。
其实这个问题是一个很初级的小儿科的项目管理问题，解决的方法很明确：在测试服务器中采用N+1的模式，也就是为每个开发人员在测试环境中配置好虚拟主机，分配好路径权限，这是开发人员用来自己测试的，并且允许开发人员在自己的虚拟主机中CHECKOUT出代码，然后在其上编辑，这样既确保了开发环境的统一，又确保了数据的安全。接着再创建另外一个虚拟主机，这个主机不允许任何人修改任何代码，他直接从SVN中CHECKOUT代码，这个主机用来供所有人测试使用，也就代表了项目的当前状态。这样还有一个好处，就是降低了公司开发成本，不再需要高配置的开发机器。当开发人员确认代码无误了以后才SVN UP上去，这样SVN就真正的成为了一个强大的版本控制工具，而不是一个初级的上传工具。


未完待续。。。

[黑泡泡选手]

是很不错的工具呀···

[以专业开发人员为伍]

lz不懂没有做过敏捷开发吧？是个实习学生？

告诉你一个事实。在优秀的团队中，每一个成员可能每隔几分钟、十几分钟、几十分钟就向svn提交一次。当它做一个小特性，一旦写出几十条代码，并且调试通过，就应该立刻提交。而不是到下班才提交一次。

lz搞行政吧，搞技术可能要把原本高强度的战争（项目管理）变成整天在那里探讨八股文章写法。

[xaqaga]

八股也有好文章。

简单的东西程序化，

复杂的东西表面化。

[我是一道光_]

[Quote=引用 2 楼 sp1234 的回复:]

lz不懂没有做过敏捷开发吧？是个实习学生？

告诉你一个事实。在优秀的团队中，每一个成员可能每隔几分钟、十几分钟、几十分钟就向svn提交一次。当它做一个小特性，一旦写出几十条代码，并且调试通过，就应该立刻提交。而不是到下班才提交一次。

lz搞行政吧，搞技术可能要把原本高强度的战争（项目管理）变成整天在那里探讨八股文章写法。
[/Quote]


yes

[iceofire]

没有争议就没有思想。支持楼主把想法说完。

[iceofire]

敏捷未必有效，过程化管理也未必不好用，关键在于裁剪。楼上某些同仁以自己的环境来将思想强加于人，未免有点不合适。

[地平线上的小树]

同意 iceofire

[ouyanghaiwa]

想法不错。可你也想想为什么别人不像你说的这么做啊！形势比人强啊！

[Defonds]

关注了

[jack_wq]

赞同 iceofire
什么用好了都可以发挥大作用，我不赞成盲目的跟风，敏捷开发可能确实很好，但是未必什么项目、什么公司都是最好用的，甚至有些场合可能效果很差。
用好了才是好的，空理论没有什么实际的意义。

[边城浪子]

要看具体应用场景。项目管理要做，搞互联网的话敏捷要搞，单项目管理不是SVN，SVN也不是项目管理的全部。

[以专业开发人员为伍]

比如说：

有的团队发现了这个问题，就让他们的开发人员用自己的电脑来充当测试服务器，但这样做的后果是毁灭性的，这样无法确保每个开发人员都在一个相同的运行环境中测试自己的代码，通常最普通的路径权限就能让一个功能耽搁半天，然后接下来的半天用来解决由于电脑IP没有被授权而无法访问数据库的错误。

（以上是lz原文）

这个描述就令人不由得想像作者可能是比较懒惰的。因为这个现象（不能在测试程序中灵活使用相对路径，没有授权IP）其实都是人的问题，如果你只是永远只用一台机器跑测试程序，就无法发现更多的问题，而且也无法方便地异地进行开发。