Uniendo la metodología Ágil con la Experiencia de Usuario

TRANSCRIPCIÓN DEL VIDEO

El otro día me brindaron la oportunidad de participar en una clase magistral que versaba sobre Transformación Digital y metodologías ágiles. Desde aquí agradecer a los organizadores que hubieran pensado en mi para ello. El reto para mi fue explicar en poco rato un concepto tan amplio, interesante y disruptivo como las metodologías ágiles a personas con diversas formaciones pero ninguna familiarizada con el desarrollo de software.

Quería compartir con vosotros entonces en el formato más breve posible la información que les trasladé. Un “metodologías ágiles para torpes” muy simplificado

Lo primero que dije es que el paradigma ágil, donde se incluyen unas cuantas metodologías como Scrum, Kanban, Lean o XP, va totalmente dirigido al proceso de desarrollo del software. Con todo, la sociedad moderna y su necesidad de mantras para aplicar a la tan ansiada transformación intenta aplicar los principios que rigen estas metodologías como filosofía que pueda ser aplicada en otros aspectos.

¿Recordáis este chiste que corre por las redes? Seguro que muchos de vosotros se ha echado unas risas con él. Para aquellos que no hayan tenido el placer, intenta de una manera bastante irónica mostrar las diferentes visiones de los actores que intervienen en los procesos tradicionales de construcción del software. Y los que llevamos muchos años en el ramo damos fé que es cierto.

Pues, en un intento de tomar cartas en el asunto, en 2001 se reunieron unos cuantos señores, concretamente 17, en un resort de estos de ski en Utah. Estas personas representaban diferentes metodologías alternativas que buscaban acabar radicalmente con este panorama. Durante unos días discutieron para acabar sacando lo que se ha llamado “el manifiesto ágil” que teneis aquí detrás. Este manifestó era una declaración de intenciones muy corta, muy simple pero muy directa que ponía el énfasis en cambiar la manera desarrollar software a partir de unas cuantas cosas muy sencillas de aplicar.

En este sentido el manifiesto se sustenta en diversos principios que he intentado simplificar.

Principios del manifiesto Agile

El primero es la ITERATIVIDAD. Se trabaja por ciclos cortos, 2 o 3 semanas normalmente, en lo que se desarrolla progresivamente aquello que se quiere acabar construyendo

Otro principio es el VALOR y el TIME TO MARKET. Estas metodologías se centran en la entrega temprana y continua del software de manera que el cliente pueda hacer uso de el de manera progresiva. Entregar valor continuamente frente a tener que esperar al final para disfrutar. Es como aquel otro dibujito que circula por la red sobre la mejor manera de llegar a construir un coche. O bien primero construyendo las ruedas, después el eje, después el motor y así. O bien primer construir un monopatín, después un patinete, después una bicicleta y así. La idea de la bicicleta es ágil.

El siguiente es la ADAPTABILIDAD. Las metodologías ágiles aceptan y entienden que el software es algo muy intangible. Al contrario que una silla del IKEA que es algo que puedes tocar o dibujar, el software no tiene color, tamaño, material… Es por ello que estas metodologías aceptan cambios en los requisitos. A través de esas iteraciones se acepta el cambio y la incertidumbre, adecuando el desarrollo del software a las respuestas del cliente ante el valor entregado.

Otro muy relacionado con lo que acabo de decir es el ALINEAMIENTO y LA COLABORACIÓN. Los desarrolladores y clientes trabajan codo con codo durante todo el proceso. Así el feedback es inmediato y se cumple la ansiada adaptabilidad. Esto puede llegar a chocar a los que han trabajado siempre con metodologías tradicionales. En lo ágil todo es muy democrático en contraposición con las rígidas jerarquías tradicionales. Se busca la auto-organización de los equipos y las decisiones de consenso.

Un principio muy importante es la CONVERSACIÓN CARA A CARA. Este es el medio de comunicación primordial en las metodologías ágiles en contraposición con los tochos de documentación generados. Esto puede llegar a chocar a muchos ya que durante el proceso de desarrollo existen multitud de momentos en los que el equipo se reúne y habla. Eso para muchos puede ser síntoma de “se están tocando los …” pero no. Esos son los momentos en que se ponen de acuerdo, se toman decisiones importantes y se asegura la coherencia de lo que se hace.

