Como mejorar la velocidad y la calidad de las entregas de desarrollo

Gracias a Ivan Reinoso por la elaboración y "préstamo" del artículo para su publicación en el blog de QA Lovers. 

Iván, aparte de un muy buen amigo, es FrontEnd Chapter Lead en Plain Concepts y tiene una carrera que no ha hecho más que elevarse, gracias a su buen hacer y su excelente trabajo en cualquier proyecto en los que han tenido el placer de contar con él.

Desde aquí, podemos decir que es un gran honor el poder publicar estas líneas escritas de su puño y letra y que esperemos que sean las primeras de muchas.

El otro día terminé de leer The Phoenix Project, el que para muchos es la biblia de la corriente DevOps. Como con cada libro o documentación que leo, me gusta después dejar por escrito un pequeño resumen para terminar de asimilar las ideas y conocimientos adquiridos y así evitar olvidarlos.

Así que gracias a mi mala memoria, os voy a hacer un poco de SPAM acerca de este libro, más concretamente sobre el principio que intenta aplicar a lo largo de todas sus páginas para resolver los problemas de la empresa ficticia “Parts Unlimited”: Las Tres Vías (The Three Ways).

En este post vamos a empezar por la primera de ellas, la cual define una serie de recomendaciones que podemos llevar a cabo para aumentar la velocidad y la calidad de la entrega de valor al cliente desde nuestro departamento de desarrollo hasta el de operaciones.

Hacer nuestro trabajo visible

Para poder mejorar nuestro proceso de desarrollo, lo primero que tenemos que saber es cual es el trabajo que realmente estamos haciendo, que nos queda pendiente o que hemos finalizado ya. Para ello, podríamos utilizar una pizarra Kanban:

Donde se representa el flujo de entrega de valor al cliente (de izquierda a derecha), y podemos identificar de un vistazo rápido en qué estado o fase del flujo (1,2,3) se encuentra cada una de las tareas (F,H,I,G,D,E,A,C). Esto nos ayuda también a priorizar las tareas cuando tenemos un gran número de ellas y detectar tareas encoladas o bloqueadas en cierto estado o departamento.

También recalcar, que debemos añadir cualquier tarea o tiempo invertido en forma de tarjeta dentro de nuestra pizarra Kanban. Con esto me refiero a que reuniones, peticiones, conversaciones telefónicas, etc también deben verse reflejadas, puesto que se va a invertir tiempo en ellas y mermará nuestra capacidad.

Limitar el trabajo en curso

Otro concepto que se introduce, es el de WIP (Work In Progress). Esto no es ni más ni menos que las tareas que están en curso actualmente. Estamos acostumbrados a tener muchas tareas asignadas e ir saltando de una en otra a medida que encontramos algún bloqueo o impedimento. Está más que demostrado que saltar entre tareas requiere tiempo y por tanto tiene un coste económico, puesto que se tarda en recuperar el contexto necesario para retomar cada una de ellas.

Lo que se sugiere para paliar este problema, es limitar la cantidad de WIP. Si volvemos a nuestra pizarra Kanban, podríamos limitar la cantidad de tarjetas en un determinado estado/columna o departamento. Por ejemplo podríamos limitar el número de tareas en Testing a 3. Si el departamento de QA está trabajando en 3 tareas y llegan más desde el departamento de desarrollo, éstas se quedarían en el departamento de desarrollo hasta que QA acabe alguna de ellas. Con esto detectamos cuellos de botella y problemas en el proceso para tomar las medidas necesarias para solucionarlos.

Para el caso anterior, veríamos que el departamento de QA está siendo un cuello de botella y que el departamento de desarrollo estaría “bloqueado”, ya que recordemos que hemos limitado el WIP, por lo que no podemos empezar nuevas tareas. Lo que se sugiere en este caso, en vez de empezar otras tareas para no estar “parado”, es ayudar a solucionar el cuello de botella de QA. Posiblemente podrían mejorar y agilizar su proceso de testing añadiendo algún tipo de automatización o tecnología, como el uso de contenedores o generación de bases de datos con los datos de prueba necesarios.

Reducir el tamaño de cada bloque de trabajo



Este gráfico está sacado de la web de Intel.

