Desarrollo ágil de software: Qué es y qué se obtiene de él

¿Qué es el desarrollo ágil de software?

El desarrollo ágil de software suena deseable y, al mismo tiempo, un poco ilusorio. Todo lo que se dice sobre la entrega de productos excelentes que deleitan al usuario final y sobre lo divertido que es para usted trabajar con un gran equipo…

¿Es realmente posible o es sólo un sueño? ¿Merece la pena el esfuerzo de ser ágil? ¿Funcionarán las herramientas y técnicas ágiles para usted y su empresa?

Bueno, vamos a profundizar.

Breve reseña

Ágil es una mentalidad basada en un conjunto de valores y principios. El desarrollo de software ágil está anclado en ellos y valora lo siguiente.

  • Basado en el valor: ofrecer valor a su cliente.
  • Poner a las personas y sus interacciones en primer lugar: trabajar de forma colaborativa y orientada al cliente, para acabar con clientes, usuarios y equipo de desarrollo contentos.
  • La confianza es esencial. No solo dentro de un equipo. La dirección debe confiar en que todo el mundo quiere hacer un buen trabajo y dejar que el equipo se autogestione para obtener resultados.
  • La comunicación en todos los niveles del equipo es vital. Los comentarios regulares de los clientes y las partes interesadas mantienen al equipo en el buen camino.
  • Trabajar el software lo antes posible significa ofrecer valor desde el principio.
  • El trabajo incremental e iterativo significa que se dan pequeños pasos hacia adelante y se corrige el rumbo cuando el cliente se da cuenta de que es necesario un cambio, normalmente gracias a ver el producto en crecimiento en acción.
  • Resultados rápidos: dividir el producto final en trozos del tamaño de un bocado y trabajar en esos trozos significa que todo el equipo ve los resultados de trabajo en las primeras semanas y evita descubrir que se ha fracasado un par de años después.

Todo esto tiene sentido, ¿verdad? Entonces, ¿por qué existe Ágil?

Agile Development

Breve historia

En los años 80 y 90, el método de gestión de proyectos predominante era el modelo de cascada. Muy utilizado en proyectos de construcción y fabricación, exigía mucho papeleo, un diseño fijo y la entrega del producto final sólo al final de la fase de construcción.

Dado que el desarrollo de software es una actividad compleja, en lugar de una actividad complicada como la construcción y la fabricación, muchos proyectos de software se salían del plazo y del presupuesto y no satisfacían las intenciones y requisitos del cliente.

Un ejemplo paradigmático fue proyecto informático del Servicio Nacional de Salud del Reino Unido, que costó más de 10.000 millones de libras y no funcionó.

Algo tenía que cambiar y varios enfoques diferentes surgieron a finales de los 80 y los 90.

Por ejemplo, la creación de prototipos, el método de desarrollo dinámico de software (o de sistemas), Scrum y la programación extrema (XP).

Entonces, en 2001, un grupo de 17 desarrolladores de software, polémicos pero con éxito, se reunieron para discutir mejores métodos de desarrollo de software.

Estuvieron de acuerdo en que el desarrollo de software debía ser adaptable al cambio, orientado al cliente y orientado al valor. Resumieron sus discusiones en un manifiesto que enumeraba 4 valores y 12 principios esenciales para el éxito del desarrollo de software: el Manifiesto Ágil.

A día de hoy, el manifiesto sigue siendo el estándar al que hay que aspirar.

Software Development Lifecycle

Los 4 valores ágiles son:

  • Personas e interacciones por encima de procesos y herramientas
  • El software de trabajo por encima de la documentación exhaustiva
  • La colaboración con el cliente por encima de la negociación de contratos
  • Responder al cambio por encima de seguir un plan.

Los 12 principios son directrices de sentido común sobre lo que supone cumplir uno o varios de estos valores. Puede leerlos todos en esta infografía.

Los 12 principios son directrices de sentido común sobre lo que supone cumplir uno o varios de estos valores. Puede leerlos todos en esta infografía.

¿Cómo funciona?

Todo comienza con la mentalidad ágil y la promesa que encierra.

La Mentalidad

La agilidad consiste en elegir actuar de acuerdo con valores y principios de sentido común que aporten valor de forma sostenible para todos los implicados.

