Metodologías Ágiles, desde la génesis a hoy

El desarrollo de software, como cualquier otra disciplina técnica, se ocupa de los siguientes temas principales: calidad, costo y confiabilidad. 

En este sentido, la correcta organización del proceso de desarrollo de software es la base para lograr el resultado planificado en el plazo previsto, con el nivel de calidad esperado y con un presupuesto adecuado.

Los problemas comunes en el proceso de desarrollo de software incluyen los siguientes:

  • 1. Cambiar los requisitos directamente en el proceso de desarrollo.
  • 2. Distribución poco clara de responsabilidad por el trabajo realizado y su resultado.
  • 3. La presencia de un flujo continuo de requisitos pequeños, “rápidos”, acumulados que distraen a los desarrolladores y gerentes de la línea principal de trabajo.
  • 4. Como resultado, se incumplen los plazos, se inflan los presupuestos y se pierde calidad.

Para resolver el problema de organizar con éxito el proceso de desarrollo de software, se creó una metodología de desarrollo de software flexible.

El desarrollo de software ágil es un conjunto de principios y reglas dentro del cual se lleva a cabo el desarrollo de software.

La metodología ágil es una familia de procesos de desarrollo, no el único enfoque para el desarrollo de software.

Los valores y principios de la Metodología Agile están consagrados en el documento 'Manifiesto Agile'. 

Ágil no incluye prácticas específicas, pero define los valores y principios que guían a los equipos exitosos.

"Agile Manifesto" fue desarrollado y adoptado el 11 de febrero de 2001 en la estación de esquí The Lodge at Snowbird en las montañas de Utah, EE. UU. 

El “Manifiesto” fue firmado por representantes de las siguientes metodologías:

  • Programación extrema
  • Scrum
  • DSDM
  • Desarrollo de software adaptativo
  • Transparente
  • Desarrollo basado en funciones
  • Programación pragmática

La mayoría de las metodologías ágiles apuntan a minimizar el riesgo al reducir el desarrollo a una serie de ciclos cortos llamados iteraciones, que generalmente duran de una a dos semanas. 

Cada iteración en sí misma parece un proyecto de software en miniatura e incluye todas las tareas necesarias para emitir un pequeño incremento en la funcionalidad: planificación, análisis de requisitos, diseño, codificación, pruebas y documentación. 

Si bien una sola iteración generalmente no es suficiente para lanzar una nueva versión de un producto, se supone que un proyecto de software ágil está listo para su lanzamiento al final de cada iteración. Al final de cada una de estas, el equipo reevalúa las prioridades de desarrollo.

Los métodos ágiles enfatizan la comunicación cara a cara.

Los equipos ágiles están ubicados en una sola oficina, a veces llamada bullpen. 

Como mínimo, también incluye a los "customers" (propietario del producto en inglés). Este es el cliente o su representante autorizado quien determina los requisitos del producto. 

Este rol puede ser desempeñado por un gerente de proyecto, un analista comercial o un cliente. 

La oficina también puede incluir probadores, diseñadores de interfaces, redactores técnicos y gerentes.

El principal resultado de la metodología ágil es un producto de software que funciona. 

Considerando que el producto de software en funcionamiento es el único indicador del trabajo del equipo del proyecto durante un período de tiempo finito, los creadores del concepto ágil formularon los siguientes valores y principios de la metodología.

 

Valores de la metodología ágil:

  • los individuos y sus interacciones son más importantes que los procesos y las herramientas;
  • el software funcional es más importante que la documentación completa;
  • la cooperación con el cliente es más importante que las obligaciones contractuales;
  • reaccionar al cambio es más importante que seguir un plan.

 

Principios de la metodología ágil:

  • satisfacción del cliente mediante la entrega temprana e ininterrumpida de software valioso;
  • dar la bienvenida a los cambios en los requisitos, incluso al final del desarrollo (esto puede aumentar la competitividad del producto resultante);
  • entrega frecuente de software en funcionamiento (cada mes o semana o incluso con mayor frecuencia);
  • comunicación cercana y diaria entre el cliente y los desarrolladores durante todo el proyecto;
  • el proyecto es llevado a cabo por personas motivadas que cuentan con las condiciones de trabajo necesarias, apoyo y confianza;
  • el método recomendado para comunicar información es la conversación cara a cara;
  • ejecutar software es la mejor medida de progreso;
  • los patrocinadores, desarrolladores y usuarios deben poder mantener un ritmo constante de forma indefinida;
  • enfoque continuo en mejorar la excelencia técnica y el diseño fácil de usar;
  • la simplicidad es el arte de NO realizar trabajos innecesarios;
  • la mejor arquitectura, requisitos y diseño provienen de un equipo autoorganizado;
  • adaptación constante (frecuente) (mejora de la eficiencia del trabajo) a las circunstancias cambiantes.

 

