Optimiza el flujo de trabajo sin detener al equipo
Una estrategia de aseguramiento de la calidad mal diseñada entorpecerá el flujo de trabajo y generará retrasos. Veamos algunas maneras de optimizar el flujo del equipo, asegurando una alta calidad.
En esta serie de textos, te he hablado de la importancia de la calidad en el desarrollo de software y que este es el camino para acelerar las entregas, pues esto garantiza que no habrá fallas, ni desperdicio en tiempo de arreglo. Con ello, el equipo y la organización tendrá posibilidad de enfocarse en desarrollar más software.
Sin embargo, una estrategia de aseguramiento de la calidad mal diseñada entorpecerá el flujo de trabajo y generará retrasos. En el paso de los años, he escuchado a algunos desarrolladores quejarse sobre las actividades de calidad en su trabajo, pues perciben cosas como las siguientes:
Detienen el avance del código, porque estará algunos días en revisión.
Los interrumpen constantemente para “asegurar la calidad del trabajo de los otros”.
Muchas actividades de revisión son omitidas, con el fin de marcarlas como cumplidas. Todos lo saben, pero no hacen nada para cambiarlo y el resultado se nota al final.
La gente no está capacitada para hacer revisiones de alta calidad, por lo que se invierte tiempo que no detiene los defectos.
El trabajo de revisión es 99% manual.
Es cierto que colocar varios puntos de revisión van a detener el progreso del código y el software hacia la entrega. Ese es justamente el problema: colocarlos como etapas a lo largo de un flujo lineal.
Veamos algunas maneras de optimizar el flujo del equipo, asegurando una alta calidad en el código y los artefactos de software.
No tienes que revisar manualmente todas las Pull Request
Los equipos que trabajan con un repositorio de código, como Git, y trabajo individual (cada desarrollador hace su parte individualmente), establecen políticas de trabajo en el repo basadas en un máster y varias ramas (una o más para cada dev). Si el dev quiere enviar su código a la rama principal, el sistema de control de versiones solo lo permitirá cuando se apruebe una “pull request”, y solo algunos podrán hacerlo.
La Pull Request es usada, entonces, como un punto de verificación de la calidad, para garantizar que el código cumple con los estándares, la lógica interna es buena, el código está completo y la estructura permitirá seguir dándole mantenimiento.
Esto es perfecto, pero no debe hacerse para todo el código. Te doy mis razones:
Muy pocas personas en el equipo podrán hacer la revisión, generando cuellos de botella.
Realizar revisiones de estilo distrae a los revisores, que omitirán errores más graves si el código tiene muchos problemas de estándares de código.
Los devs no estarán enviando código constantemente a la rama principal, porque consideran que la Pull Request debe valer la pena, así que acumulan tanto código como es posible para enviarlo. Esto retrasa arreglos pequeños o soluciones rápidas, que bien podrían entregarse ya, y aguardan hasta que hay suficiente código para enviar.
Las revisiones son asíncronas y el flujo es de “ida y vuelta”: los errores son enviados de regreso al desarrollador, quien los arreglará y enviará a revisión otra vez; el ciclo se alarga en el calendario.
La recomendación principal es que la revisión sobre las PR debe definirse solamente para algunas partes del código, y esto se acuerda durante la planificación. Es más, podríamos prescindir completamente de la revisión en las PR si hacemos lo siguiente:
Añade herramientas de Análisis Estático del código, que detectan automáticamente los problemas de estándares, estructura del código, alta complejidad ciclomática y code coverage de las pruebas. Muchos IDE ya las incluyen (los plugin de “lint” para analizar la sintaxis son un ejemplo) y varios los puedes programar para indicarles la sintaxis que quieres, los estándares de nombrado que deben seguir, etcétera.
Usa métodos de desarrollo como TDD, donde las pruebas guían el desarrollo y estas se van aprobando poco a poco. Este será el indicador para dejar pasar o no un cambio a máster, pues también puedes automatizarlo y el estado verde/rojo determina si el código se integra a la rama o se retorna para arreglos.
Establece una cultura de la Revisión Personal Sistemática. Los desarrolladores deben aprender a revisar su propio trabajo minuciosamente. Al acabar de escribir el código, el dev debe revisarlo con el apoyo de sus datos históricos, un checklist de apoyo y otras herramientas para asegurar que el código será enviado sin errores.
No desarrollar solo. Esto te lo describo detalladamente a continuación.
Desarrolla en grupo
Muchos líderes y gestores creen que la manera más rápida de terminar un trabajo es asignar tareas individualmente. Si divides el trabajo en partes, cada desarrollador recibe un paquete de tareas y trabajan en paralelo, tendrás más resultados en el mismo tiempo. Esto genera el problema que describí antes: asegurar la calidad será una fase que interrumpe el flujo, en lugar de favorecerlo.
El software es un trabajo complejo, que resuelve problemas complejos y depende mucho de la interacción entre personas. La recomendación que hago, que muchos managers rechazan, es que hagan el desarrollo juntos.
En lugar de dividir las tareas, hacer que varias personas juntas trabajen en el mismo código.
Prácticas como Pair Programming y Mob Programming tienen este enfoque y aportan varios beneficios:
Encuentran mejores soluciones, porque varias personas están enfocadas en el mismo problema y aportan sus ideas desde su perspectiva.
Involucran a grupos diversos, no es trabajo exclusivo de desarrolladores, sino que están participando los PO, testers y otros stakeholders.
El desarrollo, revisión y aseguramiento de la calidad (incluso, testing), está ocurriendo al mismo tiempo. No hay flujo lineal asíncrono y los problemas se arreglan en un período calendario corto.
Es ideal para emparejar las habilidades del grupo, pues todos aprenden y se comprenden mejor.
Algunas actividades aún se harán por separado, claro está, porque el tamaño de las mismas no favorecerá el trabajo en grupo, pero para el resto será una muy buena estrategia.
Conclusiones
Tú conoces mi postura: La calidad no es negociable. El aseguramiento de esta debe hacerse a lo largo de todo el proceso de desarrollo y todos deben involucrarse. Sin embargo, también estoy consciente de que las actividades pueden volverse un problema y una frustración para el equipo.
Por esa razón hice estas recomendaciones. Hay que favorecer las actitudes de que mantener altos estándares de calidad es muy importante y que debemos encontrar la manera de alcanzarlos, pero sin entorpecer el flujo del equipo.
¡Hasta la próxima!
¡Coméntame con un emoji en este artículo y te regalo mi Guía para Escribir User Stories!
¿Quieres implementar estas mejoras, pero no sabes cómo? Te presento dos alternativas:
Una consulta profesional de 1 hora, para discutir problemas individuales y encontrar respuestas.
¡Únete al grupo de facebook para compartir ideas con otros profesionales de Élite!
🤓