El director general Anthony Fox-Davies lo explicó como la búsqueda de formas de sortear los obstáculos, buscando soluciones que ofrezcan una calidad excelente.

Para ello, hay que fomentar la colaboración y las interacciones significativas. Y eso exige centrarse en los seres humanos y fomentar el respeto y la confianza para mejorar la vida de todos: incluidos el cliente, el usuario final y los desarrolladores.

Ya lo decía Aristóteles:

«El placer en el oficio pone la perfección en el trabajo.”

La promesa de Agile: soluciones a los problemas

Aplicar esa mentalidad al trabajo en ingeniería de software promete ofrecer resultados como estos:

  • Mejor alineación con los objetivos empresariales (del cliente)
  • Mayor productividad
  • Mayor calidad
  • Reducción del tiempo de comercialización
  • Mayor satisfacción de los clientes/partes interesadas
  • Mayor satisfacción laboral para los desarrolladores
  • Empleados más comprometidos
  • Mejores resultados para el usuario final

Los clientes y los desarrolladores lo adoran.

Customer Satisfaction

Conseguirlo requiere un esfuerzo intencionado y no siempre es fácil de mantener.

El panorama ágil más amplio

Extensión a DevOps y DevSecOps

A menudo, durante el desarrollo se pasa por alto lo que supone el funcionamiento de un producto de software, lo que dificulta que éste siga funcionando sin problemas para sus usuarios.

DevOps — Desarrollo y Operaciones: trata de solucionar este problema reuniendo a desarrolladores y operadores en un equipo. Al trabajar en colaboración, pueden reducir el tiempo de despliegue, solucionar los errores más rápidamente y prolongar la vida del producto.

Además, DevSecOps añade expertos en seguridad a un equipo para mantener la seguridad de su producto al día con medidas de seguridad explícitas y ayudar a los desarrolladores a evitar construcciones de software que puedan ser explotadas por los hackers.

Devops

Gestión ágil de proyectos

Las habilidades de proyecto utilizadas en el desarrollo ágil de software se transfieren fácilmente a otros tipos de desarrollo de productos. Rudi Schenker escribe sobre su aplicación a otros campos de la ingeniería, como la química, la eléctrica, el control y la instrumentación, entre otros.

Culturas empresariales ágiles

La mentalidad ágil funciona bien en otras disciplinas además de la ingeniería (de software). El equipo de marketing, el equipo de gestión de proveedores y el equipo de ventas pueden aplicarlo a sus actividades. Casi todos los departamentos corporativos habituales pueden beneficiarse de ser más ágiles.

Los marcos ágiles como Ágil Disciplinado, SAFe, el método Crystal y Kanban son herramientas adecuadas para ayudar a una empresa a ser más ágil. Ofrecen formas de optimizar la organización corporativa integrando métodos de trabajo ágiles y en cascada.

Para más información de esto, leer: “Here’s Why (And How) Non-Software Teams Are Adopting Agile Methodologies.”

Pero volvamos al desarrollo ágil de software.

Ciclo de vida del desarrollo de software ágil

El ciclo de vida del desarrollo ágil de software comienza con un cliente que quiere resolver un problema con un nuevo software.

El equipo o equipos que desarrollarán el software colaborarán con los profesionales de la empresa del cliente para averiguar qué necesitan los usuarios finales que haga el software.

Juntos, determinan y priorizan las características necesarias del producto y deciden las características que conformarán un producto mínimo viable, es decir, las características esenciales que se entregarán en la primera versión.

A partir de ahí, se pasa a un desarrollo iterativo e incremental durante toda la vida del producto.

Desarrollo y entrega iterativos e incrementales

El desarrollo y la entrega en ágil son iterativos. El trabajo se realiza en iteraciones cortas, que suelen durar una o dos semanas, y a veces hasta cuatro. A veces, hasta 4. También es incremental porque en cada iteración se construyen pequeñas porciones de software funcional que pueden valerse por sí mismas.

Aquí hay más información sobre este proceso. Desarrollo iterativo e incremental: Negarse a elegir

Las mini cascadas siguen siendo cascadas

