Agile software development

En un mundo de constante cambio e incertidumbre, es imposible predecir a futuro cual va a ser la siguiente innovación. Por ello desde hace años los desarrolladores han estado usando métodos Agile para reducir sus ciclos de desarrollo, basándose en un aprendizaje contínuo y entregar valor al cliente de forma regular.

Agile Manifesto

Imagen de la web de http://agilemanifesto.org/

Fue popularizado por el Agile Manifesto, que define sus valores y principios, habiéndo evolucionado en diferentes métodos de desarrollo, siendo dos de los más utilizados Scrum y Kanban.

Lean UX se basa en los principios descritos en el manifesto, los cuales son los siguientes:

Los 4 principios Agile

  1. Individuos e interacciones sobre procesos y herramientas
  2. Software funcionando sobre documentación extensiva
  3. Colaboración con el cliente sobre negociación contractual
  4. Respuesta ante el cambio sobre seguir un plan

El diferente tamaño de letra se debe a que aunque se valoren los elementos de la derecha, se priorizan más importantes los de la izquierda.

Individuos e interacciones sobre procesos y herramientas

Es más importante el conocimiento de las personas y el valor que puede surgir del conocimiento conjunto que los entregables o los procesos rígidos. La libertad de compartir ideas y realizar aprendizaje y descubrimiento entre todos los miembros del equipo crea un ambiente de innovación lo que conlleva a conseguir mejores soluciones, a la par que un sentimiento de responsabilidad sobre lo creado.

Si existe una ambiente de conversación sana y libre, existe debate, la posibilidad de tomar decisiones de forma conjunta y seguir avanzando, sin dependencias externas.

Software funcionando sobre documentación extensiva

Cada problema al que se enfrenta un negocio tiene infinitas formas de solucionarlo y cada miembro del equipo puede tener una opinión sobre cual es la mejor. El reto es encontrar la solución más viable.

Muchas veces es imposible predecir cual va a ser mejor. Por ello cuanto antes se peda probar con clientes o usuarios finales, más rápido se verá si se va por el buen camino o no para solucionar ese problema.

Cuando no existe comunicación entre los miembros del equipo, o cada fase del proyecto lo realizan unas personas sin haber estado previamente involucradas, es necesario desarrollar una documentación para enseñar lo que se ha estado realizando. Este precioso tiempo se dedida entonces a escribir textos que muchas veces nadie se lee, en vez de estar desarrollando el producto.

Colaboración con el cliente sobre negociación contractual

El trabajar de forma unida entre los miembros del equipo y con el cliente, construye un entendimiento compartido del problema y de las posibles soluciones a implementar. Crea consenso antes que decisión.

Esto conlleva a iteraciones más rápidas, una participación real en la creación del producto y un equipo que invierte su tiempo aprendiendo a validar las soluciones.

Como se ha comentado antes, al participar todo el equipo y cliente en el proyecto y en la toma de decisiones, se reduce la dependencia en crear documentación extensa ya que todo el mundo ya conoce la información.

La colaboración y participación conjunta en el proceso alinea y unifica a los equipos mucho más que cuando una parte realiza la investigación y debe convencer al resto de que esa solución es la mejor.

Respuesta ante el cambio sobre seguir un plan

Es imposible predecir lo que de verdad quiere el cliente o necesitan los usuarios. Tampoco se puede saber si va a haber algún cambio que influya y modifique totalmente la idea inicial.

Hasta que no se prueba, todo son asunciones, con lo cual, cuanto antes se pruebe antes se verá si es lo que se necesita o no, minimizándose la cantidad de recursos gastados.

Minimizar la cantidad de trabajo no realizado.

En muchas empresas, se solicitan unos requerimientos cerrados, sobre un presupuesto cerrado, que después de meses o años de desarrollo, y un montón de recursos gastados, acaba al final en manos de un cliente o usuario, que ni lo utiliza ni lo sabe utilizar porque no es lo que en verdad necesita.

Es por ello, mucho mejor, analizar cual es el MVP (Minimum Viable Product), es decir el mínimo producto viable para probar esa hipótesis de posible solución, y una vez descubierto si se va en la dirección correcta seguir avanzando.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *