¿Cómo convencer a un compañero de equipo, que se ve a sí mismo como senior, para que aprenda los conceptos básicos de SVN? [cerrado]

Para comenzar con algunos antecedentes, asumí un nuevo puesto de desarrollador este verano y terminé siendo el miembro más nuevo del equipo, pero con la mayor experiencia en el cinturón.

Hasta ahora, he logrado impulsar las iniciativas de cordura con la suficiente facilidad debido a los bajos costos de adopción (en términos de tiempo y esfuerzo). Sin embargo, las cosas se han nivelado un poco.

Uno de mis compañeros de equipo, aunque experimentado, no entiende realmente SVN. Naturalmente, las áreas en blanco en su mapa mental que representan los océanos de SVN hacen que adopte patrones de uso bastante extraños.

Por ejemplo, había declarado una política de "1 confirmación SVN por día por desarrollador" porque de lo contrario "el servidor pronto se quedaría sin espacio en disco". Cuando le expliqué que los commits de SVN son deltas, no copias completas, respondió con dudas e incluso hoy no estoy completamente seguro de si entiende lo que significa.

También tuvimos una acalorada discusión sobre si incluir la .projectconfiguración de Eclipse en SVN. Mi compañero de equipo insistió en que deberíamos, aunque ha causado numerosos conflictos sin sentido. Estaba en contra de mantener archivos de configuración de desarrollador individuales en SVN. Finalmente, resultó que mi compañero de equipo tenía la práctica de volver a verificar todo el árbol de origen después de cada confirmación para asegurarse de que el "código comprometido en el repositorio funciona". Esa fue la razón por la que se mantuvo firme en mantener la configuración del proyecto en SVN, por lo que sería fácil volver a importar el proyecto. Cuando le expliqué que commit sincroniza la copia de trabajo a byte a byte remoto, lo que hace innecesario volver a realizar el pago, mi compañero de equipo respondió con dudas nuevamente y finalmente descartó todo el asunto como insignificante.

En mi opinión, nuestro equipo pierde tiempo resolviendo conflictos de SVN en los archivos de configuración del proyecto que contienen solo configuraciones específicas del desarrollador que no necesitan compartirse en absoluto con SCM. Todo este lío porque alguien ajustó el proceso en torno a suposiciones incorrectas.

¿Cómo puedo convencer a un compañero de equipo, que se ve a sí mismo como senior, para que comprenda mejor los conceptos básicos de SVN?

En mi opinión, es mejor separar aquellos problemas que causan problemas / daños directos al proyecto de aquellos que afectan solo a ese desarrollador único . Por ejemplo, si prefiere revisar todo varias veces al día, lo retrasará, pero de lo contrario no afectará a los demás. Así que puedes dejarlo hacer eso (hasta que haya un retraso notable en el rendimiento de su trabajo) y ahorrarte la molestia de discutir sobre ello.

Otros temas que menciona, como mantener los .projectarchivos de Eclipse en el repositorio, o 1 confirmación por día, es donde debe enfocarse, para permitir que el equipo progrese de la mejor manera posible. En primer lugar, debe pedir / recopilar comentarios de los otros miembros del equipo , si esto también les causa problemas. Si hay otros, juntos pueden ejercer más presión , y si es necesario, pueden escalar más fácilmente un problema hacia la administración.

Con respecto al "SVN se queda sin espacio en disco", sería fácil refutar su creencia haciendo un experimento (potencialmente en un repositorio de prueba por separado). Solo necesita monitorear el tamaño de la jerarquía del archivo de repositorio físico antes y después de confirmar los cambios en un gran archivo de texto, o incluso muchos archivos. Si eso no lo convence, nada puede.

En ese caso, desafortunadamente probablemente tengas un problema de autoridad, donde el otro tipo considera que aceptar el consejo de alguien "de menor rango" como una pérdida de su dignidad. Tales conflictos no pueden resolverse mediante un argumento lógico. Debe escalarlo hacia la administración, pero tenga cuidado de asegurarse de contar con el apoyo suficiente (de sus compañeros de equipo y / o administración) antes de hacerlo. Tal movimiento puede ser percibido por el otro tipo como un ataque abierto, por lo que puede tener consecuencias problemáticas (para cualquiera de ustedes y / o la paz de todo el equipo). Así que piense tres veces y discuta con sus colegas de apoyo antes de hacer ese movimiento.

