我最近加入了一家大型保险公司的IT部门。尽管部门的标题是“IT”,但在这里却写了很多代码。我听说过的Java,JSP,JavaScript,COBOL甚至是一些C++。所有允许保险公司,经纪人和其他打领带的白领 worker 签发新契约(Contract)并与客户打交道的程序均以该部门制定的代码为准。有人告诉我,按照母公司的标准,该部门是相当不错的,而且我们甚至还获得了一两个内部奖项。我们这个部门有17人,分成2或3个小组。正如您可能从COBOL的更高部分猜到的那样,平均年龄超过40岁(作为引用,我为29岁) 。

目前,没有适当的版本控制系统(尽管存在通用的备份方案)。需要时,文件将通过共享文件夹传递。通常,每个小组中都有一个人负责将文件的“最终”版本复制回生产服务器。我觉得这很荒谬,甚至有些危险。

我如何尝试说服管理层我们应该在本部门实现VCS计划?我自己从未部署过VCS,但是我工作过的其他每个地方都有一个。我认为从第一步开始,我会打出“我们到目前为止还好,为什么要打扰”的墙,再加上我大多数同事的年龄,我会觉得这一步是不必要的障碍。

我知道VCS的基本优点(可追溯性,细化备份,问责制等)。我希望通过实际案例和实际实现成本实现的增值示例来支持我的案例,而不仅仅是“但是,但是,但是,我们必须拥有一个愚人的VCS!” :-)

最佳答案

您不一定需要他们的许可。

在您的计算机上安装svn,开始使用它,然后说服您的团队其他成员也使用它。

然后观察并观察会发生什么。

编辑

  • 的基本思想是显示起来比说起来容易。
  • 用一个可行的实现/解决方案来支持您的想法是一个好主意。
  • 当然,如果您成功了,并且他们希望系统在部门/公司范围内使用,则您必须准备好支持过渡,知道如何安装和使用软件。
  • 继续前进并使用行业内公认的方法比讨论使用哪种系统要快。
  • 有一个很好的变化,这会让您注意到。您可能还会得到同行的尊重和支持。

  • 如建议的那样,可以在其他 Realm 采用相同的方法:
  • issue/bug tracking systems
  • quality tools
  • time tracking
  • continuous integration
  • 知识库,HOWTO,准则,教程,演示文稿,截屏的Wiki
  • 不同的IDE和工具
  • 构建工具
  • 自动部署
  • 可以节省您团队时间的各种脚本

  • ..任何可以明显提高您的工作质量,但不会(尚未)破坏现有方法和实践的项目。

    关于version-control - 如何说服部门实现版本控制系统?,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/1124363/

    10-13 06:07