Como el chico nuevo, ¿cómo hago para que la gente actúe en toda su gran charla?

Soy "el chico nuevo" en el departamento de TI de una pequeña empresa manufacturera. Tenemos un pequeño equipo de 3 desarrolladores de aplicaciones + 1 rol de desarrollador de base de datos/dba-ish. Llevo unos meses aquí, así que estoy llegando al punto en el que he empezado a ganarme la confianza y el reconocimiento de mis compañeros.

Durante mi entrevista, se habló mucho sobre querer ser más ágil. Todavía se habla mucho al respecto, pero ninguna acción al respecto. Para ser honesto, no me importa si somos "ágiles" o no, pero realmente necesitamos comenzar a hacer algunas cosas que son simplemente mejores prácticas, ágiles o no. Cosas como pruebas unitarias y revisiones de código. Sí, vayamos con esos dos primero, ya que son los más rentables.

Ahora, he estado probando el código que toco antes de modificarlo. En parte porque he visto los beneficios y en parte porque tengo miedo de romper cualquier cosa en una base de código heredada. Mi gerente está muy contento con esto. Él mismo me lo ha dicho. Al resto del equipo parece gustarle la idea de realizar pruebas y registros cerrados, pero no ha tomado ninguna medida para comenzar a hacer estas cosas. Creo que puede ser porque simplemente no saben cómo hacerlo, pero es posible que piensen que "no tienen tiempo". (Por cierto, la parte de no tener tiempo es totalmente falsa. La gerencia sabe que es una inversión inicial que paga dividendos y apoya completamente el esfuerzo).

Honestamente, se está volviendo un poco frustrante para mí escuchar tanto hablar, pero no ver ninguna acción de mis compañeros de equipo. Como el chico nuevo, ¿cómo puedo empujarlos a la acción sin alterar las plumas? No quiero ser ese tipo .

Esto no es un duplicado de la pregunta sugerida porque ese tipo estaba preguntando si/cómo debería impulsar sus ideas. Estas no son mis ideas (aunque estoy de acuerdo con ellas, obviamente). Mi pregunta gira en torno a cómo lograr que mis colegas actúen sobre sus palabras .

Puede parecer que les gusta la "idea de las pruebas y los registros cerrados" porque no quieren discutir al respecto.
¿Qué quieres decir con @MarkRogers?
Es posible que no estén de humor o no tengan la energía para cambiar la forma en que trabajan, por lo que solo dan a la idea la idea mientras continúan haciendo lo que ya estaban haciendo. Con la esperanza de que eventualmente alguien más lo resuelva o el problema desaparezca. Esquiva clásica.
No conozco a @MarkRogers. Puede que tengas razón, pero parecen realmente interesados ​​en mejorar las cosas. O, al menos, les interesa hablar sobre cómo mejorar las cosas. Mmm
Si están genuinamente interesados ​​pero no sucede nada, puede ser porque nadie se siente cómodo tomando la iniciativa para ponerlo en marcha. ¿Eres ese tipo? Si es así, elabore un plan y preséntelo. Ellos lo apoyarán y quizás estén agradecidos por su liderazgo. Si no estás dispuesto a tomar la iniciativa, entonces es un poco hipócrita criticarlos por no hacerlo, independientemente de cuánto tiempo haya durado la situación. Mira esto como una oportunidad, no como un problema.
Para cualquier persona interesada, después de la reunión de esta mañana, propuse agregar una columna "Revisar" a nuestro tablero kanban. Todos estuvieron de acuerdo en que era una buena idea, así que lo hicimos y les mostré a todos cómo comentar un conjunto de cambios. Veremos cómo va. Gracias por todos los buenos consejos a todos. Lamento no otorgar una marca de verificación, pero sentí que todas las respuestas fueron igualmente útiles.

Respuestas (3)

Honestamente, se está volviendo un poco frustrante para mí escuchar tanto hablar, pero no ver ninguna acción de mis compañeros de equipo. Como el chico nuevo, ¿cómo puedo empujarlos a la acción sin alterar las plumas? No quiero ser ese tipo.

Usar frases como "gran charla" y "empujarlos" puede convertirte en ese tipo , por lo que no querrás ir allí.