Si su empresa usa wiki, escriba algunas publicaciones de alta calidad sobre SVN:

• ¿Por qué deberías usarlo?
• ¿Cuándo deberías usarlo?
• ¿Qué problemas resuelve?

etc.

Atraerá la atención de CTO, y todos los que se nieguen a usar tendrán que usar :)

Como líder, gerente y miembro del equipo, he tenido que lidiar con la resolución de conflictos profesionales y de personalidad en muchos niveles. No importa en qué rol me contraten, normalmente me aceptan como líder, incluso cuando no quiero el papel. La razón de esto es la forma en que trato estos conflictos.

A diferencia de muchas de las personas aquí, no estoy de acuerdo en que lidiar con esta situación sea un "darse por vencido" o "mostrarle una nueva herramienta" o "esperar a que se caiga de cabeza o se desanime". Lo más importante es que nunca es una buena idea esperar hasta que los roles estén más firmemente definidos. Esos roles se definen por personas que no esperan, por sus convicciones, ética y capacidad para lidiar con situaciones críticas, ya sea que involucren a personas o no.

Existen varios métodos para tratar con el tipo de persona que está describiendo en estas situaciones. El primer y más importante paso es investigar por qué se está comportando de la manera que es. Tiene poco que ver con lo que él sabe o no sabe. Él podría haber encontrado esta información fácilmente anteriormente, por lo que la pregunta realmente es una de dos cosas: "¿Por qué no lo hizo?" o "¿Por qué está rechazando la información que se le proporciona?" Esto lo ayudará a encontrar exactamente lo que debe abordarse.

En mi experiencia, los programadores (incluido yo mismo) rechazamos las buenas prácticas o las nuevas herramientas por solo algunas razones:

• La fuente no es creíble. En una industria que cada día se polariza más entre el "culto de Mac" y los "adoradores de la EM"; entre "ideología de código abierto" y "practicidad de propiedad" ... etc, etc. - Hay muchos que siempre tienen dudas sobre la información proporcionada y su potencial de corrupción debido al sesgo del remitente o del escritor, incluso cuando esa información es verificado como creíble.
• Malas experiencias prolongadas ... con una tecnología o práctica similar o incluso la misma. Nada es perfecto cuando comienza, y muchos comienzan con menos de 1/4 de las características de las que terminan. Es completamente posible que haya tenido muchas horas o días o incluso semanas trabajando con un producto inferior o el mismo durante una fase mal implementada.
• Una fuente "creíble" ... entra en conflicto con la información que se le presenta. Por "creíble", me refiero a alguna persona o entidad en la que confía. Muchas personas tienden a elevar a las personas en las que confiamos a niveles que no representan la realidad. Esta fuente ni siquiera tiene que haber impuesto esta creencia a la persona. Muy a menudo, lo hacemos nosotros mismos. A menudo nos da algo o alguien a quien aspirar a ser, al menos en un aspecto.
• Falta de seguridad Esto fue destacado por un póster anterior. Nuestros programas se convierten en activos desde el momento en que comenzamos a trabajar en ellos. No solo para las empresas para las que trabajamos, sino también para las personas con las que trabajamos. Esto no es simplemente un problema de control. Algunos de nosotros queremos poder mostrar nuestras cosas ordenadas a las personas que nos importan. Algunos de nosotros queremos asegurarnos de que no sea dañado por una persona o producto externo. Para algunos, es una extensión de cómo pensamos y sentimos, incluso. Alberga algunas de nuestras filosofías e ideologías y expone nuestros núcleos intelectuales. Para muchos, es nuestro futuro, ya sea para una clase, un empleador o un cliente. Para algunos es todo eso. La "seguridad" en este sentido no se aplica a los datos, necesariamente, o al código.

Averiguar cuál es el factor es con frecuencia bastante fácil. Lleve a la persona a un entorno neutral. Explique a la persona lo que está observando, en general. Pregúntele honestamente a la persona qué está causando este comportamiento. Ahora, no siempre sale bien, pero la mayoría de los adultos responden bastante bien cuando parece querer ayudar a alguien que parece estar actuando irracionalmente. Lo más probable es que no esté actuando irracionalmente, pero no es consciente de que nadie puede entender lo que realmente está sucediendo.