La mayoría de las organizaciones comienzan su viaje ágil acortando la cascada a su longitud de iteración. Básicamente, ejecutan mini cascadas en una corta sucesión.

Agility

Aunque hacer esto tiene sus ventajas, también tiene muchos inconvenientes:

  • Mantiene a las personas encerradas en sus roles tradicionales.
  • Mantiene las puertas de la fase de cascada, lo que lleva a un montón de tiempo de espera (desperdiciado) y colas de inventario de trabajo inacabado.
  • La cooperación entre personas con roles diferentes suele ser mejor porque el tema está todavía relativamente fresco en la mente de la persona anterior, pero está muy lejos de la verdadera colaboración en la que las personas trabajan juntas para abordar un elemento de trabajo.

Colaboración ágil

La verdadera agilidad colaborativa es diferente. Elimina las fases tradicionales en cascada (análisis, diseño, implementación, pruebas, entrega y operación), pero no elimina las actividades realizadas en ellas.

En la verdadera agilidad colaborativa, un equipo se encarga de un solo elemento de trabajo. Se discute el diseño, los criterios de aceptación, etc., tanto para el usuario como para los operadores, y luego se pone en práctica lo que se ha decidido en grupos más pequeños, por ejemplo, mediante la programación en parejas.

Todo esto puede parecer una enorme pérdida de tiempo de los recursos de la gente para cualquiera que sea nuevo en la agilidad.

Sin embargo, es más importante centrarse en el relevo que en los corredores en una carrera de relevos, una analogía utilizada en la fabricación ajustada y el desarrollo de software. Conseguir que el trabajo se «haga» y, por tanto, el valor para sus clientes antes es más importante que mantener a todo el mundo ocupado en todo momento. Esto genera más valor para la empresa a largo plazo.

Conseguir que el cliente, o un representante del cliente, se involucre activamente y sea fácilmente accesible para el equipo en todo momento irá aún más lejos para garantizar que se entregue más valor antes, ya que puede evitar que el equipo se meta en agujeros de conejo de características que suenan bien, pero que en realidad no ofrecen ningún valor comercial.

Mantener el ritmo

Si bien la agilidad se centra en la entrega de valor al cliente antes, eso no significa que haya que eliminar las buenas prácticas de ingeniería. Sí, a corto plazo, eso puede acelerar la entrega de valor, pero a largo plazo te hará tropezar, ya que el código se «pudre» y rápidamente se vuelve más y más difícil de cambiar.

Esto conduce a más errores, más informes de fallos y más tiempo dedicado a arreglar problemas que a entregar nuevo valor.

Por eso todo marco o metodología ágil debe incorporar buenas prácticas de desarrollo. Por ejemplo, mediante la adopción de la Programación Extrema , el «Ágil del desarrollador».

Agile-Method

Reducir los residuos para acelerar, de forma sostenible

La aceleración no se consigue haciendo que la gente trabaje más duro o más rápido. No se consigue recortando gastos. Al menos no a largo plazo.

Convertirse en ágil es como ir al gimnasio: se trata de recortar la grasa de los procesos.

Por eso muchos marcos ágiles, como LeSS and SAFe, y SAFe, han tomado una página del libro de Lean Manufacturing y han adoptado la teoría de gestión de flujos y colas para ayudarte a tomar decisiones sobre tu proceso.

Considere estos ejemplos

¿Por qué producir documentación cuando se puede crear código de forma autodocumentada y ser comprobable de forma automatizada al mismo tiempo?

  • Por qué producir diseños cuando los diseñadores y desarrolladores pueden colaborar en la implementación?
  • ¿Por qué elaborar voluminosas guías de usuario cuando se puede diseñar una interfaz autodocumentada con explicaciones in situ?

Similitudes y Diferencias

La cascada está orientada a las fases y cada fase se basa en la anterior.

Cada fase se concentra en una sola actividad -análisis de negocio, diseño funcional, diseño técnico, programación, pruebas- para todo el producto.

No se puede ver nada funcionando antes de que todo haya pasado por las fases que preceden a la programación real y se hayan programado al menos algunas características. Corregir el rumbo en cualquier fase significa rehacer mucho trabajo de las fases anteriores.

Ágil está orientado al valor y al producto.

