Proceso de DevOps: trabaja en lotes pequeños

Trabajar en lotes pequeños es un principio esencial en cualquier disciplina en la que los ciclos de comentarios sean importantes, o si quieres aprender de tus decisiones con rapidez. Además, te permite probar con rapidez hipótesis sobre si una mejora en particular puede tener el efecto que deseas y, si no, te permite corregir o revisar las suposiciones. Si bien este artículo se aplica a cualquier tipo de cambio que incluya la transformación organizacional y la mejora de los procesos, se centra sobre todo en la entrega de software.

Trabajar en lotes pequeños es una característica de una administración de productos moderada. Trabajar en lotes pequeños permite predecir el rendimiento del software y de la organización, además de que se cuenta con características como la visibilidad del trabajo en el flujo del valor, la experimentación en equipo y la visibilidad de los comentarios de los clientes.

Una de las razones por las que el trabajo se realiza en lotes grandes es el gran costo fijo de la transferencia de cambios. En los enfoques tradicionales por etapas para el desarrollo de software, las transferencias desde el desarrollo hasta la prueba o desde la prueba hasta las operaciones de TI constan de versiones completas: meses de trabajo de equipos compuestos por decenas o cientos de personas. Con este enfoque tradicional, la recopilación de comentarios sobre un cambio puede llevar semanas o meses.

Por el contrario, las prácticas de DevOps, que implican el uso de equipos multifuncionales y enfoques livianos, permiten que el software avance del desarrollo a la producción, a través de pruebas y operaciones, en cuestión de minutos. Sin embargo, este progreso rápido requiere que se trabaje con código en lotes pequeños.

Trabajar en lotes pequeños tiene los siguientes beneficios:

  • Reduce el tiempo que implica recibir comentarios sobre los cambios, lo que facilita la clasificación y la solución de problemas.
  • Aumenta la eficiencia y la motivación.
  • Evita que la organización caiga en la falacia del costo irrecuperable.

Puedes aplicar el enfoque de los lotes pequeños a nivel de la característica y del producto. A modo de ejemplo, un producto mínimo viable, o MVP, es un prototipo de un producto que cuenta con las características suficientes para permitir el aprendizaje validado sobre el producto y el respectivo modelo de negocio.

La entrega continua se basa en trabajar en lotes pequeños y se intenta obtener todos los cambios en el control de versión lo antes posible. Un objetivo de la entrega continua consiste en cambiar la economía del proceso de entrega de software a fin de que sea funcional para trabajar en lotes pequeños. Con este enfoque, se proporcionan comentarios completos a los equipos con rapidez para que puedan mejorar su trabajo.

Cómo trabajar en lotes pequeños

Cuando planifiques características nuevas, intenta dividirlas en unidades de trabajo que se puedan completar de forma independiente y en períodos cortos. Recomendamos que cada característica o lote de trabajo siga los conceptos ágiles del principio INVEST:

  • Independiente. Haz que los lotes de trabajo sean lo más independiente posible entre sí para que los equipos puedan trabajar sin respetar un orden y, luego, implementarlos y validarlos separados de otros lotes de trabajo.
  • Negociable. Los lotes de trabajo son iterables y se pueden renegociar a medida que se reciben los comentarios.
  • Valioso. Se pueden usar lotes de trabajo discretos que proporcionan valor a las partes interesadas.
  • Estimable. Existe información suficiente sobre los lotes de trabajo, por lo que puedes estimar su alcance con facilidad.
  • Pequeño. Durante un sprint, deberías poder completar lotes de trabajo en pequeños incrementos de tiempo, lo que puede significar unas horas o un par de días.
  • Verificable. Los lotes de trabajo se pueden probar, supervisar y verificar para asegurarse de que funcionen como los usuarios desean.

Cuando las características tienen el tamaño adecuado, puedes dividir su desarrollo en lotes aún más pequeños. Este proceso puede ser complejo, y desarrollarlo requiere experiencia. Lo ideal es que los desarrolladores comprueben varios cambios pequeños que se pueden actualizar en el tronco al menos una vez al día.

La clave es comenzar el desarrollo en la capa de la API o el servicio, no en la capa de la IU. De esta manera, puedes hacer adiciones a la API que al comienzo no estarán disponibles para los usuarios de la app y verificar esos cambios en el tronco. Puedes iniciar estos cambios en producción sin hacerlos visibles para los usuarios. Este enfoque, llamado lanzamiento oscuro, permite a los desarrolladores registrar el código de los lotes pequeños que se completaron, pero no de las características que aún no se terminaron. Luego, puedes ejecutar pruebas automatizadas para estos cambios a fin de comprobar que se comportan acorde a lo esperado. De esta manera, los equipos siguen trabajando con rapidez y se desarrollan a partir del tronco y no de las ramas de características de larga duración.