Una vez que descubra cuál es el problema, puede equiparse con las herramientas adecuadas para solucionarlo. Si es el escenario # 1, aliéntelo a hacer la investigación de las fuentes en las que confía y (esto es importante)volver a usted con sus propios hallazgos. Esto le dirá que su propia información tiene valor para usted. En el caso del escenario # 2, proporcione comparaciones precisas con lo que es diferente ahora que antes. Anímalo a intentarlo, pero ten un plan de respaldo para ver si sale mal. Para el escenario # 3, dígale que solicite su fuente con SU información. Lo más probable es que su fuente no tenga los puntos de vista que él cree que tiene, sino que lo hizo al mismo tiempo. La mayoría de nosotros nos adaptamos con el tiempo, por lo que su punto de vista probablemente ha cambiado. Si no está dispuesto, anímelo a presentarle su fuente. Y finalmente, para el escenario # 4, asegúrele que sus preocupaciones son suyas. (Deberían estar en algún nivel) Demuestre cómo esta "nueva" herramienta puede proteger sus intereses y aumentar su seguridad. Y si no puede,

Sé que todo esto suena demasiado simple para funcionar, pero a veces simplemente lo hace. De hecho, cuanto más sincero eres, más a menudo lo hace. Al abordar sus necesidades, usted está abordando las necesidades del equipo, ya sea que él sea "senior" o no, porque él es parte del equipo. Demostrarle que quiere estar en la misma página que él, pero que simplemente no lo está, podría alentarlo a comenzar a trabajar junto con usted. Si ha hecho todo esto y aún no llega a una resolución, ha hecho todo lo posible para hablar con el líder del equipo.

FuzzicalLogic

Hay mucha superstición en torno al control de fuentes. Es contrario a la intuición, la matemática es arcana e involucra el activo más importante que posee una compañía de software. Tengo que admitir que hay una parte de mí que todavía no confía en él. Pero no lo haría sin un minuto.

Una solución podría ser ofrecer asumir la responsabilidad de cuidar el repositorio. Por supuesto, si lo presenta como "es mucho trabajo para usted, y esto resulta ser un área en la que tengo algo de experiencia", en lugar de "no sabe lo que está haciendo" eso tendrá Una mejor oportunidad de trabajar.

Si "se ve a sí mismo como un anciano" significa lo que creo que significa, no lo abandonará porque lo ve como una fuente de autoridad y control. Por lo tanto, la solución para usted podría ser usar Git localmente para administrar unidades y ramas de confirmación sensatas, luego simplemente presione para svn una vez al día como él lo solicite. Git está diseñado como un sistema peer-to-peer y para tener una copia de repositorio completa en cada máquina local. Puede ofrecer git a otros desarrolladores que prefieran hacerlo de esa manera, y puede seguir siendo solo un complemento de SVN que los grupos de trabajo individuales (ya sea uno o más desarrolladores, formales o ad-hoc) usan internamente. Y cuando llegue el día en que el hombre mayor ceda, se mude a otro departamento o empresa, o se vea en un rincón irrecuperable con sus políticas de SVN, tendrá una ventaja inicial para limpiarlo todo.

Solo habla con ellos. Mira, soy un desarrollador senior, pero hay cosas que no sé. Esa es la naturaleza del negocio. Si se ponen a la defensiva o son agresivos, ese es un problema de personalidad con el desarrollador por si acaso y eso debe ser tratado por el líder del equipo, o si ellos son el líder del equipo, por su jefe.

Comience una iniciativa de bolsos marrones, una vez muy pocas semanas, alguien habla sobre algo que sabe a la hora del almuerzo y se lo presenta a los demás.

Usas esto como excusa para presentar SVN en detalle y tal vez parte del pensamiento detrás de algunas de las alternativas.

Unas semanas después, alguien más puede intentarlo.

Intentaré darle algunas pistas respaldadas por mi experiencia personal.

Uno de mis compañeros de equipo, aunque experimentado, no entiende realmente SVN. Naturalmente, las áreas en blanco en su mapa mental que representan los océanos de SVN hacen que adopte patrones de uso bastante extraños.

Por ejemplo, había declarado una política de "1 confirmación SVN por día por desarrollador" porque de lo contrario "el servidor pronto se quedaría sin espacio en disco". Cuando le expliqué que los commits de SVN son deltas, no copias completas, respondió con dudas e incluso hoy no estoy completamente seguro de si entiende lo que significa.

