Soy un administrador de programas de desarrollo de software que ha experimentado muchos de los beneficios del desarrollo basado en pruebas y la integración continua. Pero algunos de los equipos de desarrollo con los que trabajo no siguen estas prácticas. No me corresponde a mí decirles cómo hacer su trabajo, pero ¿cómo puedo alentarlos a adoptar estas prácticas sin traspasar los límites de mi función?
Predicar con el ejemplo. No puede obligar a las personas a hacer algo en lo que no creen, especialmente en su función. Pero si trabajas de la manera que crees que es la correcta, y si muestras resultados discretamente, eventualmente deberías ganarte a la gente para que se ponga de tu lado. No obligues a nadie, simplemente trabaja de la manera que creas correcta, menciona tus resultados positivos y, si están interesados, muéstrales más.
Primero me di cuenta del poder de TDD cuando uno de mi equipo insistió en hacerlo para su propio trabajo. Pensé que estaba perdiendo el tiempo, pero confiaba en él lo suficiente como para dejarlo trabajar de la manera que mejor le pareciera. Entonces, un día, me mostró docenas de errores que había encontrado en nuestro software y que corrigió en silencio. Los había encontrado porque quería verificar el comportamiento del código con el que estaba trabajando, escribió pruebas para él y encontró agujeros. No convirtió a todo el equipo en ese momento, pero me convirtió a mí. Estoy seguro de que también lo hizo por otras personas... solo en silencio.
En una nota relacionada, vea este video de Dan North, y en particular la historia #3, The Coach. http://www.infoq.com/presentations/interactions-career
En mi experiencia, este es un proceso de años. Los desarrolladores que no practican "Quality Build In" en su proceso diario lo verán como un trabajo extra. Prefieren estar programando...
Las empresas de manufactura esbelta tendrán la calidad integrada en sus procesos tanto como sea posible. Al integrar la calidad en su proceso, evita reelaboraciones y desperdicios innecesarios. Esto significa que sus máquinas son capaces de detectar anomalías (jidoka) y sus accesorios tienen pruebas de errores para evitar errores de montaje (poka yoke).
Compromiso de gestión
Desde mi perspectiva, esta debe ser la visión de la gerencia, deben comunicar a estos equipos que esto es lo que se espera de ellos.
Tenga en cuenta que las pruebas automatizadas agregan un esfuerzo adicional a corto plazo, mientras que son realmente ágiles y eficientes a largo plazo. El tiempo de los desarrolladores se distribuirá en un 33 % de requisitos, un 33 % de programación y un 33 % de pruebas automatizadas. Esto ralentizará al equipo y podría ser un problema si la gerencia no está al tanto.
Soy un administrador de programas de desarrollo de software que ha experimentado muchos de los beneficios del desarrollo basado en pruebas y la integración continua. Pero algunos de los equipos de desarrollo con los que trabajo no siguen estas prácticas. No me corresponde a mí decirles cómo hacer su trabajo, pero ¿cómo puedo alentarlos a adoptar estas prácticas sin traspasar los límites de mi función?
Si bien es posible que no esté en condiciones de dictar buenas prácticas de trabajo, parece probable que esté en condiciones de impulsar un enfoque orientado a los resultados. En términos generales, TDD y CI son prácticas que están diseñadas para reducir las tasas de defectos, y ese debe ser su enfoque.
Como ejemplo, puede dibujar un gráfico circular que muestre cuánto tiempo se consume corrigiendo errores en lugar de realizar un desarrollo totalmente nuevo en nuevas funciones. Al hacer que las tasas de defectos sean un costo visible para los desarrolladores (quienes generalmente preferirán trabajar en nuevas funciones a corregir errores), crea un incentivo para que los desarrolladores inspeccionen y adapten su flujo de trabajo.
No se trata de "responsabilizar a la gente". Más bien, el objetivo es crear un vínculo causal que ayude a los desarrolladores a ver las consecuencias naturales de sus prácticas de desarrollo actuales. Esto puede ser todo lo que se necesita para invitar al cambio.
Tenga en cuenta que, al final del día, probablemente no debería importarle si están escribiendo software usando TDD y CI, o escribiendo código en tablillas de piedra usando escritura cuneiforme. Lo que realmente le importa es la calidad del software y la eficiencia de la entrega, y definitivamente debe mantener objetivos razonables para ambas cosas. Luego, depende del equipo de desarrollo si quieren hacer las cosas de la manera más fácil o de la manera más difícil; puede brindar orientación si la aceptan, pero debe dejar que algunas personas aprendan cometiendo sus propios errores.
Concéntrese en resultados tangibles (p. ej., índices de defectos o plazos de entrega de funciones). Establezca objetivos razonables para sus proyectos. Desafíe a sus equipos a mejorar sus procesos o cadenas de herramientas cuando no cumplan con las expectativas razonables. No puede proteger a las personas de sí mismas, pero puede alentar el crecimiento profesional, especialmente si proporciona el tiempo, el dinero y el equipo necesarios para implementar un cambio de proceso real.
Niels van Reijmersdal
Todd A. Jacobs
mal