Considere preguntarle a su gerente si estaría bien que usted creara una presentación sobre algunas de las prácticas que considere importantes. Algunas empresas tienen "charlas de bolsa marrón" durante el almuerzo donde estos temas son comunes.

Si es aceptado, puede hablar sobre lo que propone, por qué lo considera importante (con suerte, no solo porque siente que es una "mejor práctica", sino más sobre por qué beneficiará al equipo/empresa en su contexto particular) y cómo todos ustedes pueden ir implementando estas ideas.

Trate de obtener la aceptación explícita del gerente con anticipación, luego use su poder de persuasión para convencer a otros de que se suban al tren. A veces, sugerir un proyecto piloto comienza bien; a menudo, comenzar poco a poco es la forma más sencilla de lograr mejoras.

Esa es la cosa. Conocen los beneficios, de lo contrario no se hablaría tanto de ello... Sin embargo, el proyecto piloto es una buena idea. Me gusta eso. Podría ser capaz de hacer que eso suceda.
Saber que algo sería una mejora y querer aprovecharlo y poder encontrar los recursos necesarios para adoptarlo, suelen ser cuestiones muy diferentes. En teoría, la práctica debería ser idéntica a la teoría; en la práctica, eso no siempre es posible y, cuando lo es, generalmente tiene que llegar allí de forma incremental.
Recibí un voto positivo aleatorio que me llamó la atención. Lo había olvidado todo hasta ahora. Solo quiero decir gracias. Cuando dejé esa empresa, la cobertura de pruebas estaba creciendo y estábamos lanzando para probar de 2 a 4 veces por semana.

Al resto del equipo parece gustarle la idea de realizar pruebas y registros cerrados, pero no ha tomado ninguna medida para comenzar a hacer estas cosas.

¿Saben realmente cómo hacer pruebas unitarias?

Si nunca ha hecho esto antes, puede que no sea sencillo comenzar a hacerlo. Especialmente si tiene años de experiencia sin realizar pruebas.

Parece que todo su equipo al menos está abierto a la idea de cambiar sus procesos. Me concentraría en asegurarme de que sepas por qué no están haciendo las cosas. Sospecho que es una resistencia general al cambio o falta de comprensión de cómo hacer las cosas.

Si es una falta de conocimiento, puede considerar maneras de ayudar con esto. Una buena manera podría ser pedirle ayuda a alguien y hacer algo de programación en pareja, cuando trabaje con un código que no entiende (tan completamente). Puede hablar sobre lo que está haciendo y ver si puede escribir pruebas con la otra persona allí, explicando lo que está haciendo.

Tenga en cuenta que ver una prueba escrita (revisión de código) y saber cómo abordar la escritura de una prueba no son necesariamente lo mismo.

Si es solo un problema de "nos gusta hablar de eso y sonar a la moda sin hacer nada", puede intentar sugerir o preguntar sobre cosas prácticas muy específicas (en lugar de simplemente lamentarse por la falta de revisión de código o pruebas unitarias). , también):

  • "Ojalá fuéramos más ágiles".
  • "Bueno, ¿quieren revisar el código de cada uno? Estoy libre esta tarde y tengo un compromiso que estoy haciendo"
Es posible que no lo sepan legítimamente . Un poco de programación en pareja podría ser un gran curso de acción. No estoy seguro de que haría eso para poner a prueba el código heredado, pero tal vez con un poco de código greenfield. Gracias. Consejo sólido.
Lo más probable es que la gente de @ThatGuy tampoco salga y diga eso. No es probable que le diga al chico nuevo: "Eh, nosotros, las personas más importantes, no sabemos cómo hacer algo que crees que es básico y que la gerencia quiere". El código heredado con el que no está familiarizado es perfecto para esto, puede decir algo como "Espero escribir algunas pruebas sobre el código heredado y usted está más familiarizado con esa base de código. ¿Me puede ayudar?" y de nuevo, simplemente hable sobre el proceso mientras lo hace. Por lo general, a las personas les gustan los halagos y pedir ayuda es una excelente manera de generar apoyo en el futuro.
Ese es un muy buen argumento. Punto a favor.