Incluso si el espacio en el disco fuera un problema, siempre podría confirmar muchos archivos a la vez, por lo que creo que lo que sugiere es la solución incorrecta. Además, es posible desperdiciar mucho espacio al registrar archivos binarios grandes porque SVN no almacena deltas para archivos binarios. Un check-in por día también es malo porque te obliga a cometer cambios que no pertenecen, por ejemplo, en caso de que arregles más de un error por día.

La solución que hemos adoptado en nuestra empresa es que hay un filtro que rechaza cualquier confirmación que contenga archivos binarios. Podemos forzar la confirmación mediante el uso de una palabra clave especial en el comentario de check-in (tenemos que mostrar a SVN que sabemos lo que estamos haciendo). Una vez en un año o dos, un gerente de proyecto archiva las ramas antiguas y las elimina del repositorio. Con esta estrategia no tenemos problemas de espacio que conozco (nuestro repositorio admite varios proyectos diferentes y tiene más de 100000 revisiones).

En resumen, podría decirle que está de acuerdo con él en que el espacio en disco es un tema importante pero, por otro lado, señalar

1. la importancia de los registros relacionados con funciones en lugar de un registro diario monolítico;
2. el hecho de que al registrar un archivo binario grande por día, uno podría llenar el disco de todos modos.

Luego, podría sugerir que tenga una reunión (posiblemente también con otros desarrolladores o administradores del sistema) para discutir estrategias para mantener el uso del espacio en disco bajo control (por ejemplo, filtros de archivos binarios, copias de seguridad periódicas y limpieza de ramas viejas no utilizadas).

También tuvimos una acalorada discusión sobre si incluir la configuración del proyecto Eclipse en SVN. Mi compañero de equipo insistió en que deberíamos, aunque ha causado numerosos conflictos sin sentido. Estaba en contra de mantener archivos de configuración de desarrollador individuales en SVN. Finalmente, resultó que mi compañero de equipo tenía la práctica de volver a verificar todo el árbol de origen después de cada confirmación para asegurarse de que el "código comprometido en el repositorio funciona". Esa fue la razón por la que se mantuvo firme en mantener la configuración del proyecto en SVN, por lo que sería fácil volver a importar el proyecto. Cuando le expliqué que commit sincroniza la copia de trabajo a byte a byte remoto, lo que hace innecesario volver a realizar el pago, mi compañero de equipo respondió con dudas nuevamente y finalmente descartó todo el asunto como insignificante.

En mi opinión, nuestro equipo pierde tiempo resolviendo conflictos de SVN en los archivos de configuración del proyecto que contienen solo configuraciones específicas del desarrollador que no necesitan compartirse en absoluto con SCM. Todo este lío porque alguien ajustó el proceso en torno a suposiciones incorrectas.

¿Utiliza un servidor de compilación? Tenemos un servidor de compilación que revisa el proyecto completo y lo compila todas las noches. A la mañana siguiente, los probadores tienen un instalador listo para probar del producto (si la compilación maestra se ejecutó correctamente) y nosotros (los desarrolladores) tenemos un informe de compilación con todas las advertencias (y errores, en caso de que haya alguno). Por supuesto, es necesario configurar los archivos de configuración estándar para la construcción de servidor y comprobar a. Cada desarrollador puede comprobar a cabo junto con el resto del proyecto, pero no se le permite comprobar en cualquier cambios locales.

En este escenario, usted aborda su necesidad de poder verificar el proyecto completo y construirlo en cualquier momento. También evita perder tiempo para fusionar los cambios que no deberían haberse verificado en primer lugar porque no son parte del producto: el producto es la construcción maestra, y eso debe mantenerse limpio. Si alguien interrumpe la compilación maestra (por ejemplo, registrando su propio archivo .project), puede revertir los cambios u obligar a ese desarrollador a solucionar el problema.

Tal vez si vuelve a plantear el problema, puede volver a sugerirle una reunión (posiblemente con otros desarrolladores) y encontrar una estrategia común juntos.

¿Cómo puedo convencer a un compañero de equipo, que se ve a sí mismo como senior, para que comprenda mejor los conceptos básicos de SVN?

Creo que la mejor estrategia sería evitar llevar el conflicto a un nivel personal y más bien discutir los problemas en cuestión y las posibles soluciones. Si tiene la impresión de que está buscando una confrontación personal, aquí hay algunas sugerencias (de nuevo, por experiencia personal):