También puedes iniciar cambios en modo de lanzamiento oscuro mediante la activación o desactivación de características, que es una declaración condicional basada en parámetros de configuración. Por ejemplo, puedes hacer que los elementos de la IU sean visibles o invisibles, o puedes habilitar o inhabilitar la lógica de servicio. La configuración de activación o desactivación de características puede leerse en el tiempo de implementación o en el entorno de ejecución. Puedes usar estos parámetros de configuración para cambiar el comportamiento del código nuevo más abajo en la pila. También puedes usar una técnica similar conocida como rama por abstracción para realizar cambios a mayor escala en el sistema sin dejar de desarrollar y actualizar troncos, y sin usar ramas de características de larga duración.

En este enfoque, los lotes de trabajo no se completan hasta que se implementan en producción y el proceso de comentarios comienza a validar los cambios. Los comentarios provienen de muchas fuentes y en muchos formatos, incluidos los usuarios, la supervisión del sistema, el control de calidad y las pruebas automatizadas. Tu objetivo es optimizar la velocidad para reducir el tiempo del ciclo y poner los cambios al alcance de los usuarios. De esta manera, puedes validar la hipótesis lo más rápido posible.

Errores comunes cuando se trabaja en lotes pequeños

Cuando desglosas el trabajo en lotes pequeños, te puedes encontrar con los siguientes dos errores:

  • No dividir el trabajo en piezas tan pequeñas como se debe. Tu primera tarea es desglosar el trabajo de forma congruente. Se recomienda que confirmes el código sin tener en cuenta el estado de la característica y que el desarrollo de las características individuales no demore más que unos días. Cualquier lote de código que requiera más de una semana para completarse y verificarse es demasiado grande. Durante el proceso de desarrollo, es esencial que analices cómo dividir las ideas en incrementos que puedas desarrollar de manera iterativa.

  • Trabajar en lotes pequeños, pero, luego, reorganizarlos antes de enviarlos para que se realicen pruebas o actualizaciones. Reorganizar el trabajo de esta manera retrasa los comentarios sobre si los cambios tienen defectos y, antes que nada, sobre si los usuarios y la organización coinciden en que los cambios fueron acertados.

Formas de reducir el tamaño de los lotes de trabajo

Cuando divides el trabajo en lotes pequeños que pueden completarse en horas, por lo general, puedes probar y, luego, implementar esos lotes en producción en menos de una hora (PDF). La clave es dividir el trabajo en características pequeñas que permitan un desarrollo rápido, en lugar de desarrollar características complejas en ramas y actualizarlas con poca frecuencia.

Para mejorar el desarrollo de los lotes pequeños, verifica el entorno y confirma que se cumplan las siguientes condiciones:

  • El trabajo se divide de una manera que permite a los equipos realizar actualizaciones de producción con mayor frecuencia.
  • Los desarrolladores tienen experiencia en dividir el trabajo en cambios pequeños que se pueden completar en horas, en lugar de días.

Para convertirte en un experto en el desarrollo de lotes pequeños, esfuérzate por cumplir con cada una de estas condiciones en todos tus equipos de desarrollo. Esta práctica es una condición necesaria para la integración continua y el desarrollo basado en troncos.

Formas de medir el tamaño de los lotes de trabajo

Cuando comprendas la integración continua y la supervisión, podrás describir en términos generales las formas posibles de medir el desarrollo de lotes pequeños en los sistemas y el entorno de desarrollo.

  • Las características de la aplicación se dividen de una manera que admite actualizaciones frecuentes. ¿Con qué frecuencia se pueden realizar actualizaciones? ¿En qué difiere esta cadencia de actualización entre los equipos? ¿Los retrasos en la producción están relacionados con características más grandes?
  • Las características de la aplicación se dividen de una manera que permite a los desarrolladores completar el trabajo en una semana o menos. ¿Qué proporción de características puedes completar en una semana o menos? ¿Qué características no puedes completar en una semana o menos? ¿Puedes confirmar y actualizar los cambios antes de que se complete la característica?
  • Los MVP se definen y establecen como objetivos de los equipos. ¿El trabajo se divide en características que permiten el desarrollo rápido y los MVP, en lugar de procesos complejos y largos?

Las medidas dependen de los siguientes factores:

  • Se conocen los procesos de la organización.
  • Se establecen objetivos para reducir el desperdicio.
  • Se buscan maneras de reducir la complejidad en el proceso de desarrollo.

¿Qué sigue?