Se entrega un software que funciona desde el principio y se puede ver el producto a medida que crece. Esto permite una retroalimentación mucho más temprana y la corrección del curso a medida que se avanza con un desperdicio mínimo.

Los equipos siguen realizando las mismas actividades que en un proceso en cascada, pero lo hacen en colaboración y para una pequeña parte cada vez. Esto concentra las idas y venidas entre, por ejemplo, el análisis y la programación en un pequeño periodo de tiempo y se beneficia del hecho de que todo está todavía fresco en la mente de todos.

Funciones y responsabilidades clave

Al examinar cualquier marco de trabajo ágil, reconocerá las siguientes funciones clave, aunque pueden tener nombres ligeramente diferentes.

  • El cliente, o un representante, que aporta la perspectiva empresarial.
  • El director de producto, que actúa como enlace entre los clientes, los usuarios y los equipos. Los equipos siguen trabajando directamente con los clientes y los usuarios para aclarar lo que van a crear a continuación, pero el gestor de producto los reúne. Al no meterse en la maleza, el gestor de producto es libre de hacer un trabajo más orientado al futuro.
  • Personas de diferentes disciplinas trabajan juntas en (una parte de) el producto en el equipo. Un equipo siempre incluye a las personas que realmente producen el producto, es decir, desarrolladores, diseñadores, analistas, probadores, y puede incluir a otros.
  • El coach ayuda al equipo y a todas las partes interesadas a adoptar la mentalidad y los valores ágiles, y a trabajar de acuerdo con los principios. Algunos distinguen entre entrenadores de equipo y entrenadores ágiles, donde los entrenadores de equipo se centran en 1 a 3 equipos, y los entrenadores ágiles ayudan a la organización más amplia. El papel del Scrum Master en Scrum se define haciendo ambas cosas, pero en la práctica el Scrum Master es a menudo visto como un entrenador de equipo.

En muchos marcos ágiles, los directores de línea y los directores de proyecto no tienen ningún papel. Por eso puedes esperar una resistencia abierta y no tan abierta, a menos que les ayudes a redefinir su papel y su valor en un entorno ágil. LeSS tiene consejos específicos al respecto.

Reuniones clave, ciclos y cadencias de entrega

Agile-Method

Una cadencia de entrega es la frecuencia con la que se lanza una nueva versión a los clientes. Una iteración, o ciclo, es el tiempo que un equipo trabaja antes de hacer una pausa, reflexionar y planificar los siguientes pasos.

  • Las cadencias de entrega varían mucho. Desde las entregas trimestrales, por ejemplo en muchos marcos ágiles a escala, hasta la entrega continua y el despliegue continuo, en los que los usuarios reciben actualizaciones incluso mientras utilizan el producto. En muchas organizaciones la cadencia de entrega es igual a la duración de sus iteraciones.
  • Los ciclos de iteración tienden a ser de 1 a 4 semanas. La mayoría de los equipos de Scrum prefieren Sprints de 2 semanas, Kanban y Lean suelen trabajar con una sola semana. Por lo general, cuanto más larga es la iteración, menos beneficios se obtienen del aprendizaje y el ajuste y la mejora de la práctica ágil.

Las reuniones en ágil tienen propósitos específicos, aunque pueden tener diferentes nombres en cada marco. Las reuniones en una iteración son:

  • Reuniones de perfeccionamiento para aclarar lo que hay que hacer para el trabajo que se asumirá en breve. Algunos marcos ven esto más como una actividad que como una reunión.
  • Una reunión de retrospectiva para mirar atrás y aprender, y tomar medidas para mejorar el proceso en la siguiente iteración.
  • Una reunión de planificación para decidir en qué trabajará el equipo en la siguiente iteración y resolver cualquier cuestión pendiente. Lo ideal es que la reunión de planificación de la siguiente iteración se celebre después de la retrospectiva para poder aplicar inmediatamente las lecciones aprendidas.
  • Una reunión de inspección en la que el equipo presenta lo que ha creado durante la iteración y recibe los comentarios de los clientes, el director de producto y otras partes interesadas.
  • Una reunión de comprobación diaria para que el equipo siga centrándose y avanzando hacia el objetivo de su iteración actual.