• ¿Cómo es la dinámica de tu equipo? ¿Sus otros colegas tienen una experiencia similar con este compañero de equipo? Hay muchos indicios pequeños, no demasiado explícitos, que un equipo puede dar a uno de sus miembros para desalentar ciertos comportamientos (pequeños chistes u observaciones) y alentar una confrontación constructiva (proponer una reunión o mencionar un tema informalmente durante un descanso para tomar café). ) A veces, un buen equipo puede aislar rápidamente un elemento perturbador y volver a la normalidad.
• ¿Qué tan buena es la gestión de su personal? Tuvimos un caso de conflicto en nuestra empresa y el jefe de personal tuvo que intervenir para aclarar la situación. No fue agradable, pero a veces el ambiente de trabajo se deteriora tanto que no mejorará por sí solo. Espero que este no sea su caso (no tengo la impresión de que haya llegado tan lejos todavía), pero siempre es bueno saber si tiene una buena administración de personal o si tiene que resolver los conflictos por su cuenta.

¿Por qué estoy escribiendo esto? Dices que quieres "convencer a un compañero de equipo, que se ve a sí mismo como senior, para que comprenda mejor los conceptos básicos de SVN". Para mí, parece que el conflicto podría ser demasiado personal. Algunos psicólogos sostienen que el 70% de nuestra comunicación es a nivel emocional, si este nivel no funciona, la gente deja de hablar sobre hechos porque están demasiado ocupados lidiando con las emociones.

Entonces, además de explicar sus puntos, también podría intentar hacer algo para mejorar la comunicación. Invitar a tomar un café o almorzar juntos, tener una breve conversación sobre un tema que no está relacionado con el trabajo, etc., puede mejorar la comunicación y atraer la atención de su colega a los hechos importantes que desea que comprenda. Si acepta este tipo de comunicación, entonces quizás los conflictos que tuvo hasta ahora estuvieron relacionados con el hecho de que no se conocen bien y hubo algunos pequeños malentendidos, pero probablemente esté abierto a construir una colaboración constructiva. Si se niega, entonces podría haber una hostilidad más profunda de su lado.

En este caso, creo que deberías esperar hasta que tus roles se aclaren. Si su compañero de equipo no tiene oficialmente un rango más alto que el suyo, no tiene sentido irritarse por sus intentos de mejorar las cosas. Con el tiempo, tendrá que aceptarlo o hacer el ridículo si sigue intentando demostrar que sabe más. Si tiene un rango más alto, debe encontrar una manera de hacerle entender que esto no está en discusión: sus observaciones están destinadas a mejorar la productividad y no a socavar su posición, esto debe ser 100% claro. Cuando los roles se han aclarado, si todavía no puede aceptar sugerencias constructivas o críticas, entonces realmente debe tener algún problema con la autoestima o algo así.

Entonces, si todas las estrategias anteriores fallan y sigues sintiéndote (muy) frustrado, me temo que lo único razonable es empacar tus cosas y buscar un lugar mejor. Hice esta experiencia hace tres años y encontré una compañía mucho mejor en la que estoy muy satisfecho ahora. Tal vez este no sea su caso (espero que no, por supuesto), pero trate de entender este punto también.

Solo mis 2 centavos.

Indíquele algo de material de aprendizaje sobre cómo funciona SVN y cuáles son las mejores prácticas al usar SVN.

Como dice @Peter: elige tus batallas con cuidado y no desperdicies tu energía peleando con alguien que obviamente no entiende los conceptos básicos. SVN no es exactamente una tecnología de punta y ha estado aquí por un tiempo, por lo que hay suficiente información al respecto.

Intente mantener un registro de la 'pérdida de tiempo SVN'. Cada vez que haya un problema de conflicto / pago / versión que deba resolverse, tome nota de cuánto tiempo le llevó a usted / al equipo resolverlo. Si resulta que está perdiendo una cantidad considerable de tiempo cada semana, intensifíquelo con él y la gerencia. Estoy seguro de que la gerencia pronto solicitará soluciones si se dan cuenta de que la productividad puede mejorarse con simples cambios en el proceso de trabajo.

O trate de convencer a su colega para que tenga una semana de prueba en la que el equipo use su sistema de registros (si eso es fácil de lograr con sus proyectos actuales y su base de código). Prométale que si no funciona, puede volver al sistema anterior después de que termine la semana. Pero podría venir después de probarlo él mismo.

