Compartir a través de


¿Qué es el desarrollo de Agile?

El desarrollo ágil es un término que se usa para describir el desarrollo de software iterativo. El desarrollo de software iterativo reduce el ciclo de vida de DevOps completando el trabajo en incrementos cortos, normalmente denominados sprints. Los sprints suelen tener una duración de una a cuatro semanas. A menudo, el desarrollo ágil se contrasta con el desarrollo tradicional o en cascada, que planea proyectos más grandes por adelantado y los completa según el plan.

La entrega de código de calidad de producción en cada sprint requiere que el equipo de desarrollo ágil tenga en cuenta un ritmo acelerado. Toda la codificación, pruebas y verificación de calidad deben realizarse en cada sprint. A menos que un equipo esté configurado correctamente, los resultados pueden no cumplir con las expectativas. Aunque estas decepciones ofrecen grandes oportunidades de aprendizaje, resulta útil aprender algunas lecciones clave antes de empezar.

En este artículo se describen algunos factores clave de éxito para los equipos de desarrollo de Agile:

  • Refinamiento diligente del trabajo pendiente
  • Integración desde etapas tempranas y de manera frecuente
  • Minimizar la deuda técnica

Refinamiento diligente del trabajo pendiente

Un equipo de desarrollo Agile trabaja con un backlog de requisitos, que a menudo se denominan historias de usuario. El backlog es priorizado, con las historias de usuario más importantes en la parte superior. El propietario del producto posee el listado de pendientes y agrega, cambia y reprioriza historias de usuario en función de las necesidades del cliente.

Imagen de un panel Kanban que contiene varias columnas. En cada columna, hay algunas tarjetas visibles.

Una de las mayores desventajas para la productividad de un equipo ágil es un backlog mal definido. No se puede esperar que un equipo ofrezca software de alta calidad de forma coherente cada sprint a menos que tengan requisitos claramente definidos.

El trabajo del propietario del producto es asegurarse de que cada sprint, los ingenieros han definido claramente los casos de usuario con los que trabajar. Las historias de usuario en la parte superior de la lista de pendientes deben estar siempre listas para que el equipo comience. Esta noción se denomina refinamiento de trabajos pendientes. Mantener un trabajo pendiente listo para un equipo de desarrollo ágil requiere esfuerzo y disciplina. Afortunadamente, vale la pena la inversión.

Al refinar un trabajo pendiente, recuerde las siguientes consideraciones clave.

  1. Refinar las historias de usuario suele ser una actividad prolongada. Las interfaces de usuario elegantes, los diseños de pantalla hermosos y las soluciones de placer del cliente tardan tiempo y energía en crearse. Los product owners diligentes refinan las historias de usuario con dos a tres sprints de antelación. Tienen en cuenta las iteraciones de diseño y las opiniones de los clientes. Trabajan para asegurarse de que cada historia de usuario es algo que el equipo de Agile está orgulloso de entregar al cliente.

  2. Una historia de usuario no se refina a menos que el equipo lo diga. El equipo debe revisar el caso del usuario y aceptar que está listo para trabajar. Si un equipo no ve el caso del usuario hasta el día uno de un sprint, es probable que se produzcan problemas.

  3. Historias de usuario en la parte inferior del backlog pueden permanecer ambiguas. No pierda tiempo refinando los elementos de prioridad inferior. Céntrese en la parte superior del trabajo pendiente.

Integrar temprano y con frecuencia

La integración continua y la entrega continua (CI/CD) configuran a su equipo para el ritmo rápido del desarrollo ágil. Tan pronto como sea posible, automatice las canalizaciones de compilación, prueba e implementación. Configure esa automatización como una de las primeras tareas que su equipo aborda al iniciar un nuevo proyecto.

Con la automatización, el equipo evita procesos de implementación manuales lentos, propensos a errores y que requieren mucho tiempo. Dado que los equipos liberan cada sprint, no hay tiempo para realizar estas tareas manualmente.

CI/CD también influye en la arquitectura de software. Garantiza la entrega de software compilable e implementable. Cuando los equipos implementan una característica difícil de implementar, se dan cuenta inmediatamente si se produce un error en la compilación y las implementaciones. CI/CD obliga a un equipo a corregir los problemas de implementación a medida que se producen. El producto siempre está listo para enviarse.

Gráfico de barras abstractos que muestra el estado de las compilaciones de CI a lo largo del tiempo. La mayoría de las compilaciones se han realizado correctamente. Solo se produjo un error.

Hay algunas actividades clave de CI/CD que son fundamentalmente importantes para el desarrollo ágil eficaz.

  1. Pruebas unitarias. Las pruebas unitarias son la primera defensa contra el error humano. Considere la posibilidad de que las pruebas unitarias formen parte de la codificación. Compruebe las pruebas con el código. Haga que las pruebas unitarias formen parte de cada compilación. Las pruebas unitarias con errores significan que se produjo un error en la compilación.

  2. Automatización de la construcción. El sistema de compilación debe extraer automáticamente el código y las pruebas directamente desde el control de código fuente cuando se ejecutan compilaciones.

  3. Políticas de rama y compilación. Configura directivas de rama y de compilación para compilar automáticamente cuando el equipo integra el código en una rama específica.

  4. Implemente en un entorno. Configure un pipeline de lanzamiento que implemente automáticamente proyectos compilados en un entorno que emula el de producción.

Minimizar la deuda técnica

Con las finanzas personales, es más fácil mantenerse libre de deudas que salir de ellas. La misma regla se aplica con deuda técnica. La deuda técnica incluye todo lo que el equipo debe abordar debido a los atajos que se tomaron anteriormente. Por ejemplo, si tiene una programación ajustada, puede sacrificar la calidad para cumplir una fecha límite. La deuda técnica es el precio que pagas más adelante, cuando tienes que refactorizar el código para compensar esa falta de calidad. Entre los ejemplos se incluyen correcciones para solucionar problemas de diseño deficiente, errores, problemas de rendimiento, problemas operativos, problemas de accesibilidad y otros problemas.

Mantenerse al tanto de la deuda técnica requiere valor. Hay muchas presiones para retrasar el retrabajo del código. Se siente bien trabajar en funcionalidades e ignorar la deuda técnica. Desafortunadamente, alguien debe pagar la deuda técnica antes o después. Al igual que la deuda financiera, la deuda técnica se vuelve más difícil de pagar cuanto más tiempo exista. Un propietario de producto inteligente trabaja con su equipo para asegurarse de que hay tiempo para pagar la deuda técnica cada sprint. Equilibrar la reducción de la deuda técnica con el desarrollo de características es una tarea difícil. Afortunadamente, hay algunas técnicas sencillas para crear equipos productivos centrados en el cliente.

Siempre ser Ágil

Ser Ágil significa aprender de la experiencia y mejorar continuamente. El desarrollo ágil proporciona más ciclos de aprendizaje que el planeamiento de proyectos tradicional debido a los bucles de proceso más estrictos. Cada sprint proporciona algo nuevo para que el equipo aprenda.

Por ejemplo:

  • Un equipo entrega valor al cliente, obtiene comentarios y, a continuación, modifica su trabajo pendiente en función de esos comentarios.
  • Aprenden que sus compilaciones automatizadas faltan pruebas clave. Incluyen trabajo en su siguiente sprint para solucionar este problema.
  • Encuentran que ciertas características funcionan mal en producción, por lo que hacen planes para mejorar el rendimiento.
  • Alguien del equipo se entera de una nueva práctica. El equipo decide probarlo durante unos sprints.

Los equipos que acaban de empezar con el desarrollo ágil deben esperar más oportunidades de aprendizaje. Son una parte inestimable del proceso porque conducen al crecimiento y la mejora.

Pasos siguientes

Hay muchas maneras de establecerse en un proceso de desarrollo ágil adecuado para un equipo. Azure DevOps proporciona varias plantillas de proceso. Los equipos que buscan diferentes estructuras de línea base a su planeación pueden usar estas plantillas como puntos de partida. Para obtener información sobre cómo seleccionar una plantilla de proceso que mejor se adapte a la referencia cultural y los objetivos de un equipo, consulte Elección de un flujo de proceso o una plantilla de proceso para trabajar en Azure Boards.

A medida que crecen las organizaciones, puede ser un desafío mantenerse disciplinado. Obtenga más información sobre el escalado de Agile a equipos de gran tamaño.