Puede haber reuniones similares para coordinar el trabajo de muchos equipos, especialmente cuando la cadencia de entrega difiere de la duración de la iteración.

Métodos y técnicas

Hay muchos marcos y metodologías disponibles que le ayudarán en su viaje ágil. Por ejemplo, Scrum, Kanban, Scrum, Kanban, Lean Software Development, y Programación Extrema.

También encontrará marcos para ayudar a escalar la agilidad a varios equipos e incluso a toda la organización. Encontrarás un resumen completo pero sucinto en “6 marcos ágiles escalados: ¿cuál es el adecuado para usted?

He aquí un rápido vistazo a algunas técnicas bien conocidas.

  • Historias de usuario  y mapeo de historias para crear una visión del producto, identificar los requisitos individuales y priorizarlos en varias versiones.
  • Desarrollo impulsado por el comportamiento para facilitar la comunicación y la colaboración con su cliente y producir un producto que pueda ser verificado de forma automatizable.
  • El Desarrollo Dirigido por Pruebas, que es independiente pero también forma parte del Desarrollo Dirigido por el Comportamiento, para informar el diseño de su código y crear una red de seguridad alrededor de él que reduzca la ansiedad por romper algo con un cambio.
  • La refactorización es una técnica utilizada en el desarrollo guiado por pruebas y fuertemente recomendada por Extreme Programming para mantener el código susceptible de cambios.
  • Otro método muy defendido por la Programación Extrema, es el Pair programming, o emparejamiento. Es un medio de colaboración, formación y prevención de errores (dos ven más y saben más que uno).

Hay muchos otros marcos, herramientas y técnicas que se utilizan en el trabajo ágil, y continuamente aparecen nuevos productos. Pruebe estos boletines para estar al día.

Errores comunes: Por qué Ágil no siempre funciona

Google sigue utilizando algunas metodologías en cascada y Amazon se describe como Lean pero no ágil. Pero se puede aprender mucho de los escollos que a veces hacen fracasar a los ágiles.

  • Hacer ágil

La mayor razón de los fracasos ágiles es cuando la gente sigue los pasos. Por ejemplo, realizar las reuniones prescritas, pero no adoptar la mentalidad, los valores y los principios, o no hacerlo completamente. A veces ni siquiera las buenas prácticas de ingeniería. Esto se conoce como «hacer» ágil en lugar de convertirse en ágil.

  • Falta de una dirección clara desde arriba

Es necesario que la dirección esté a bordo y participe en los procesos. No contar con el apoyo de la dirección es una forma segura de desincentivar a todo el mundo para que solucione los obstáculos del trabajo ágil.

  • Entrenamiento inadecuado

Los equipos no se convierten en ágiles o autogestionados por declararlos así. No ayudar a un equipo en este proceso es una trampa común.

  • No todo el mundo es apto para ágil

Aunque la agilidad y el cumplimiento de las normas no se excluyen mutuamente, los sistemas altamente regulados, como la sanidad, no se prestan fácilmente al trabajo ágil.

  • Intereses creados

La forma ágil de trabajar exige un cambio radical que a menudo choca con los intereses creados y con las estructuras organizativas y los sistemas de recompensa de toda la vida. Sobre todo en las grandes empresas y gobiernos, acostumbrados a contratos rígidos y a una dirección vertical.

Recuerda que puedes seguir utilizando tu mentalidad ágil y algunos marcos ágiles incluso si un cliente insiste en un enfoque en cascada, como costes fijos y plazos de entrega fijos. Por ejemplo, así es como Kanban puede ayudar.

Empezando

La clave para ser ágil es adoptar la mentalidad y las prácticas que facilitan la entrega de un producto valioso y mantenerlo en forma para poder responder rápidamente a los cambios en los requisitos de los clientes, el entorno empresarial y las necesidades de los usuarios finales.