1. Deje que Subversion resuelva el problema por usted. La forma en que lo dices, tu compañero de trabajo es relativamente poco sofisticado cuando se trata de Subversion. En ese caso, una solución técnica podría ser una buena opción. Si el resto del equipo está de acuerdo y puede obtener la bendición de su gerente, agregue un global-ignorescampo al archivo de configuración del repositorio para que pueda excluir los archivos .project y otros que no desee bajo el control de versiones.

2. Ayúdalo a salir. En lugar de imponerle su forma de hacer las cosas, intente ayudar al hombre a hacer las cosas a su manera sin causar problemas a los demás. Si su compañero de trabajo está trabajando en su propia rama, realmente no debería importarle lo que comete. Si quiere confirmar su archivo .project para poder retirar una copia nueva de todo el directorio, no hay problema para usted. Lo único que debería importarle es que no vuelva a fusionar su archivo .project con la rama de desarrollo común. Eso debería ser fácil de administrar, nuevamente, configurando la propiedad ignorar en la rama de desarrollo para excluir el archivo .project.

3. Busque apoyo desde arriba. No te metas en una discusión de "no eres el jefe de mí" con el chico, pero si su comportamiento te está causando un problema, asegúrate de que tu gerente esté al tanto de la situación. Si no está seguro de cómo acercarse a su gerente, intente pedirle consejo: "Mike, he estado tratando de hablar con Larry, pero no lo estoy logrando. Insiste en X, Y y Z, y el resto de nosotros pasamos mucho tiempo innecesario trabajando en los problemas que se crean. ¿Pueden darme algunos consejos sobre cómo tratar con el tipo? "

4. Ignóralo. ¿Por qué alguien del equipo escucha a este chico? ¿Tiene alguna autoridad real sobre el proyecto? ¿ A quién le importa si declara una política de un compromiso por desarrollador si no tiene el poder para hacerla cumplir? Deja que piense que es Yertle the Turtle si lo hace sentir mejor, pero no dejes que te cree problemas reales.

Haz que despidan al tipo y acaba con el talón arrastrando y la evidente mancha hacia la tecnología más nueva. O realmente explotar y comenzar a usar GIT. Si no puede entender SVn, seguramente GIT lo dejará boquiabierto.

Parece que estás luchando en una batalla perdida pero puedes salir adelante. Maquiavelo en El Príncipe describió lo difícil que es para uno cambiar el status quo. Sugeriría leer ese capítulo nuevamente y luego tal vez no hacer lo que él sugiere: puede ser duro.

Debe comunicar sus inquietudes al desarrollador senior en privado y asegurarse de criticar constructivamente la forma en que se hacen las cosas y no a él ni a ningún otro desarrollador. Luego ofrézcase para hablar y escribir una guía de mejores prácticas. Muéstreles cómo comprender mejor SVN les facilitará la vida. En definitiva, se trata de costos y eficiencia. Si puede demostrar que su forma de mejorar las cosas sin pisar los dedos de los pies, entonces puede ganar esta.

Trate de entender por qué el (los) hombre (s) mayor (es) está (n) usando el repositorio tal como está. ¿Cuáles son sus preocupaciones? ¿Qué es lo que están tratando de lograr? ¿Cómo puedes ayudarlos a ser más productivos? Sobre todo, trate de mantener un enfoque tranquilo y profesional. Es fácil frustrarse. Sea asertivo: Asertividad en el trabajo: una guía práctica para manejar situaciones incómodas de Ken Back y Kate Back es una buena lectura. Finalmente, piense "¿cómo me convencería de cambiar?" Sea un defensor del diablo honesto y eso puede ayudarlo a encontrar buenas respuestas y preguntas que hacer.

Como nota al margen, tendría cuidado de usar el humor. Puede hacer maravillas o puede hacerte sonar como un imbécil. Por lo tanto, lo evitaría.

Básicamente, elige tus batallas con cuidado, ya que es posible que no ganes esta. Si ese es el caso, ya no te importa o busca un trabajo diferente. Duro, lo sé.