Lo que se propone es: en vez de trabajar sobre tareas mas grandes y entregarlas al cliente y al resto de departamentos una vez finalizadas, conviene dividir esas tareas o bloques de trabajo en otros más pequeños. De este modo, estos bloques de trabajo irán llegando a los distintos departamentos (y al cliente finalmente) mucho antes, con lo que podremos identificar errores en el proceso mucho antes gracias al feedback.

Imaginaros que estamos trabajando en una tarea muy grande (de meses incluso) y cuando finalmente la terminamos y pasamos al siguiente “step”, detectamos un error que nos hace corregir y repetir nuevamente todo el trabajo. Es mucho mejor detectarlo antes en unidades de trabajo más pequeñas, donde la cantidad de trabajo a corregir es mucho menor y podemos aplicar la corrección al resto de trabajo pendiente por hacer.

En el caso de un proyecto de desarrollo, podemos ver cada commit de cada desarrollador como un bloque de trabajo, que con una integración y despliegue continuo (CI/CD) se va entregando y desplegando a los diferentes entornos. Mucho cuidado con el trabajo que vamos entregando, pues muchas veces varias tareas tienen dependencias entre sí, por lo que tenemos que detectarlas y entregarlas conjuntamente.

Reducir el número de traspasos

En cualquier proyecto de software, dentro del proceso de desarrollo, las tareas y el trabajo va pasando entre personas y diferentes equipos o departamentos. Esto es lo que conocemos como traspasos. Cada vez que hay un traspaso, se incurre en un gasto de tiempo adicional: el nuevo equipo o la nueva persona tiene que obtener el contexto de la tarea, analizarla, etc. Además, cuanto más traspasos hay, más se pierde el contexto original del trabajo, lo que puede acabar siendo “el teléfono escacharrado”.

Por ello, se recomienda reducir este número de traspasos, por ejemplo automatizando alguno de los procesos para conseguir eliminar las dependencias de unos equipos o personas con otros y que sean capaces de liberar valor al cliente por sí solos.

Identificar y elevar continuamente nuestras restricciones

Debemos estar continuamente identificando y solucionando las restricciones, deficiencias o “stoppers” que nos impiden entregar valor al cliente de la forma más rápida posible. Por mucho que en una de las fases del flujo se esté trabajando de forma rápida y eficiente, si hay una restricción (constraint) después de esta fase, generará un cuello de botella. Y al contrario, si se encuentra antes de esta fase, provocará que los recursos de ésta se encuentren bloqueados sin trabajo que ejecutar hasta que el cuello de botella que provoca la restricción se solucione.

Recalco la palabra “continuamente”, puesto que deberemos identificar y resolver las restricciones de forma cíclica, es decir, una vez solucionada una restricción, intentaré identificar y solucionar la siguiente, hasta que la única restricción existente sea la calidad de la definición de requisitos por parte de negocio o la capacidad disponible en el equipo de desarrollo.

Algunos ejemplos muy comunes de restricciones que se encuentran en cualquier proyecto de software son la creación de entornos, el despliegue del código o el testing. Estas 3 restricciones suelen ser costosas en términos de tiempo y podremos optimizarlas/solucionarlas por ejemplo mediante automatización.

Eliminar “basura” en el flujo de entrega de valor

Por último, como parte de esta primera vía, se nos aconseja eliminar la “basura”, o mejor dicho, todo aquel trabajo adicional que se realiza en el flujo de un proceso de desarrollo y que no aporta valor al cliente.

Se nos ponen algunos ejemplos de esta “basura”:

- Trabajo parcialmente terminado.

- Trabajo adicional que se ha hecho y no es necesario, como por ejemplo, generación de documentación que nunca se utilizará.

- Desarrollo de características adicionales en el producto y que no ha pedido el cliente.

- Cambio de tareas para un mismo recurso, lo que provoca que la persona pierda tiempo al cambiar de contexto entre una y otra.

- Tiempos de espera entre una fase y otra del flujo de desarrollo.

- Defectos como documentación incompleta.

- Trabajo manual que es más susceptible a que se pueda cometer algún fallo en su ejecución, se debe automatizar todo lo que sea posible.

- Heroicidades o actos irracionales, como trabajo o despliegues a altas horas de la noche para llegar a un compromiso, aunque la calidad de lo entregado no sea la mínima aceptable y que por consiguiente generará cientos de bugs nuevos.

Y hasta aquí mi pequeño resumen de este gran libro, ¡espero que os sea útil!