Compartir a través de


¿Qué es el desarrollo de Agile?

El desarrollo de Agile es un término que se usa para describir el desarrollo de software iterativo. El desarrollo de software iterativo acorta el ciclo de vida de DevOps mediante la ejecución en incrementos más pequeños, normalmente denominados sprints. Los sprints suelen durar entre una y cuatro semanas. El desarrollo de Agile suele contrastar con el desarrollo tradicional o en cascada, donde los proyectos más grandes se planean por adelantado y se ejecutan siguiendo ese plan.

La entrega de código de calidad de producción en cada sprint requiere que el equipo de desarrollo de Agile se haga responsable del ritmo acelerado. En todos los sprints, se deben realizar la codificación, las pruebas y la comprobación de calidad. Si un equipo no está bien organizado, los resultados pueden no estar a la altura de las expectativas. Aunque estas decepciones ofrezcan grandes oportunidades de aprendizaje, es útil aprender algunas lecciones clave antes de empezar.

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

  • Optimización dinámica del trabajo pendiente
  • Integración temprana y frecuente
  • Reducción de la deuda técnica

Optimización dinámica del trabajo pendiente

Un equipo de desarrollo de Agile trabaja con requisitos de trabajo pendiente, a menudo denominados casos de usuario. El trabajo pendiente tiene prioridad y los casos de usuario más importantes se encuentran en la parte superior. El propietario del producto posee el trabajo pendiente y agrega, cambia y vuelve a dar prioridad a los casos de usuario en función de las necesidades del cliente.

Image of a Kanban board that contains several columns. In each column, a few cards are visible.

Uno de los mayores obstáculos en la productividad de un equipo de desarrollo ágil es un trabajo pendiente mal definido. No se puede esperar que un equipo entregue de forma consistente software de alta calidad en cada sprint a menos que tenga requisitos claramente definidos.

El propietario del producto debe asegurarse de que, en cada sprint, los ingenieros dispongan de casos de usuario claramente definidos con los que trabajar. Los casos de usuario en la parte superior del trabajo pendiente deben estar siempre listos para que el equipo empiece a trabajar en ellos. Esto se conoce como optimización del trabajo pendiente. Mantener el trabajo pendiente listo para un equipo de desarrollo de Agile requiere esfuerzo y disciplina. Por suerte, la inversión merece la pena.

Al optimizar el trabajo pendiente, tenga en cuenta las siguientes consideraciones clave.

  1. El análisis de los casos de usuario suele ser una actividad de larga duración. La creación de interfaces de usuario sofisticadas, diseños de pantalla impactantes y soluciones atractivas para el cliente requieren tiempo y energía. Los propietarios de productos rigurosos revisan los casos de usuario con dos o tres sprints de antelación. Consideran las iteraciones de diseño y las opiniones de los clientes. Trabajan para garantizar de que cada caso de usuario sea algo que el equipo de Agile esté orgulloso de entregar al cliente.

  2. Un caso de usuario no se analiza a menos que el equipo lo indique. El equipo debe revisar el caso de usuario y aceptar que está listo para trabajar en él. Si un equipo no conoce el caso de usuario hasta el primer día de un sprint, es probable que surjan problemas.

  3. Los casos de usuario que se encuentran más abajo en el trabajo pendiente pueden resultar ambiguos. No pierda tiempo analizando elementos de menor prioridad. Céntrese en la parte superior del trabajo pendiente.

Realice la integración temprana y frecuente

La integración continua y la entrega continua (CI/CD) preparan al equipo para el ritmo rápido del desarrollo de Agile. Tan pronto como sea posible, automatice los procesos de creación, prueba e implementación. Establezca esa automatización como una de las primeras tareas que el equipo aborde al iniciar un nuevo proyecto.

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