Para que las revisiones de código sean prácticas, necesita un sistema que las facilite. Por ejemplo, como lo hace GitHub con las solicitudes de extracción o como GitLab con las solicitudes de combinación. Escuché grandes cosas sobre Gerrit, pero no lo he usado. Obtenga uno de estos o similar instalado (incluso solo en su propia PC, al principio), de lo contrario, simplemente no será práctico.

Este es un ejemplo de presentación de revisiones de código a un colega que usa GitHub.

Implemente un cambio razonablemente interesante en una rama e intencionalmente deje algunos errores. Cree una solicitud de extracción y pídale a un compañero de equipo que la revise amablemente. Siéntese con él, muéstrele su error y cómo puede ingresar un comentario en la línea correspondiente. Guíelo a través del resto de sus cambios, si hace algún comentario, pídale que ingrese un comentario allí mismo. Después de revisar todos los cambios juntos, regrese a su escritorio, confirme y envíe las correcciones. Los comentarios anteriores desaparecerán de la solicitud de extracción, pídale que haga otra pasada en caso de que encuentre algo más. Repita hasta que no encuentre nada y se pueda aceptar la solicitud de extracción.

Muéstreles también a otros compañeros de equipo, siga asignándoles solicitudes de extracción y anímelos a que hagan lo mismo con usted. Esperemos que la práctica se ponga de moda.

El proceso es exactamente el mismo con GitLab (clon gratuito de GitHub), pero llaman solicitudes de extracción como solicitudes de combinación. No sé con Gerrit y otros, me imagino que existe una funcionalidad similar.

Implementamos esta idea en dos equipos hasta ahora, durante los últimos 3 años. Es la práctica más popular que implementamos. A los muchachos les encanta hacerlo, y ocasionalmente me envían solicitudes de combinación incluso después de que me mudé a otro equipo. En mis nuevos equipos estoy tratando de difundir la práctica precisamente de la manera que describí anteriormente.

En cuanto a las pruebas unitarias:

  • Obtenga un sistema de compilación continuo que ejecute pruebas unitarias como parte de la compilación.
  • Proponga una charla durante el almuerzo que demuestre ejemplos de pruebas unitarias buenas y pruebas unitarias malas. Pon el contenido que usaste en un repositorio público.
  • Escriba buenas pruebas unitarias y asigne solicitudes de fusión a un compañero de equipo que tenga más probabilidades de aceptar la idea.
  • Presionar para que todos implementen (al menos) una prueba de unidad por semana. Asegúrese de medir y realizar un seguimiento del progreso (uso una hoja de Excel simple).

En cuanto a las mejoras en la calidad del código:

  • Obtenga una herramienta de análisis estático integrada en el sistema de construcción continua. Por ejemplo SonarQube.
  • Implemente correcciones a los problemas planteados por la herramienta de análisis estático y asigne solicitudes de fusión a un compañero de equipo que tenga más probabilidades de aceptar la idea.
  • Proponga comprar libros que se sabe que son buenos recursos en su dominio, téngalos alrededor de su escritorio y anime a otros a tomarlos y pedirlos prestados en cualquier momento.
  • Presionar para que todos implementen (al menos) una corrección a los problemas planteados por la herramienta de análisis estático por semana. Asegúrese de medir y realizar un seguimiento del progreso (uso una hoja de Excel simple).

Observe el patrón común en los dos ejemplos anteriores:

  1. Obtenga una configuración de herramientas que lo ayudará a lograr sus objetivos de manera eficiente
  2. Use las revisiones de código como una forma de predicar con el ejemplo
  3. Obtenga materiales de apoyo adicionales alineados
  4. Presionar para implementar mejoras en pasos pequeños y manejables

Todas estas ideas son cambios incrementales tan pequeños y simples que son realmente fáciles de vender.

Personalice y use una variación adaptada a su entorno.

Gracias por esto. Estoy más convencido de que si esto va a pasar, voy a tener que enseñarlo. Esto definitivamente ayudará.
Como el chico nuevo, ¿cómo hago para que la gente actúe en toda su gran charla?
RespuestasAquíPolítica de privacidad1y, 0v