Parece un caso abierto y cerrado.
Los bloqueos de código son una reliquia. Un remanente de los días en que las metodologías rígidas en cascada ofrecían la única opción para el desarrollo y lanzamiento de productos. Todo el concepto de detener la producción y retrasar la publicación, solo para probar errores y otros problemas funcionales, no tiene lugar en la gestión de productos moderna y ágil.
Al menos esa parece ser la opinión de consenso entre muchos gurús ágiles.
Pero, ¿se sostiene? Una vez que rasque la superficie de los argumentos más comunes contra la incorporación de bloqueos de código en la gestión ágil de productos, ¿seguirán pareciendo arcaicos?
En esta pieza, exploraremos los tres argumentos principales contra la incorporación de bloqueos de código en su gestión de productos Ágil, y analizaremos dónde se desmoronan esos argumentos, todo para ayudarlo a tomar una mejor decisión sobre si debe incorporar bloqueos de código en su gestión de productos Ágil.
- Argumento 1: Las congelaciones de código son irrelevantes e innecesarias
- Argumento 2: Los bloqueos de código Rompen un Principio Ágil Básico
- Argumento 3: Los bloqueos de código Conducen a Versiones Más Lentas y de menor Calidad
- Haciendo el Caso de los Bloqueos de Código: ¿Una Batalla Perdida?
- El problema Con el Argumento 1: Las pruebas automatizadas No son Exhaustivas
- El problema Con el Argumento 2: «Reducir», No «Eliminar»
- El Problema Con El Argumento 3: Repensar la velocidad y la calidad
- ¿Debería Utilizar Bloqueos de Código en Su Gestión Ágil de Productos?
Argumento 1: Las congelaciones de código son irrelevantes e innecesarias
Este argumento es bastante simple y concreto: las metodologías y herramientas ágiles modernas han eliminado la necesidad de una ventana de pruebas y control de calidad dedicada.
Las metodologías ágiles, como las revisiones de código de pares, la programación por pares y la supervisión constante del estado del sistema, le brindan una visibilidad mucho mayor del rendimiento de una aplicación o función mientras se desarrolla. Los errores y los problemas son más fáciles, y es más probable que se detecten durante el propio desarrollo, y se resuelvan antes de cualquier actividad de pruebas y control de calidad dedicada.
Las nuevas herramientas también han automatizado muchas pruebas. Evalúan constantemente el código para asegurarse de que esté limpio y listo para la producción en todo momento. Los problemas se identifican en tiempo real y se envían alertas de inmediato para resolverlos lo antes posible. El número de pruebas automatizadas ya es amplio y sigue creciendo, reduciendo drásticamente el volumen de pruebas manuales que se deben realizar.
El resultado de estas nuevas metodologías y herramientas ágiles es fácil de ver. La mayoría de las actividades principales de pruebas y control de calidad realizadas durante una congelación de código se realizan durante el desarrollo o mediante software. En Agile, el software y las funciones ahora salen del desarrollo con un nivel de confianza mucho más alto de lo que solían, lo que hace que un bloqueo de código dedicado sea cada vez más difícil de justificar.
Argumento 2: Los bloqueos de código Rompen un Principio Ágil Básico
Este segundo argumento es un poco de nivel superior. Básicamente, argumenta que las congelaciones de código no tienen un hogar en la metodología ágil porque rompen uno de los principios básicos de la metodología ágil, lo que reduce el tiempo entre el desarrollo y la publicación.
Cuanto más refinado sea su enfoque de la metodología ágil, más intentará reducir esta ventana de tiempo. Los enfoques actuales más refinados de la metodología Ágil son la Integración Continua y el Desarrollo Continuo (CICD), y su objetivo es dividir el desarrollo en pequeños cambios incrementales para «publicar» los cambios en el código lo más rápido posible. En la aplicación más pura de CICD, el desarrollo y la liberación apenas existen como fases distintas: el nuevo código se integra en la aplicación casi tan pronto como se completa.
Por el contrario, debe mantener distintas fases de desarrollo y lanzamiento si va a implementar bloqueos de código. Después de todo, ahí es donde vive la congelación de código, entre esas dos fases distintas. En lugar de intentar minimizar o eliminar esa ventana de tiempo entre el desarrollo y el lanzamiento como la mayoría de las metodologías ágiles, los bloqueos de código lo obligan a formalizar esta ventana hasta el punto en que necesita construir sus programas de desarrollo y lanzamiento alrededor de ella.
Si los bloqueos de código no se alinean con los principios Ágiles básicos, es difícil demostrar que aún pertenecen a la metodología.
Argumento 3: Los bloqueos de código Conducen a Versiones Más Lentas y de menor Calidad
Este argumento final es grande e incluye algunos ángulos diferentes.
Para empezar, argumenta que los bloqueos de código agregan mucha complejidad y partes móviles adicionales a su hoja de ruta, y naturalmente aumentan las posibilidades de que algo salga mal y se deshaga de su línea de tiempo. Incluso si nada sale mal, el trabajo involucrado en los bloqueos de código consume mucho tiempo e impredecible (ya que no sabe qué errores encontrará o cuánto tiempo tardará en corregirlos), que simplemente agregando bloqueos de código a su hoja de ruta creará ciclos de desarrollo y liberación más lentos.
A continuación, argumenta que las congelaciones de código reducirán la productividad de su equipo de desarrollo. Aunque Ágil en general, y CICD específicamente, mantiene a sus desarrolladores trabajando constantemente en una cadena ininterrumpida de productividad, los bloqueos de código obligan a sus desarrolladores a dejar de trabajar a intervalos predefinidos. Al hacer esto, romperá su ritmo y los obligará a tratar de evitar sus políticas de congelación de código, en lugar de encontrar y mantener cualquier flujo que los haga más productivos.
Finalmente, argumenta que la creación de ventanas dedicadas donde deje de recibir requisitos comerciales limitará las características y funcionalidades de sus versiones a lo que pueda completarse antes de la congelación, lo que conducirá a software y aplicaciones de menor calidad y menos integrales.
Haciendo el Caso de los Bloqueos de Código: ¿Una Batalla Perdida?
En este punto, se ve bastante sombrío para cualquiera que aún quiera incluir bloqueos de código en la metodología Ágil. Los detractores de esta práctica hacen algunos argumentos muy convincentes y un caso sólido general de que, desde el desarrollo de la metodología ágil moderna, las congelaciones de código se han convertido en:
- Obsoleto e irrelevante
- Desalineado con las prácticas de desarrollo modernas
- Una barrera para las versiones rápidas y de alta calidad
Pero aunque estos argumentos son convincentes y contienen mucha información precisa, no son a prueba de balas. Y hay defectos fundamentales dentro de cada uno que deben discutirse antes de cerrar el libro sobre las congelaciones de código como un elemento útil de la gestión ágil de productos.
El problema Con el Argumento 1: Las pruebas automatizadas No son Exhaustivas
El control de calidad automatizado y las prácticas de desarrollo Ágiles han aumentado la calidad del código a medida que se produce, eso es un hecho. Pero solo porque una pieza de código haya pasado las pruebas unitarias, eso no significa que esté lista para producción. Incluso los enfoques CICD más refinados no siempre incluyen pasos críticos, como pruebas de regresión, que aseguran que un fragmento de código esté libre de defectos. Cuando se trata de eso, hay algunas cosas que no puedes probar y resolver mientras un fragmento de código está en producción.
Si elige utilizar bloqueos de código, no renunciará a los beneficios del control de calidad automatizado y las prácticas recomendadas ágiles. Usted y su equipo simplemente detectarán los problemas más pequeños y triviales de su código durante la producción, despejando las cubiertas para centrarse en detectar problemas más grandes y de mayor impacto durante su congelación, como la estabilidad general y la confiabilidad de su nuevo software o función.
El problema Con el Argumento 2: «Reducir», No «Eliminar»
Agile está diseñado para reducir el tiempo entre el desarrollo y el lanzamiento, eso también es un hecho. Pero hay una gran diferencia entre tratar de reducir esta ventana y tratar de eliminarla por completo. Hacerlo sería casi imposible, especialmente para proyectos más grandes.
La congelación de código puede ser muy corta en CICD— o solo puede aplicarse a una rama específica mientras el desarrollo continúa en otras ramas, pero todavía existe. No importa lo refinado que se haya vuelto Agile, casi siempre habrá un punto en todas las hojas de ruta de desarrollo y lanzamiento en el que una nueva pieza de software o característica se evaluará en un estado fijo antes de que llegue a los usuarios del mundo real.
El Problema Con El Argumento 3: Repensar la velocidad y la calidad
Si utiliza bloqueos de código, agregará un nuevo paso a su ciclo de desarrollo y lanzamiento. No hay duda de eso. Y cada vez que agregas un nuevo paso a cualquier proceso, ralentizas ese proceso y creas un nuevo punto de falla potencial. Los bloqueos de código no son una excepción.
Pero es importante dar un paso atrás y tener una visión más amplia de la desaceleración y la pérdida de productividad.
Si su característica tiene errores, deberá corregirlos, independientemente de si los detectó durante una congelación de código o si se dieron a conocer después del lanzamiento. Desde una perspectiva de desarrollo puro, la cantidad de tiempo necesario para solucionarlos será aproximadamente la misma en ambos escenarios.
Pero si está lidiando con errores en un entorno en vivo, tiene una serie de otros problemas que necesita tratar, incluidos:
- Decidir si revertir la función de buggy o dejarla en funcionamiento.
- Sacar a tus desarrolladores de sus nuevos proyectos, después de que hayan comenzado a trabajar.
- Compensando a los usuarios del mundo real que se vieron afectados por los errores.
- Responder y administrar a sus partes interesadas internas que no están muy contentos con su publicación problemática.
La lista continúa. No hay nada más complicado, lento y destructivo para la productividad, para usted y su equipo, que lanzar una característica o producto roto. Los bloqueos de código minimizan las posibilidades de que esto suceda.
Y en cuanto al argumento de que el código se congela conduce a características y productos de menor calidad porque reducen la cantidad de requisitos comerciales que puede recopilar? Los requisitos de su negocio siempre serán poco más que una» mejor suposición » en cuanto a cómo debería funcionar su producto o característica. Los requisitos más valiosos siempre vendrán de los usuarios del mundo real, implementando su producto o característica en escenarios del mundo real. Y solo puede recopilar esos requisitos dando a sus usuarios versiones funcionales que puedan implementar de la manera más fluida y libre de errores posible.
¿Debería Utilizar Bloqueos de Código en Su Gestión Ágil de Productos?
En última instancia, los bloqueos de código siguen desempeñando un papel importante para muchos gerentes de productos ágiles.
Ahora, hay casos en los que desempeñan un papel menos crítico. Es posible que los proyectos muy pequeños no necesiten períodos de congelación de código dedicados. Las nuevas características que tienen consecuencias relativamente menores si se envían de forma imperfecta podrían no valer la pena congelarse. Lo mismo es cierto para los planes de lanzamiento por fases, como los lanzamientos de Canary, cuando solo desea probar nuevas funciones con un público cálido que ha preparado para esperar una experiencia imperfecta y con errores.
Pero en la mayoría de los casos, vale la pena tomarse el tiempo, incluso un período de tiempo muy corto, para asegurarse de que sus nuevas funciones sean tan perfectas como cree que son antes de ponerlas en manos de las personas que más importan: sus usuarios del mundo real.
Este artículo se publicó inicialmente en flagship.io