La CI/CD también afectan a la arquitectura del software. Garantiza la entrega de software compilable e implementable. Cuando los equipos implementan una característica difícil de desplegar, se dan cuenta inmediatamente si la compilación y las implementaciones fallan. La CI/CD obliga a un equipo a solucionar los problemas de implementación a medida que se producen. Por lo tanto, el producto siempre está listo para enviarse.

Abstract bar chart that shows the status of CI builds over time. Most builds succeeded. Only a few failed.

Hay algunas actividades clave de CI/CD que son de vital importancia para el desarrollo eficaz de Agile.

  1. Pruebas de unidad. Las pruebas unitarias son la primera protección contra el error humano. Considere las pruebas unitarias como 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 fallidas significan una compilación también fallida.

  2. Automatización de compilaciones. El sistema de compilación debe extraer de forma automática el código y las pruebas directamente del control de código fuente cuando se ejecute la compilación.

  3. Directivas de ramas y compilaciones. Configure directivas de ramas y compilaciones para compilar de forma automática a medida que el equipo comprueba el código en una rama específica.

  4. Implementar en un entorno. Configure un canal de distribución que despliegue automáticamente los proyectos compilados en un entorno que imite al de producción.

Minimizar la deuda técnica

Cuando se trata de finanzas personales, es más fácil no endeudarse que salir de las deudas. La misma regla se aplica con la deuda técnica. La deuda técnica incluye todo aquello que el equipo deba abordar debido a los atajos que se tomaron previamente. Por ejemplo, si tiene una programación apretada, es posible que sacrifique la calidad para cumplir un plazo. La deuda técnica es el precio que se paga más adelante, cuando se debe refactorizar el código para compensar esa falta de calidad. Algunos ejemplos son las medidas para solucionar problemas de diseño, errores, rendimiento, funcionamiento o accesibilidad, entre otros.

Estar al día con la deuda técnica requiere valentía. Hay muchas presiones para aplazar la revisión del código. Es agradable trabajar en las características e ignorar las deudas. Por desgracia, tarde o temprano alguien tiene que pagar la deuda técnica. Al igual que la deuda financiera, la deuda técnica es más difícil de pagar cuanto más tiempo pase. Un propietario de producto sensato trabaja con su equipo para asegurarse de que haya tiempo para saldar la deuda técnica en cada sprint. Conseguir un equilibrio entre la reducción de la deuda técnica y el desarrollo de características es una tarea difícil. Por suerte, existen algunas técnicas sencillas para crear equipos productivos y orientados al cliente.

Siempre sea Agile

Ser Agile significa aprender de la experiencia y mejorar continuamente. El desarrollo de Agile ofrece más ciclos de aprendizaje que el planeamiento de proyectos tradicional debido a los bucles de proceso más ajustados. Cada sprint aporta algo nuevo para que el equipo debe aprender.

Por ejemplo:

  • Un equipo ofrece valor al cliente, recibe comentarios y, a continuación, modifica su trabajo pendiente en función de ese comentario.
  • Aprende que a las compilaciones automatizadas les faltan pruebas clave. Incluye trabajo en próximo sprint para abordar la cuestión.
  • Descubre que determinadas características funcionan mal en producción, por lo que diseña planes para mejorar el rendimiento.
  • Alguien del equipo se entera de una nueva práctica. El equipo decide probarla durante algunos sprints.

Los equipos que apenas están comenzando con el desarrollo de Agile deben prever más oportunidades de aprendizaje. Son una parte de gran valor del proceso porque conducen al crecimiento y la mejora.

Pasos siguientes

Existen muchas formas de establecer un proceso de desarrollo de Agile adecuado para un equipo. Azure DevOps ofrece varias plantillas de proceso. Los equipos que busquen estructuras de referencia diferentes para su planeamiento pueden utilizar estas plantillas como base de partida. Para obtener información sobre cómo seleccionar una plantilla de proceso que mejor se adapte a la cultura 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 las organizaciones crecen, mantener la disciplina puede ser todo un reto. Descubra cómo escalar Agile a equipos grandes.