Y por último, aunque existen otros, está el KISS. Este es un principio universal pero que fácilmente se aplica aquí. Es el KEEP IT SIMPLE STUPID hazlo simple estúpido. Estas metodologías buscan maximizar la cantidad de trabajo no realizado, es decir, hacer lo estrictamente necesario para que funcione tal como se quiere. En futuras iteraciones ya se podrá complicar pero siempre a voluntad del cliente y del equipo.

Para explicar mejor lo que realmente son estas metodologías he optado por usar un simple esquema del proceso. Y como se que los humanos entendemos mejor las cosas por contraposición, lo primero que he hecho es exponer cual sería en una metodología clásica.

Para las clásicas he optado por una metodología en cascada. En éstas todo está muy bien planificado en fases y tareas al inicio del proyecto. Estas tareas se van ejecutando tanto secuencial como en paralelo para alcanzar el objetivo final. Así siempre comenzamos con una fase de recogida de requisitos, su análisis y el diseño de lo que vamos a construir. El resultado es un montón de documentación que debemos validar con el cliente para poder continuar. A partir de entonces podemos desarrollar el software. Durante esta fase se marcan diversos puntos de seguimiento en el que, con suerte, el cliente puede ver algo parcial sin hacerse una idea global de lo que le acabaran entregando. Cuando lo hacen se abre normalmente una fase igualmente larga de cambios para que al final el cliente acabe teniendo algo que se parece relativamente poco a lo que el había pedido en un inicio.

Por el contrario, la práctica ágil comienza por una fase previa de consenso con el cliente que bien puede ser un proceso de Design Thinking del que se acaba sacando un Backlog. Este backlog recoge de forma sintética todo lo que queremos hacer en forma de historias de usuario priorizadas…

Explicación detallada del proceso…

Comparativa entre procesos

¿Es mejor un paradigma u otro? Son diferentes. Como ya hemos visto hay diferencias importantes entre ellos. Mientras las metodologías ágiles son totalmente adaptativas, las tradicionales son totalmente predicitivas. Eso se traduce en lo que hemos hablado una mayor iteratividad respecto a la necesidad de hacer las cosas por fases para un mayor control. Y también se traduce en que es el código y no la documentación la que sustenta lo que se está desarrollando. Es el mismo producto desarrollado y su código y no ese análisis funcional que nadie mirará tiempo después de que se haya acabado el proyecto.

Y eso nos lleva a preguntarnos ¿Cuándo es indicado usar uno u otro? Aunque siempre es difícil decirlo, parece que el consenso generalizado sería que las metodologías ágiles son indicadas para alcances difusos en los que se debe gestionar bien la incertidumbre y cuando el tiempo pasa por delante de la calidad. Y aquí debo hacer un inciso… La calidad es importante siempre. Quizás la única diferencia radica en que en las ágiles forma parte del mismo proceso de desarrollo y está dentro del mismo Sprint, mientras que en las tradicionales se acostumbra a ejecutar en una fase posterior a la del desarrollo. Las tradicionales están indicadas para desarrollos con alcances muy bien definidos y cuando la calidad pasa por delante del tiempo. La adopción de una u otra va mucho a como es la organización. Es un tema de riesgo, incertidumbre y criticidad. Existe la creencia de que las metodologías ágiles no son las mejores para proyectos de alta criticidad porque supone asumir un mayor riesgo, cosa que las grandes y tradicionales empresas evitan a toda cosa.

Tasas de éxito del proceso

Con todo, quiero mostrar este gráfico para demostrar que las tasas de éxito de los proyectos que se asumen con las ágiles son, sin discusión, mejores que las tradicionales. Y eso es un hecho incuestionable. Las compañías en su ansia por transformarse deben aprender a convivir con la incertidumbre. Se acabaron los proyectos faraónicos en los que se controlaba todo desde un Project. La transformación pasa entonces por las metodologías ágiles.

Para finalizar pedir disculpas de antemano a los verdaderos expertos en metodologías ágiles por la simplificación del concepto. Mi objetivo principalmente es espolear la curiosidad de la gente para que investiguen y sigan aprendiendo sobre ellas.

A todo el resto espero que os haya gustado el video.

Saludos