Seguimos con esta pequeña guía hacia la agilidad y creo que lo siguiente que es necesario conocer, antes de entrar mas a fondo en el manifieste ágil, es que diferencias hay entre crear un producto de manera ágil y crearlo de la manera «tradicional» o en cascada.
Lo primero que tengo que decir es que la manera de crear en casaca no es el lado oscuro (aunque seguro que en algún post lo digo 🙂 ) y no tenemos que cambiar de repente todos hacia la agilidad y utilizarla en todos los proyectos que desarrollemos, ya que no siempre será posible, aunque por otro lado, no siempre hay que quedarse en waterfall ya y pensar que la agilidad «es un invento» ya que está mas que demostrado que funciona.
Venga que si no comienzo esto será larguísimo:
Cascada: Lo que todos conocemos «Quiero tal cosa de esta manera y la quiero para el día tal. Por cierto si te atrasas te tendré que penalizar y tu alma será mía» (la parte en cursiva la puedes cambiar por lo que quieras, pero que sea doloroso 😛 ).
Para poder completar esta tarea desde el inicio debemos de saber todos los requisitos del proyecto antes de comenzar para diseñar el producto final y completo.
Necesitamos, como he dicho antes, tener todos los requerimientos especificados, crear un calendario con unos hitos bien marcados sabiendo todas las dependencias entre ellos, tener un contrato en el que ambas partes estén de acuerdo en todo lo que se tiene que crear y sobre todo cumplir con lo que se ha firmado (aunque veamos que faltan o sobran cosas) y es muy importante cumplir con el contrato para no caer en penalizaciones y en caso que existan problemas poder defendernos. En este caso no estaremos cooperando con el cliente que realiza el encargo.
Es decir, una vez se ha pensado el producto final, este no acepta modificaciones ya que se ha especificado de manera muy clara en un principio y por norma general todas las modificaciones que se tenga que realizar implican un coste extra para el cliente.
Agilidad: Aquí la cosa cambia «Tengo una idea que quiero se convierta en realidad, pero no sé seguro al 100% que es lo que el «Stakeholder» ( usuario final que utilizará el producto, entre otros) querrá que implementemos primero o que le parecerá más interesante.
Vemos que hay un cambio importante por parte del cliente stakeholder (en este caso quien tiene la idea y quiere realizarla), asume que existe una incertidumbre sobre el producto y que no puede predecir en que acabará convirtiéndose, sabiendo que la única manera de descubrirlo es observar a los usuarios finales (otros Stakeholders), saber como ellos tratan el producto, que partes utilizan y como lo hacen. Este es un punto importante ya que aunque los usuarios finales no lo sepan, se les acaba de convertir en una parte muy importante de desarrollo del producto.
Para poder completar la tarea debemos de tener claro cual es la visión y cuales son los requisitos, pero en este caso no para poder diseñar el producto final, si no para poder diseñar un MVP (Minimum viable product) (mas adelante revisaremos metodología para poder alcanzar este MVP) es decir que es lo mínimo que podemos construir para poder lanzar el producto al mercado y recibir feeback de los usuarios finales o stakeholders (en este caso los que utilizarán el producto).
Para poder recibir el feedback es muy importante determinar cuales son los KPI que queremos tener en consideración ya que estos son vitales, ya que son la clave que nos ayuda a despejar incertidumbre sobre el producto y poder predecir con mayor grado de fiabilidad que será valor y que debemos desarrollar en próxima iteración.
Sobre este punto hay que abrir la mente ya que no siempre el único KPI debe ser el retorno de la inversión, puede ser que nos interese la valoración de la experiencia de uso de los stakeholders (en este caso clientes finales), o cuantos de estos stakeholders han modificado sus hábitos gracias a nuestro producto, numero de stakeholders que lo utilizan, si ha mejorado la sensación de calidad de los stakeholders, cuanto pensamos que podemos evolucionar el producto, etc…
Otra de las grandes diferencias que cabe destacar y que es muy diferencial entre agile y waterfall es cuando comienza el retorno de la inversión.
Se puede decir que en waterfall no se recibe retorno hasta la puesta en marcha del producto, ya que hasta ese momento los usuarios no tienen posibilidad de uso dado que el producto no es alcanzable para ellos. también se debe de tener en consideración que una vez lanzado será «doloroso» realizar cambios en el producto en caso que detectemos que los usuarios finales reclamen o no utilicen partes, ya que se ha utilizado el presupuesto para desarrollar un producto finalizado completamente y puede que no acertáramos al 100% en todo lo que pensamos inicialmente.
Por otro lado en agilidad, se intenta comenzar a tener retorno lo mas temprano posible, por eso se crea el MVP, con la ventaja que podemos ir conduciendo la creación de nuestro producto con cada iteración que realizamos para aumentar el retorno a la vez que potenciamos los puntos que mejor aceptación tienen, creando un producto «a medida» de nuestros consumidores.
Pues nada, que como se dice … hasta aquí puedo leer … Seguiremos mas adelante y que creo que si has llegado a leer hasta aquí te mereces un descanso y una buena cerveza 🙂
Saludos y cuidaros todos mucho!!!