Hace unos 8 años estuve al revés de su posición cuando SVN era una tecnología razonablemente nueva. Yo era un desarrollador senior y un desarrollador junior me solicitó / con errores para instalar SVN (en realidad, era más exactamente el soporte de TI que un desarrollador). Tomé una mente abierta a pesar de mis sospechas iniciales sobre el aumento de la carga de trabajo, la complejidad innecesaria, etc., y luego me convertí en un gran admirador.

En mi opinión, por lo que ha descrito, este problema definitivamente se reduce a las personalidades del equipo: su terquedad está demostrando ser un obstáculo para el equipo en general sobre este tema. Puede que sea mejor simplemente retroceder en este punto y dejar que la presión del resto del equipo se desarrolle naturalmente para forzar su mano.

Esto es más o menos un caso de "falta de autoridad" y una persona que aplica el poder de su propio miedo para mantener las cosas "bajo control".

Para resolver esto, encuentre a alguien que haya inspirado a su compañero de equipo o alguien a quien respete y que pueda explicar la urgencia de usar algo como SVN. De esa manera, su miedo al cambio y básicamente a "perder autoridad" no está en juego porque no es un miembro del equipo que le dice qué hacer. Me abstendría de usar a alguien como un gerente para hablar con este tipo porque eso solo agrega presión e incluso podría crear una situación más estresante para usted.

Hace poco leí Impulsando el cambio técnico: por qué las personas de su equipo no actúan sobre las buenas ideas y Cómo convencerlos de que deberían , publicado por The Pragmatic Programmers. Este libro proporciona antecedentes que debe conocer antes de intentar introducir un cambio técnico, una serie de patrones en las personas que se oponen o se niegan a cambiar, técnicas para implementar los cambios y luego estrategias para maximizar el uso de estas técnicas y de todas las personas que lo rodean. tú.

Según su publicación, diría que su compañero de equipo probablemente cae en el patrón Desinformado o Cínico, pero también podría ser un caso de Irracional. Algunas de las técnicas recomendadas para contrarrestar a este tipo de personas son ganar experiencia dentro del entorno objetivo para que pueda encontrar cualquier problema y presentar respuestas a los problemas que otras personas enfrentarán antes de que sucedan, resolver el problema correcto, entregar el mensaje apasionadamente pero sin ser demasiado celoso, demuestre las técnicas mostrando claramente las ventajas de sus métodos y herramientas y véndalas orgánicamente (pero no cree problemas solo para resolverlas), y obtenga publicidad e inscríbase en el resto de su equipo. Sin embargo, si él es irracional, allí '

Finalmente, luego de comenzar a usar estas técnicas, necesita una estrategia general. Es importante no dejar que aquellos que son activamente hostiles o irracionales lo retrasen, ignórelos. En cambio, encuentre personas a las que pueda demostrar y convenza de que tiene una mejor manera y aplique las técnicas apropiadas basadas en ellas como individuo. Una vez que más personas vean las mejoras que ofrece su conocimiento, úselas para continuar convenciendo a otros. Finalmente, use este esfuerzo de base para convencer a la gerencia de que hay una mejor manera, pero asegúrese de expresarlo en términos que puedan entender (tiempo, dinero, calidad).

No intentes "convencer" a este tipo de nada. Las personas (incluso los programadores) no responderán ni respetarán los argumentos razonables / lógicos de alguien a quien vean de menor importancia. Así que no pierdas el aliento. En cambio, trabaje para construir un nivel de confianza con esta persona. Esta persona escuchará lo que tiene que decir solo cuando esté abierto a ello.

Mientras tanto, tienes problemas reales:

1. El chico revisa su archivo .project en el repositorio: simplemente ignórelo. no tiene que modificar el archivo, ni nadie más en el equipo que lo sepa mejor. Déjalo ir. Si le da a su "miembro superior" un sentimiento cálido y feliz como una manta de seguridad, que así sea.
2. Existe un presupuesto percibido en el espacio en disco: esta es la razón por la cual el Sr. Senior dicta 1 compromiso por día. ¿La escasez de espacio es real o percibida? Incluso si solo se percibe, tal vez hay algo que puede hacer para cambiar esa percepción. Eso debe tratarse de inmediato: si toma la iniciativa, también ayuda a generar confianza.

También podría agregar que este tipo estará dispuesto a adoptar mejores prácticas de SVN cuando piense que fueron sus ideas. Eso requerirá un poco de previsión por su parte, y probablemente se tomará el crédito por establecer mejores prácticas, pero usted está de acuerdo con eso.