Existen metodologías que se adhieren a los valores y principios establecidos en el Manifiesto Ágil. 

Una de las más habituales es la metodología de desarrollo Scrum, que, quizás, puede considerarse un conjunto de prácticas específicas utilizadas en el proceso de desarrollo de software. 

Scrum (traducido del inglés. "Rally", "dump", "fight") enfatiza claramente el control de calidad del proceso de desarrollo.

Scrum es un conjunto de principios sobre los que se construye el proceso de desarrollo, que permite, en cortos períodos de tiempo rígidamente fijados (sprints de 2 a 4 semanas), proporcionar al usuario final un software funcional con características adicionales para las que se determina la máxima prioridad. 

La funcionalidad requerida para la implementación en el siguiente sprint se determina antes de que comience en la etapa de planificación y no se puede cambiar durante el sprint. 

Al mismo tiempo, una corta duración de sprint estrictamente fija, da al proceso de desarrollo previsibilidad y flexibilidad. 

Scrum es uno de los "adoptadores" más comunes del desarrollo de software ágil.

Este enfoque fue descrito por primera vez por los expertos Hirotaka Takeuchi e Ikujiro Nonaka en 1986.  Ellos fueron quienes señalaron que los proyectos en los que trabajan equipos pequeños y multifuncionales tienden a producir constantemente mejores resultados, y lo explicaron como el “enfoque de rugby”.

Dentro de la metodología Scrum, se asigna la siguiente composición del equipo de sprint para cada sprint:

  1. Scrum Master.
  2. Cliente / propietario del producto.
  3. Equipo

Consideremos cada grupo de participantes con más detalle.

 

1. El Scrum Master es el rol más importante en la metodología. Es responsable del éxito de Scrum (como principio de organización del equipo) en el proyecto. 

De hecho, Scrum Master es la interfaz entre la gerencia y el equipo. Normalmente, el director de proyecto desempeña este papel en un proyecto.

 

Las principales funciones de un Scrum Master son:

  • crea una atmósfera de confianza,
  • elimina obstáculos,
  • hace visibles los problemas y las preguntas abiertas,
  • es responsable de adherirse a las prácticas y el proceso del equipo.

El Scrum Master lleva a cabo una reunión diaria de Scrum y realiza un seguimiento del progreso del equipo mediante el Sprint Backlog, notando el estado de todas las tareas en el Sprint. El Scrum Master también puede ayudar al Cliente a crear una lista de tareas de sprint para el equipo.

 

2. El cliente / propietario del producto es la persona a cargo del desarrollo del producto. Por lo general, se trata de un gerente de producto para el desarrollo de productos, un gerente de proyecto para el desarrollo interno y un representante del cliente para el desarrollo personalizado. 

El cliente es el único punto de la toma de decisiones finales para el equipo en el proyecto, por lo que siempre es una persona y no un grupo o comité.

 

Las obligaciones del Cliente son las siguientes:

  • es responsable de dar forma a la visión del producto,
  • gestiona la rentabilidad,
  • gestiona las expectativas de los clientes y todas las partes interesadas,
  • coordina y prioriza la lista de tareas del sprint,
  • proporciona requisitos claros y comprobables para el equipo,
  • interactúa con el equipo y el cliente,
  • es responsable de aceptar el código al final de cada iteración.

El cliente asigna tareas al equipo, pero no tiene derecho a asignar tareas a un miembro específico del equipo del proyecto durante el sprint.

 

3. Equipo

En la metodología Scrum, el equipo se autoorganiza y se autogestiona. El equipo se compromete a entregar el alcance del sprint al Product Owner. 

El trabajo del equipo se evalúa como el trabajo de un solo grupo. En Scrum, no se evalúa la contribución de los miembros individuales del equipo del proyecto, ya que esto rompe la autoorganización del equipo.

 

Las responsabilidades del equipo son las siguientes:

  • es responsable de evaluar los elementos de la cartera de pedidos,
  • decide sobre el diseño y la implementación,
  • desarrolla software y se lo proporciona al cliente,
  • realiza un seguimiento del propio progreso (junto con el Scrum Master),
  • es responsable del resultado ante el propietario del producto.

El tamaño del equipo está limitado por el tamaño grupos de personas capaces de una interacción cara a cara eficaz. El tamaño típico del equipo es de 7 ± 2.

El equipo de Scrum es multifuncional. 

Incluye personas con diferentes habilidades: desarrolladores, analistas, testers. 

No hay roles predefinidos y divididos en el equipo que limiten el alcance de los miembros del equipo. 

El equipo está formado por ingenieros que contribuyen al éxito general del proyecto de acuerdo con su capacidad y necesidad de diseño. 

El equipo se organiza para realizar tareas específicas en el proyecto, lo que le permite responder con flexibilidad a cualquier tarea posible.

Para facilitar la comunicación, el equipo debe estar en un solo lugar.

Es preferible ubicar al equipo no en salas separadas, sino en la misma sala común para reducir los obstáculos a la libre comunicación. 

El equipo debe proporcionar todo lo necesario para un trabajo cómodo, proporcionar pizarrones y rotafolios, proporcionar todas las herramientas y el entorno necesarios para el trabajo. 

El resultado del sprint depende de todas estas condiciones.

 

Habiendo considerado los principios subyacentes de Agile (y el conjunto de prácticas de Scrum), es necesario resumir lo que significa Agile:

  • flexibilidad, adaptabilidad, reducción de riesgos,
  • escalabilidad, amplitud de aplicaciones,
  • centrarse en el trabajo en equipo eficaz,
  • plazo de entrega más probable y predecible del producto al cliente.

Sin embargo, muchas empresas se enfrentan a desafíos importantes al intentar pasar al uso en el mundo real de Agile y Scrum en particular.

 

Los principales problemas de la transición a metodologías ágiles:

Falta de comprensión del papel de la dirección en la implementación de la metodología. La transición a muchas metodologías ágiles implica un cambio radical en las tareas y métodos de trabajo de los líderes. 

En pocas palabras, esta transición se puede formular como una transición del control a la dirección, una transición de órdenes e instrucciones a recomendaciones. 

El primer error que se comete durante dicha transición es un deseo subconsciente de retener el poder, lo que conduce al mismo control. 

El segundo error igualmente grave es todo lo contrario: un malentendido de esta transición puede llevar a la remoción de gerentes de las funciones de liderazgo, cuando el líder deja de dar instrucciones, pero nunca comienza a dar recomendaciones. 

El papel del gerente se reduce a funciones puramente formales de secretaría. 

La razón de esto puede ser la renuencia de los gerentes a razonar su opinión (en el modelo antiguo a menudo no tenían que hacerlo) o el temor de no implementar las recomendaciones formuladas.

 

Construir un "sistema" que no tenga la flexibilidad necesaria 

La falta de experiencia con la nueva metodología lleva a que el nuevo proceso se implemente siguiendo instrucciones, letra por letra, lo que genera inflexibilidad y burocracia.

 

Inicio de la implementación no desde lo "básico"

Al pasar a nuevas metodologías, la gestión persigue los beneficios específicos que la metodología debe aportar: alta productividad, calidad, etc. 

Sin embargo, algunas de las prácticas del nuevo proceso conducen más claramente a estos beneficios, y algunas no son en absoluto obvias. 

En este sentido, existe la tentación de introducir primero prácticas más "rentables" y luego otras. 

Esto no toma en cuenta que unas prácticas son básicas en relación con otras, y la introducción de la segunda sin la primera es imposible.

 

Los trabajos cambian, pero los hábitos no cambian

Declarar nuevas reglas y seguir estas reglas son cosas fundamentalmente diferentes. 

Falta de comprensión de nuevas ideas por parte de todos los miembros del equipo o poca conciencia de los beneficios de cambiar a un nuevo proceso, motivación débil, falta del período de transición con indulgencias claramente expresadas en el horario de trabajo y el número de tareas: esta no es una lista completa de errores que pueden llevar al hecho de que el nuevo proceso solo se puede seguir formalmente "por el bien de la apariencia", pero en realidad saboteado por los miembros del equipo.

 

Mida todo (recopile datos), pero no reaccione ante nada 

Análisis interminable de la situación, en lugar de mejora continua. 

La mayoría de las metodologías ágiles implican recopilar datos y discutir los errores cometidos en el paso anterior antes de comenzar con el siguiente. 

Los errores comunes en esta área son la recopilación de datos sin un análisis adicional o una interpretación incorrecta o demasiado superficial de los datos recopilados.

 

Prescindir de apoyo

La falta de experiencia del equipo con la nueva metodología y la implementación de las instrucciones por carta está plagada de errores, malas interpretaciones y malentendidos. 

Solo la participación de un instructor experimentado con experiencia directa en el nuevo proceso en el proceso de transición puede salvar al equipo de muchos giros equivocados y callejones sin salida, o en algunos casos incluso de construir una metodología completamente incorrecta.