Cómo alentar la adopción del control de versiones

Recientemente comencé a trabajar en un equipo donde no hay control de versiones. La mayoría de los miembros del equipo no están acostumbrados a ningún tipo de control de versiones. He estado usando mercurial en privado para seguir mi trabajo. Me gustaría animar a otros a adoptarlo, y al menos comenzar a versionar su código a medida que desarrollan cambios. ¿Alguien puede darme consejos sobre cómo puedo alentar la adopción de un control de versión distribuido como mercurial? Cualquier consejo sobre cómo ganar personas incluyendo gerentes para DVCS sería muy apreciado.

Debe presentar un caso para el uso del control de versiones, y primero tratar de venderlo a sus compañeros de trabajo, y si eso falla, subir la cadena para proyectar el liderazgo y más.

Para los demás ingenieros de software, su caso debe centrarse en cómo ahorra tiempo y dolores de cabeza a largo plazo. Encuentre tiempos de su propio pasado o historias publicadas (blogs, artículos en revistas, libros blancos) sobre cómo el uso del control de versiones le facilita la vida. Si te has quemado por no tener control de versiones, hazlo personal. Si sus colegas desarrolladores han estado en la misma situación, deberían ver la luz y cómo estas herramientas pueden ayudarlos.

Esta es tu mejor apuesta. Aunque no puedo encontrar las fuentes en este momento, he leído (en un par de lugares) que los cambios más efectivos para procesar provienen de los desarrolladores, que tienen que lidiar con los cambios. Si puede lograr que los desarrolladores se unan, logrará dos cosas. Primero, ya tiene la aceptación de las personas que se verán afectadas por el cambio de proceso. En segundo lugar, hay un grupo de personas para convencer a la gerencia de que este es un esfuerzo que vale la pena y mejorará el producto y el proyecto.

Sin embargo, si no puede obtener el apoyo del equipo de desarrollo y aún siente una gran confianza en la implementación del control de versiones, puede pasar a la administración. Pero se vuelve más riesgoso si va solo, ya que no solo tiene que preocuparse por vender la mejora, sino también por la reacción de sus colegas.

Para la gestión de proyectos, programas y organizaciones, el caso debe ser cómo implementar el control de versiones puede ahorrarle tiempo y dinero a la organización. A las personas de este nivel les importa cuánto cuesta el proyecto, dónde se encuentra en comparación con las estimaciones, etc. Busque libros blancos, libros, artículos y otros documentos y publicaciones profesionales que expliquen cómo la implementación del control de versiones ha ahorrado tiempo y dinero a otras organizaciones a largo plazo. También puede introducir una perspectiva de calidad aquí, si su organización está interesada en la calidad del software.

Mencionó específicamente que desea utilizar un sistema de control de versiones distribuido. No lo fuerces por la garganta del equipo u organización. Preséntales el control de versiones y sus opciones. Aunque personalmente puede preferir usar un DVCS (como Mercurial), puede que no sea la mejor opción para su equipo y organización. El uso de una herramienta que no está bien ajustada solo empeorará las cosas con la paliza.

Además, tenga en cuenta los riesgos de introducir el proceso tarde . Aunque el uso del control de versiones es una práctica recomendada comúnmente aceptada, podría ser demasiado tarde para introducirlo de manera efectiva en el proyecto actual sin un gran riesgo para la finalización del proyecto. En cambio, recomendaría centrarse en mejorar el status quo para futuros proyectos y equipos.

Además, este es un enfoque general que puede seguir para llevar a cabo cualquier proceso o mejora tecnológica.

La primera pregunta es: ¿qué hacen actualmente? Seguramente, cada desarrollador no tiene el código fuente pegado en su propia caja que cambia a voluntad. Una vez que tenga el proceso que siguen actualmente, puede sugerir algunas herramientas que mejoren este proceso; por lo general, un SCM es ideal para ayudarlos con esto, en lugar de hacer que sigan un proceso diferente.

El punto principal aquí es, si tienen una forma de trabajo pseudo-SCM, tal vez almacenando la versión actual en un servidor en algún lugar, entonces debe determinar si un DVCS o un CVS es más apropiado, no intente venderlos Mercurial si SVN se ajusta mejor.

La forma más rápida es convencer a la gerencia de que es necesario.

Haz algunos cálculos:

Costo del software de control de versiones - gratis.
Costo del hardware para soportar el repositorio: un servidor.
Costo de implementar software: un par de días de trabajo para un equipo pequeño, aumentando para equipos más grandes.

Costo de no implementar el control de versiones:

El mejor de los casos: los días perdidos debido a que faltan las ediciones, se sobrescriben los cambios, etc., errores recurrentes, etc.
En el peor de los casos, por muchos años de esfuerzo que su equipo haya dedicado hasta ahora.

Esta última cifra es el peor de los casos en el que pierde todo su trabajo debido a una falla del servidor, etc., pero incluso los escenarios del "mejor caso" deberían informarles por qué es necesario. El costo de los errores recurrentes podría ser mayor, ya que podría conducir a la pérdida de clientes.

El equipo de desarrollo también debe comprender estos costos y dado que la mayoría (si no todos) el software de control de versiones se integra a la perfección con los IDE en estos días, ni siquiera notarán que está allí la mayor parte del tiempo.

La administración generalmente se preocupa más por ahorrar dinero. ¡Enfatice cómo el control de versiones puede beneficiar financieramente al equipo y obtendrá su atención de inmediato!

Hay un aspecto que otras personas aquí no han mencionado que creo que tienes en tu esquina, estás hablando del control de versiones distribuidas , por su propia naturaleza, puedes colarte en una práctica de facto, un desarrollador a la vez Con un control de versión más completo, como el que usamos en mi oficina (MS Visual SourceSafe), le sería difícil acercarse al tipo en el cubo frente al mío y venderlo, uno por uno, según los méritos de control de versiones. Sin embargo, con (cualquier) DVCS, puede decir "hey, intente esto y vea si le gusta. Le mostraré las cuerdas y con gusto responderé cualquier pregunta, lo guiaré, bla bla paja". De esa manera, no necesita un "proceso" desde arriba, puede construir un mandato de base, una persona a la vez.

Sobre la base de la respuesta de gbjbaanb.

La clave aquí es que debe adaptar el proceso de control de versiones a cualquier proceso existente y mostrar cómo ahorra el esfuerzo del resto del equipo.

Personalmente, también estoy a favor de Mercurial, pero no necesariamente quiero imponerlo a personas que no están acostumbradas al control de versiones porque es un poco más difícil de comprender que un sistema de control de versiones de bloqueo basado en un servidor antiguo. Dicho esto, si se trata de un verdadero sitio de greenfields, podría ser mejor ir por completo, saltear los años 80 y 90 e ir con Mercurial. También miraría algunas de las cosas del ciclo de vida del software de terceros creadas en torno a Mercurial: estoy seguro de que hay una, pero su nombre se me escapa;)

Supongo que trabajas para una empresa pequeña y que eres relativamente nuevo en el equipo, por lo que podría ser difícil de vender, especialmente si el resto del equipo está atrincherado y tiene la confianza de la administración. Podría ser mejor dejar que llenen algo mal y luego acudir al rescate. Eso no significa sabotaje, solo espera lo inevitable.