Rapid Application Development

Mucho hemos escuchado de “Metodologías Ágiles”. Pero realmente la metodología ágil nos hace ágiles? No necesariamente.

Primero voy a resumir rápidamente lo que es una Metodología Ágil y una Metodología Cascada (tradicional). Lo tradicional es que primero se definen detalladamente los requerimientos, y luego se hace toda la construcción. La metodología ágil nos dice que primero se construye un prototipo, a veces llamado MVP, y sobre esa base se va retroalimentando y se va construyendo continuamente. Se dice que la metodología ágil entrega valor primero, ya que se tienen entregables desde más temprano.

Usemos el ejemplo de la construcción de una casa, para poder entender mejor de metodologías aplicadas.

Qué es Rapid Application Development (RAD), y cómo garantizar su éxito

A diferencia de los métodos tradicionales en cascada, RAD es un proceso continuo, que permite generar valor mucho más rápido, y en muchos casos terminar con una solución mucho más apegada a las necesidades del negocio.

El proceso de RAD implica primero analizar los requerimientos, hacer diseños simplificados y pasar a la construcción de prototipos funcionales. Muchos proyectos tradicionales fallan y se pierden muchos millones de pesos, porque después de muchos meses de tiempo, dinero y esfuerzo, la solución no cumple los requerimientos. Con RAD esto se mitiga ya que el usuario del negocio empieza a ver la solución a través de Prototipos Funcionales que luego evolucionan a MVP (Minimum Viable Product), los cuales se pueden poner en operación en una fracción del tiempo, el costo y sobre todo el riesgo. 

Una ventaja muy importante de RAD es que el equipo del proyecto se mantiene motivado al tener victorias continuas, a diferencia de ver la victoria demasiado lejos.

Las claves del éxito son:

  1. Tener reuniones para entender los requerimientos
  2. Hacer buenos prototipos funcionales
  3. Hacer buenas revisiones sobre los prototipos funcionales
  4. Hacer cambios rápidos, basados en las revisiones
  5. Poner en productivo el MVP lo más pronto posible
  6. Repetir el proceso ‘n’ veces.
  7. Mantener siempre mapas visibles de las actividades del equipo, se recomiendan tableros kanban.

Si observan bien, la clave del éxito consiste en muy buena medida en tener la capacidad de hacer prototipos funcionales y poderlos modificar rápidamente, y también en tener la capacidad de hacer MVP’s de forma rápida, y que tengamos la capacidad de evolucionarlos continuamente.

Existen las siguientes formas de desarrollar software:

  1. No-Code: Existen soluciones como Appery.io que nos permiten diseñar aplicaciones web y s web que se configuran de forma gráfica. 
    1. Ventajas: 
      • Es lo más rápido
      • Se puede usar como herramienta para hacer prototipos funcionales 
    2. Desventajas:
      • Nos limitamos a los elementos gráficos que se nos presentan en la solución
      • Nos limitamos a lógica simple que no siempre alcanza cubrir los requerimientos del usuario
  2. Low-Code: Existen soluciones como Mendix o Odoo Studio que mantienen las ventajas de No-Code, es decir, se pueden diseñar pantallas con templates y ‘drag and drop’ pero al mismo tiempo permiten extender la funcionalidad a través de lógica de programación encapsulada dentro de pequeñas funciones que se asocian a los botones o las acciones del flujo de las pantallas.
    1. Ventajas:
      • Sigue siendo muy rápido
      • También se puede usar para hacer prototipos funcionales
      • Es muy flexible, se pueden cubrir casi todos los requerimientos
    2. Desventajas:
      • Sigue teniendo limitaciones sobre los elementos gráficos
  3. Desarrollo Tradicional: Aquí existen muchos lenguajes de programación, frameworks, y arquitecturas de desarrollo que se pueden usar. Básicamente todo se puede hacer aquí.
    1. Ventajas:
      • Es la opción más flexible que permite cubrir cualquier requerimiento de negocio
    2. Desventajas:
      • No se puede usar para construir prototipos, hay que hacerlos en otro lado
      • Es difícil decidir el lenguaje y el framework a utilizar
      • Es la opción más tardada y cara
      • Dependiendo de quién lo hace, puede que después de un tiempo el código quede tan amarrado que ya no se puedan seguir haciendo más cambios y haya que volver a hacerlo todo.

Nosotros recomendamos opciones de Low-Code para la estrategia de Rapid Application Development, ya que nos permite elaborar los prototipos, luego utilizarlos para evolucionarlos a MVP y luego seguir evolucionando el software sin las complejidades de hacer todo por codigo.