Llegar a ese punto es un viaje y ganarse los corazones y las mentes es la clave para seguir adelante. Aquí tiene algunos pasos para ponerse en marcha.

  • Sobre todo, desarrolle y utilice su propia mentalidad ágil.
  • Emplee entrenadores ágiles para empezar y mantener el rumbo.
  • Identifique a los líderes ágiles dentro de su empresa para garantizar su comprensión y patrocinio.
  • Forme a los gerentes y a los desarrolladores de software para que no hablen entre ellos.
  • Consiga que las personas clave más entusiastas se certifiquen en métodos y marcos ágiles.
  • Invierta en en programas de TI adecuados que apoyen su trabajo ágil.
  • Identificar las oportunidades de mayor agilidad en sus metodologías de desarrollo actuales.
  • Introduzca marcos que funcionen en su empresa.
  • Examine herramientas como Kanban para establecer sus objetivos, supervisar el progreso y lograr resultados.
  • Introduzca el cambio de forma gradual para que no resulte abrumador para todos los implicados.

Reconozca que llevará tiempo realizar todos los cambios necesarios para pasar a un modelo de negocio totalmente ágil. Dependiendo de la escala de la adopción de Agile en su empresa, hay varias herramientas disponibles que apoyarán su viaje – puede ver las herramientas de Digite aquí ( https://www.digite.com/products/).

Más información

Libros y artículos

Metodologías ágiles en profundidad: Sudiptar Malakar.

Guía rápida de gestión de proyectos ágiles: Ed Stark.

La Guía de Scrum: Ken Schwaber y Jeff Sutherland.

Scrum Product Ownership:  Navigating the Forest and the Trees:  Bob Galen.

Desbloqueando la Agilidad: An Insider’s Guide to Agile Enterprise Transformation: Jorgen Hesselberg

Examinar el Manifiesto Ágil: Scott Ambler

Agile ha muerto.  Larga vida a la agilidad: Dave Thomas

Entrenamiento y formación

Digité ofrece tanto formación como servicios de consultoría Ágil y puede ayudarle rápidamente a usted y a su equipo a ponerse al día.

Certificación y acreditación

Como formador acreditado por la Universidad Kanban, los servicios de formación de Digité incluyen formación especializada y certificación en Kanban.

ICAgile ofrece acreditación

Tanto Scrum.org como Scrum Alliance ofrecen cursos de certificación.

Desenredar la terminología ágil

He aquí una guía rápida de la terminología ágil (que puede resultar muy confusa para los recién llegados).

Qué es la mentalidad ágil

La mentalidad ágil es una forma de pensar en el desarrollo de productos (de software) basada en los valores y principios ágiles establecidos en el Manifiesto Ágil.

¿Qué son los métodos ágiles de desarrollo de software?

Los métodos ágiles de desarrollo de software son otra forma de referirse a las metodologías, técnicas y prácticas utilizadas para desarrollar software de forma ágil.

Qué es la metodología ágil

Una metodología ágil consiste en las prácticas que un equipo utiliza para realizar una tarea. Cada equipo se basa en diferentes marcos, técnicas, herramientas y prácticas para desarrollar su propia metodología para un proyecto concreto. Recurrir a una serie de metodologías le ayuda a ser ágil sin reinventar la rueda. Para más información, lea Qué es la metodología ágil.

¿Qué son los marcos?

Los marcos te dicen qué hacer, pero no dicen mucho sobre cómo hacerlo. Los equipos y las organizaciones tienen que completar estos marcos con buenas prácticas para todas las actividades del desarrollo de software.

Campeón del desarrollo ágil de software

El desarrollo ágil de software es deseable y no es una ilusión.

A pesar de los fracasos y decepciones que se pueden leer, hay muchas empresas que están cosechando los beneficios.

Sólo hay que tener en cuenta que no se llega a ser ágil de la noche a la mañana.

Es un proceso. Hay mucho que aprender y mucho que desaprender.

Pero también hay mucho que disfrutar.

Al trabajar en colaboración, te sientes apoyado. Sabes cómo obtener ayuda. Puedes divertirte y trabajar juntos. Confías en el proceso y en tus compañeros. Te encanta que entregues más valor antes. Te sientes mucho más productivo y orgulloso de tus logros.

Así que, ¡a por ello!

Comienza tu viaje para convertirte en ágil. Adopte la mentalidad ágil y trabaje para conseguir equipos más felices y productivos que puedan responder mejor a sus clientes de forma sostenible.

Rocket

¡La vida es buena cuando sus equipos ágiles están sincronizados!

Solicite una demostración personalizada de SwiftEnterprise.