La retroalimentación es la información que recibimos del mundo como respuesta a la realización de algo. Sin retroalimentación, no hay forma de saber si estamos logrando nuestros objetivos.
En el desarrollo de programas informáticos, hay muchas oportunidades de utilizar la retroalimentación para mejorar. Tal vez la más obvia sea la de obtener retroalimentación de nuestros usuarios, pero hay muchas otras que se presentan antes de que podamos tener nuestro software frente a los clientes.
Nuestros diseños obtienen retroalimentación de las limitaciones que encontramos al escribir el código.Obtenemos retroalimentación al fusionar nuestro código cuando hay conflictos (o la falta de ellos).Los resultados de las pruebas nos dan retroalimentación, al igual que las revisiones del código.Luego cuando nos desplegamos a la producción, obtenemos retroalimentación en forma de uso del cliente e informes de errores.
Cada uno de estos bucles de retroalimentación nos enseña algo que podemos usar para adaptarnos y mejorar.
Retroalimentación más rápida
Por desgracia, siempre hay un retraso entre el momento en que se hace algo y el momento en que se recibe la respuesta. Cuanto más largo sea el retraso, más lentamente podremos reaccionar. Pero lo peor es que los grandes retrasos también significan que pasamos más tiempo con malas suposiciones. Aquí hay algunos ejemplos:
- mucho trabajo de diseño se dedica a una idea que es técnicamente inviable
- los cambios se hacen en una rama del código sólo para encontrar que la rama maestra cambió significativamente, haciendo que ese trabajo sea obsoleto
- un desarrollador hace algo que no sabía que no debía, entonces tiene que reescribir el código después de que el problema se encuentra en la revisión del código
- se envió un micrófono a producción que no se encuentra durante meses, pero luego resulta que algunos clientes confían en el comportamiento no deseado
- la nueva característica que hemos creado no es utilizada por los clientes
Para evitar estos problemas debemos apretar nuestros bucles de retroalimentación para ser lo más rápidos posible.
Algunos bucles de retroalimentación pueden ser ajustados a través de medios técnicos.Podemos usar computadoras más nuevas para compilar el código más rápidamente.Podemos hacer nuestras pruebas unitarias más rápidas.Podemos configurar servidores de integración continua para ejecutar automáticamente nuestras pruebas.Estos son importantes, pero sólo nos llevan hasta cierto punto.La mayor parte del retraso en los proyectos de desarrollo de software se debe a la forma en que los humanos eligen trabajar.
Cambio de procesos y prácticas
Puede ser muy difícil modificar el funcionamiento de un equipo. Cuantas más personas se vean afectadas, más difícil será conseguir cambios. Pero estos cambios también pueden tener enormes beneficios. Veamos algunas formas de estrechar los lazos de retroalimentación cambiando la forma en que trabajamos.
Equipos multifuncionales
Cuando los equipos se dividen por especialidades, el trabajo en cualquier proyecto debe competir con otras prioridades al cruzarse con los equipos. Esto retrasa la retroalimentación. Por ejemplo, si un desarrollador terminó de codificar una característica, puede que tenga que esperar a que un probador esté disponible para verificarla. Y luego hay otra espera para que el equipo de operaciones se despliegue a la producción. Estos retrasos se ven agravados por la rotación de cambio de contexto – es raro que cada equipo ya esté al tanto de los detalles de cada proyecto.
Los equipos multifuncionales no tienen que ocuparse de la comunicación y la priorización de los gastos generales del trabajo entre varios equipos. La retroalimentación llega más rápidamente porque los miembros del equipo trabajan regularmente entre sí. Hay menos rotación y las personas cuya retroalimentación se necesita participan mucho antes en el proceso.
Esta es una de las razones por las que vemos los cambios culturales de Agile y DevOps hacia el trabajo conjunto de personas de diferentes disciplinas. (De hecho, mejorar la retroalimentación es la Segunda Vía de DevOps.)
Desarrollo dirigido por pruebas
¿Alguna vez has trabajado en un código por un tiempo sin ejecutarlo, y luego cuando finalmente lo ejecutas te sorprendes si funciona la primera vez?
Solía trabajar así. Sólo ejecutaba mi código cuando ejecutaba toda la aplicación, y hacerlo era lento. Así que escribía mucho código, y luego me ocupaba de los errores de sintaxis, bugs y otros problemas más tarde.
Una de las grandes ventajas del desarrollo dirigido por pruebas (TDD) es que se ejecuta el código a menudo. En lugar de ejecutar la aplicación completa, se ejecutan trozos más pequeños en suites de pruebas diseñadas para ser rápidas. La ejecución constante de las pruebas proporciona información sobre el estado del código. No sólo se aprende si se compila y ejecuta correctamente, sino que también se sabe cuánto tiempo ha pasado desde la última vez que funcionó. Cuando se produce un fallo inesperado, se puede reducir el problema a los últimos cambios.
Para mí, esta rápida retroalimentación y los beneficios de diseño de TDD son las verdaderas razones de la práctica. Tener un conjunto de pruebas completo con alta cobertura de códigos es sólo un agradable efecto secundario.
Integración continua
La integración continua (IC) se trata de la retroalimentación que recibes cuando fusionas código de diferentes desarrolladores para ver cómo funciona todo junto. Se hace todo el tiempo (¡continuamente!) porque posponerlo hace que el bucle de retroalimentación sea largo y las fusiones se vuelven mucho más dolorosas.
Aunque se puede practicar la IC sin un servidor (practicando el desarrollo basado en troncos, por ejemplo), es muy beneficioso configurar un servidor de IC para automatizar el trabajo de construcción y prueba de la base de código integrada, lo que hace que la retroalimentación sea más rápida y fiable.
Pair & Programación Mob
La codificación colaborativa es una forma poderosa de estrechar los lazos de retroalimentación. Al hacer que las personas trabajen juntas, la retroalimentación que se dan mutuamente es inmediata y fácil de aplicar. La programación en parejas puede mejorar significativamente las revisiones de código, y la programación en masa puede eliminar ese paso por completo!
Al tener menos trabajo en curso, los conflictos de fusión son menos frecuentes y menos dolorosos. Trabajé en un equipo de programación de la mafia en el que los conflictos de fusión sólo aparecían un par de veces al año (e incluso entonces era normalmente un caso especial).
Pero quizás lo más importante es saber que estás trabajando en lo correcto. Cuando trabajas solo, puedes malinterpretar la tarea. Trabajar juntos suele sacar a la luz los malentendidos o desacuerdos para poder abordarlos.
Tuberías de despliegue
La automatización de los despliegues los hace rápidos y menos propensos a errores.Luego puedes llevar tu código y características a entornos de prueba y producción donde puedes obtener diferentes tipos de retroalimentación.Los despliegues con botones son fantásticos.Algunos equipos llegan a hacer despliegues continuos.
Desacoplar sus despliegues de sus lanzamientos significa que puede desplegar más a menudo, y a su vez obtener retroalimentación más a menudo. Los conmutadores de funciones son una gran manera de probar cosas en producción en un pequeño grupo de usuarios, y luego desplegarlo a más usuarios gradualmente en base a los resultados.
Tamaños de lotes pequeños
Mi última sugerencia para estrechar los lazos de retroalimentación es trabajar en pequeños incrementos. Haga sus tareas o historias de usuarios pequeñas; idealmente en rebanadas verticales donde cada historia entregue algún valor. (Evite las rebanadas horizontales como «crear el esquema de la base de datos» porque esas no entregan valor por sí mismas.) Luego ponga esas pequeñas rebanadas en producción.
Cuanto más tiempo pasa su equipo trabajando en una idea sin enviarla a producción, más largo se vuelve su ciclo de retroalimentación. Sin la retroalimentación de los clientes, sólo está adivinando si quieren las nuevas características y es más probable que caiga en argumentos de costos hundidos. Desafortunadamente, muchos equipos hacen que su «producto viable mínimo» sea demasiado grande y no enviarán nada hasta que todo esté completo.
Las entrevistas con los clientes y otras técnicas son excelentes para examinar las ideas, pero también son susceptibles de problemas como el sesgo de selección y los pequeños tamaños de las muestras. En lugar de esperar a que se termine de elaborar un conjunto completo de características, considere la posibilidad de entregar antes las piezas de funcionalidad a los usuarios y utilice sus comentarios para orientar su trabajo.
Otro beneficio de los lotes de tamaño pequeño es que el trabajo se hace más rápido. Hay menos código que escribir, por lo que es más fácil fusionar y revisar el código. Hay menos pruebas que escribir y hacer pasar. Cada paso es más fácil y hay menos ruido en la retroalimentación.
Apriete sus bucles de retroalimentación
Piensa de dónde obtienes la información. ¿Qué cambios podrías hacer para obtener la información más valiosa más a menudo? ¿Qué valor tendría, tanto económicamente como para la moral del equipo?
Obtener feedback es importante. Cuanto más rápido lo obtengas, más rápidamente podrás adaptarte al cambio. También evitas perder tiempo y esfuerzo en cosas que no necesitas hacer. Las formas más efectivas que he encontrado para acelerar el feedback son mejorar las partes humanas del proceso de desarrollo de software.
Categorías: prácticasTags: testing, directed discovery